Probé Kimi Code creando una app completa: Swarm, Goals y lo que nadie te cuenta

Kimi es uno de los modelos abiertos más populares del momento, en gran parte por su precio y porque trae su propio agente de código: Kimi Code. Así que decidí ponerlo a prueba de verdad: crear una aplicación entera usando solo su agente, y de paso probar sus dos características más llamativas — Swarm (lanzar múltiples agentes en paralelo) y los Goals (loops autónomos que iteran hasta cumplir un objetivo).

La app en sí es lo de menos: un sistema llamado AutoStock para manejar inventario de piezas y autos (precios, proveedores, compras, ventas), con una tienda pública y múltiples roles de usuario. Piénsalo más como una demo de lo que puede hacer el agente que como un tutorial de la app. La idea es que al final tengas claro si este modelo te sirve o no para tu flujo de trabajo.

El stack y el modo plan

Antes de pedirle que construya nada, lo primero que hago con cualquier agente es pasar al modo plan. En Kimi Code se activa con Shift + Tab (verás que el input cambia de color). Ahí le pasé el prompt inicial con la idea del sistema y el stack:

• Frontend: Next.js 16
• Backend: Express + PostgreSQL
• ORM: Drizzle
• UI del dashboard: shadcn/ui

Un tip que te ahorra dolores de cabeza: escribe /yolo al inicio. YOLO ("you only live once") es el modo en el que el agente no te pide permiso para cada comando. En planificación no importa mucho, pero cuando esté construyendo no quieres que se detenga a cada rato.

Ojo con las versiones viejas

Algo que noté rápido: Kimi tiende a sugerir versiones desactualizadas de las librerías. Parece entrenado con datos algo viejos. La solución fue apoyarlo con Context7, una herramienta que le inyecta documentación actualizada para que siempre proponga las últimas versiones. Si vas a usar Kimi (o cualquier modelo abierto barato), te recomiendo tenerla a la mano.

En el plan también me dio a elegir arquitectura: monorepo con paquetes compartidos, o todo dentro de Next.js. Fui por el monorepo con pnpm, y mi razón es simple: en sistemas de este tipo (que terminan conectándose a ERPs, otras APIs, apps de escritorio o CLIs) conviene que el backend viva por separado. El monorepo te deja escalar agregando carpetas sin reestructurar todo.

Swarm: múltiples agentes trabajando en paralelo

Aquí viene lo interesante. Con /swarm activas la característica estrella de Kimi Code: un conjunto de agentes trabajando en conjunto, como si abrieras múltiples sesiones de Kimi que se coordinan solas y reportan a un agente principal.

Le pedí: "Implementa el plan con múltiples agentes: uno de backend, uno de frontend, y crea una carpeta docs en la raíz del proyecto".

Lo que hizo fue bastante sensato:

1. Primero lanzó un agente base que dejó establecido el monorepo y los archivos de configuración (correcto, porque si no, cada agente se va por su lado).
2. Luego delegó en paralelo a tres agentes: backend, frontend y documentación.

Cada agente maneja su propio contexto — un concepto común en agentes: los subagentes no contaminan el contexto principal, y al terminar reportan solo el resultado. Abajo tienes una barra de progreso que te muestra cuántos agentes van terminando.

Al final tuve el monorepo completo, comandos para ejecutarlo y credenciales de prueba. Un tip práctico: cuando el agente genere credenciales, guárdalas en un archivo tipo test-credentials.md (y agrégalo al .gitignore). Te va a servir después para automatizar el testing.

Primer resultado: funciona, pero el diseño es básico

Ejecuté ambos proyectos (web en el puerto 3000, API en el 3001) y... bueno. La tienda pública era más un formulario que un landing, y el diseño en general era muy plano. Esto es un patrón con Kimi: la lógica avanza, pero las interfaces que genera son muy básicas.

La forma de mejorar eso es con skills: archivos Markdown con descripciones detalladas que le dan al modelo una referencia mucho más rica de qué hacer. Instalé uno llamado UI/UX Pro Max, que trae más de 50 estilos, decenas de paletas de colores, guías de tipografía y reglas de UX pensadas justamente para landings y dashboards:

npx skills add https://github.com/nextlevelbuilder/ui-ux-pro-max-skill --skill ui-ux-pro-max

Dos detalles de instalación que te van a ahorrar tiempo:

• El instalador de skills (el CLI skills) soporta Kimi Code además de Claude Code y Codex: al instalar te pregunta para qué agentes configurarlo. Instálalo a nivel global.
• Kimi Code no detecta skills nuevos en caliente: tienes que cerrar la sesión y reanudarla con kimi --resume (te lista las sesiones anteriores para retomar donde quedaste).

Con el skill activo (/skill:ui-ux-pro-max), le pedí recrear el landing desde cero y rediseñar el dashboard con sidebar, paneles y gráficas. El landing mejoró — tampoco nada espectacular — pero el dashboard directamente tiró un error. Y aquí está la lección honesta: estos modelos baratos hacen los cambios, pero el grado de calidad varía mucho. No puedes confiar a ciegas.

Testing automatizado con Playwright CLI

Cuando un modelo falla seguido, la jugada es automatizar la verificación: que el propio agente entre a las páginas, pruebe cada funcionalidad y se corrija solo. Gasta más tokens, sí, pero lo que importa es que la app funcione.

Instalé el skill de Playwright CLI (también vía skills.sh, global) y en modo plan le pedí: "Ejecuta múltiples agentes para revisar cada funcionalidad del landing y del dashboard usando Playwright CLI, en modo headed".

Un truco importante: acláraselo explícitamente — "esto es un skill". Ya me ha pasado que estos modelos, al ver "Playwright", instalan el paquete y se ponen a escribir scripts de test dentro del proyecto, cuando lo único que quieres es que naveguen la app.

El resultado fue visualmente genial: el swarm lanzó varios agentes y cada uno abrió su propia ventana del navegador, probando en paralelo el carrito, el seguimiento de pedidos, la autenticación... Al terminar, el reporte fue claro: errores críticos, páginas que no cargaban. Le pedí "corrige y lanza los subagentes de nuevo", y tras otra pasada varias vistas del dashboard ya funcionaban. No perfecto, pero iterando.

Advertencia de hardware: cada agente con navegador consume RAM en serio. Con 6 agentes en paralelo, mis 48 GB de RAM llegaron casi al 70%. Si vas a hacer testing exhaustivo con swarm, necesitas un equipo con buena memoria.

Goals: el "loop engineering" de Kimi

Para cerrar el ciclo, probé /goal, el equivalente de Kimi a los loops autónomos. Le defines un objetivo y el agente itera solo hasta cumplirlo. Mi prompt fue algo así: "Comprueba una por una cada página y su funcionamiento completo. Si no hay datos, crea un seed. Termina solo cuando todas las páginas estén completamente funcionales. Usa Playwright CLI".

Consejos concretos:

• Mantén el modo YOLO activo. Si lo dejas en modo auto, el loop se detiene cada vez que necesita permiso para un comando y pierde toda la gracia.
• Controlas el loop con /goal status (te muestra tiempo corriendo y tokens gastados), /goal pause y /goal cancel.

Lo dejé correr más de una hora. En los primeros ~15 minutos hizo el testing completo de autenticación, dashboard y UI sin que yo tocara nada, y luego empezó a delegar la corrección de bugs y a re-testear. Esto es lo que llaman loop engineering: probar, corregir, volver a probar, sin intervención humana.

Veredicto honesto

Después de todo el proceso, el resultado final es un proyecto funcional pero visualmente mediocre. Incluso con skills, la interfaz no termina de mejorar a la primera; necesitarías muchas más pasadas del loop. Como proyecto básico está bien, pero no llega solo.

Mi lectura:

• Dónde flojea: lógica de interfaces y calidad de diseño. Si eres desarrollador puro buscando el mejor resultado de código, hay otros modelos (incluso abiertos, como MiniMax o GLM) que probablemente lo hagan mejor.
• Dónde brilla: la propuesta de Kimi es una suscripción barata con una cantidad enorme de tokens. Si tu flujo consiste en delegar tareas largas y lanzar muchos agentes en paralelo, es una de las formas más económicas de lograrlo.
• Lo que más me gustó: el Swarm, sin duda. Tener orquestación de múltiples agentes integrada nativamente en el propio CLI, con contextos independientes y reporte centralizado, funciona bastante bien. Me convence más eso que los Goals.

Si tú también usas Kimi, cuéntame en los comentarios para qué lo estás usando — así todos aprendemos algo nuevo.