Kimi acaba de lanzar K3, su modelo más potente hasta ahora, y decidí probarlo con algo que no fuera un prompt sencillo ni una landing page básica. La idea era ponerlo realmente bajo presión: pedirle una simulación 3D interactiva de una mini ciudad futurista con tráfico autónomo, peatones, semáforos adaptativos, accidentes, ambulancias, métricas y distintas cámaras, todo funcionando directamente en el navegador.
En los benchmarks mostrados por Kimi, K3 aparece muy cerca de modelos de frontera como GPT 5.6 Sol y Fable 5, por encima de GPT 5.5 y Opus 4.8. Obviamente, los benchmarks son una cosa y construir un proyecto complejo de punta a punta es otra. Por eso esta prueba me parecía interesante.
El resultado fue una aplicación llamada Neopolis: una ciudad simulada con interfaz propia, controles ambientales, sistema de tráfico, modos de cámara, panel de métricas y eventos de emergencia. No salió instantáneamente, se demoró bastante, pero logró completar un proyecto que normalmente exigiría mucho más trabajo manual.
Tabla de contenido
- 🚦 El desafío: construir una ciudad autónoma que funcionara de verdad
- 🤖 Por qué usé Kimi K3 Swarm
- 🧠 Cómo Kimi dividió el trabajo
- 🏙️ Neopolis: una landing page que no estaba ni en el pedido
- 🎮 Los controles de la simulación 3D
- 🚥 Semáforos adaptativos, tráfico y gestión con IA
- 🔊 La mejora posterior: añadir sonido a los accidentes
- ⏱️ Tiempo, consumo y el punto débil de Kimi K3
- 📊 Entonces, ¿Kimi K3 realmente está al nivel de modelos de frontera?
- 🛠️ Dónde probar Kimi K3 y sus herramientas
- ✨ La lección más importante: ya podemos pedir proyectos bastante más ambiciosos
🚦 El desafío: construir una ciudad autónoma que funcionara de verdad
La petición no era simplemente generar una escena 3D bonita. Quería una simulación donde hubiese lógica detrás de lo visual. Es decir, calles conectadas, vehículos moviéndose por carriles, peatones cruzando, semáforos con ciclos coordinados, congestión y situaciones de emergencia.
La lista de requisitos incluía varios componentes que, juntos, convierten una demo visual en una pequeña aplicación interactiva:
- Varias intersecciones conectadas entre sí.
- Vehículos autónomos que circularan por carriles.
- Peatones con comportamiento independiente.
- Semáforos coordinados y configurables.
- Tráfico moderado, denso y caótico.
- Accidentes y eventos de emergencia.
- Ambulancias con prioridad de circulación.
- Métricas de movilidad en tiempo real.
- Controles de clima, hora, lluvia y velocidad de simulación.
- Cámaras aérea, rasante y cinemática.
- Una interfaz pulida para navegar y controlar todo.
Esto importa porque un modelo puede ser bueno generando una pantalla estática, pero otra cosa muy distinta es organizar arquitectura, estado, componentes, lógica de simulación, interfaz, validación y depuración. Ahí es donde quería ver si Kimi K3 estaba realmente a la altura.
🤖 Por qué usé Kimi K3 Swarm
Kimi ofrece tres variantes principales en esta experiencia: K3, K3 Max y K3 Swarm Max. La opción Swarm está pensada para trabajos complejos porque levanta subagentes que pueden repartirse las tareas y avanzar en paralelo.
Para una petición como esta, usar un único agente habría sido posible, pero probablemente mucho más lento. Había demasiado que resolver: diseño, planificación, estructura del proyecto, motor de simulación, escena 3D, HUD, páginas y depuración. Mi intuición era clara: para algo de este tamaño, lo correcto era activar Swarm.
El prompt incluía de forma explícita que los agentes debían planificar y dividir el proyecto entre especialidades. Eso es bastante importante. En vez de pedir solamente “hazme una ciudad 3D”, le estaba dando una misión con entregables funcionales y con una instrucción de organización.
Una buena petición para este tipo de trabajo tiene que dejar claras cuatro cosas:
- El resultado final: qué debe poder hacer la aplicación.
- Las reglas del sistema: cómo deben interactuar tráfico, peatones, semáforos y emergencias.
- La experiencia visual: qué controles y vistas debe tener la interfaz.
- El criterio de calidad: que funcione en navegador, sea interactiva y pueda validarse.
Si quieres aprender a plantear mejor las instrucciones antes de crear una app con inteligencia artificial, tengo una guía específica sobre cómo crear prompts para tu app. Para mí, esta parte cambia muchísimo el resultado final.
🧠 Cómo Kimi dividió el trabajo
Una vez enviado el prompt, Kimi comenzó a crear agentes y a estructurar el proyecto por etapas. La planificación contempló siete fases. Al dejarlo trabajar, se podía ver que iba descomponiendo una tarea enorme en partes mucho más manejables.
Después de aproximadamente dos horas de trabajo acumulado, el proyecto marcó como terminado. Kimi indicó que ocho agentes participaron en la construcción de Neopolis. Sus responsabilidades cubrían áreas como:
- Planificación del producto.
- Diseño de experiencia e interfaz.
- Scaffold o estructura inicial del proyecto.
- Motor de simulación.
- Escena visual de la ciudad.
- HUD y paneles de control.
- Páginas de presentación.
- Depuración y validación.
Esto fue una de las partes más interesantes de la prueba. No se trató de una única respuesta larga con código. El sistema generó archivos, organizó una estructura, construyó componentes y luego validó el resultado en navegador.
En proyectos de este tipo, esa separación es muy lógica. El motor de simulación no debería tener las mismas responsabilidades que el diseño del HUD. La escena 3D no debería mezclarse con la lógica de los semáforos. La depuración debe comprobar que todo se conecte correctamente antes de entregar una versión final.
Que un sistema de agentes sea capaz de adoptar esta forma de trabajar no significa que reemplace por completo la revisión humana, pero sí demuestra que ya puede encargarse de una cantidad importante de trabajo de producción.
🏙️ Neopolis: una landing page que no estaba ni en el pedido
Al abrir el preview, lo primero que apareció no fue directamente el simulador. Kimi creó una landing page de presentación para Neopolis, algo que ni siquiera había pedido explícitamente. La página tenía estética futurista, una propuesta de valor y un botón para iniciar la simulación.
El concepto central de la página era bastante bueno: “El tráfico piensa. La ciudad fluye.” Esa frase resume bien la idea de usar inteligencia artificial y señales adaptativas para gestionar movilidad urbana.
También aparecieron secciones explicativas sobre las capacidades de la ciudad, como intersecciones coordinadas, flota autónoma, semáforos adaptativos, peatones, emergencias con prioridad y ciclo meteorológico. Es una buena muestra de que el sistema no se limitó a crear un canvas 3D, sino que pensó el proyecto como un producto completo.
Después de iniciar la simulación, aparecía una introducción breve con indicaciones sobre los controles disponibles. La experiencia era bastante clara: explorar libremente la ciudad o tomar el control desde los paneles laterales.
🎮 Los controles de la simulación 3D
Una vez dentro de Neopolis, había bastante más interacción de la que esperaba. La ciudad permitía cambiar condiciones ambientales, ritmo de ejecución, cámaras y parámetros de tráfico desde la interfaz.
Entre los controles principales estaban:
- Ciclo día y noche: se podía mantener automático o controlar la hora manualmente.
- Lluvia: un interruptor permitía activar o desactivar el clima lluvioso.
- Velocidad: la simulación podía pasar de 1x a 4x para observar cambios más rápido.
- Cámaras: había modo aéreo, rasante y cine.
- Navegación libre: era posible hacer zoom y desplazarse por distintas zonas de la ciudad.
- Semáforos: se podían modificar los tiempos de ciclo y alternar entre modos.
- Modo IA: el sistema podía optimizar automáticamente los tiempos de los semáforos.
La cámara aérea era probablemente la más práctica para entender la red completa. Permitía acercarse a una intersección específica, observar los vehículos, revisar los cruces peatonales y ver el estado de las señales.
La cámara rasante, en cambio, daba una sensación más cercana a estar dentro de la ciudad. Se podía avanzar entre edificios, seguir carriles iluminados y pasar cerca de vehículos. No es necesariamente la vista ideal para administrar el tráfico, pero sí aporta bastante a la presentación del proyecto.
El modo cinemático también funcionaba como una forma de recorrer la ciudad desde diferentes ángulos. Para una demo o una presentación de producto, este tipo de detalle visual suma muchísimo.
🚥 Semáforos adaptativos, tráfico y gestión con IA
La parte más importante de la simulación no era únicamente el movimiento de autos. Era la posibilidad de intervenir en las reglas que organizan la circulación.
En el panel lateral se podía cambiar la duración de los ciclos de semáforos, dejando más o menos tiempo para cada fase. También había una opción adaptativa y un modo controlado por IA, donde el sistema intentaba optimizar los tiempos de señalización.
La idea es muy interesante. En una ciudad real, un semáforo de tiempo fijo puede ser ineficiente si una calle está prácticamente vacía y otra está completamente congestionada. Un sistema adaptativo, en teoría, puede usar el flujo de tráfico para ajustar sus decisiones y mejorar la circulación.
La simulación mostraba métricas en tiempo real, como nivel de congestión, flujo vehicular, incidentes y otros indicadores asociados a la movilidad. Esto permite no solo cambiar valores, sino también observar las consecuencias de esos cambios.
Para generar más presión, fui aumentando el tráfico, la cantidad de peatones y los eventos de emergencia. También activé lluvia y probé distintos ajustes de semáforos. La ciudad podía pasar de un flujo moderado a una situación bastante más caótica.
Ahí se nota el valor de tener una aplicación interactiva en vez de una escena de exhibición. Se puede modificar el sistema, provocar condiciones extremas y revisar cómo responde.
El límite de una demo de simulación
Eso sí, había un detalle importante. Aunque los accidentes se registraban como eventos y aparecían en las métricas, la simulación no parecía tener colisiones físicas extremadamente precisas entre todos los vehículos y peatones. En un punto, algunos elementos lograban pasar muy cerca unos de otros sin una reacción física completamente realista.
Y está bien tenerlo presente. Neopolis es una aplicación creada automáticamente como prueba de capacidad, no un motor de tráfico validado para operar una ciudad real. Pero para el objetivo de construir una demo compleja, interactiva y coherente, el resultado fue bastante sólido.
🔊 La mejora posterior: añadir sonido a los accidentes
Después de probar la ciudad y generar algo de caos, apareció una mejora muy concreta: si sucede una colisión, tiene sentido que exista una señal sonora. El sistema registraba accidentes, pero faltaba esa capa de feedback que hace que un evento crítico se perciba inmediatamente.
En lugar de reiniciar el proyecto con Swarm, esta vez usé un solo agente. La instrucción fue simple: añadir sonido cuando ocurriera una colisión y, además, sugerir mejoras siguientes para el proyecto.
Kimi respondió proponiendo una implementación en una nueva rama, con un módulo de sonido procedural, validación y una nueva versión de la aplicación. Mientras trabajaba, se podían ver los archivos creándose en tiempo real.
Este punto es importante porque demuestra que el proyecto no quedó congelado después de la primera entrega. Se podía iterar sobre una funcionalidad puntual, pedir una mejora bien delimitada y dejar que el agente hiciera el cambio sin rehacer toda la ciudad.
Tras la validación, volví a abrir la simulación, aumenté el tráfico, los peatones, la lluvia y el caos hasta que finalmente ocurrió un accidente. Esta vez, el evento tuvo sonido. Funcionó.
Ese pequeño cambio ilustra bastante bien una forma útil de trabajar con agentes de código:
- Construir una primera versión amplia del producto.
- Probar la aplicación en condiciones reales de uso.
- Encontrar fricciones, vacíos o detalles faltantes.
- Hacer solicitudes pequeñas y específicas.
- Validar cada cambio antes de seguir agregando capas.
Es mucho más razonable que tratar de imaginar absolutamente todo en el primer prompt. La primera petición define la dirección. Las iteraciones convierten una demo en algo más pulido.
⏱️ Tiempo, consumo y el punto débil de Kimi K3
El proyecto completo tardó aproximadamente cuatro horas y consumió cerca de 7,57% del plan asignado en esta prueba. No fue rápido. De hecho, la principal crítica que tengo por ahora es precisamente la velocidad.
Hay que considerar que K3 estaba recién lanzado y probablemente había mucha gente usándolo al mismo tiempo. Eso puede afectar los tiempos de respuesta y validación. En tareas complejas, el sistema no solo genera código: tiene que planificar, crear archivos, conectar componentes, construir, probar y corregir. Aun así, cuatro horas es un tiempo relevante.
La parte positiva es que no necesitas quedarte mirando la pantalla durante todo ese proceso. Kimi puede seguir trabajando en una pestaña mientras haces otras cosas. También existe una opción de CLI para quienes prefieran integrar los agentes a un flujo de desarrollo más técnico.
En otras palabras, no lo veo necesariamente como una herramienta para resolver todo en segundos. Lo veo más como una especie de equipo de desarrollo asistido al que le puedes delegar una tarea grande, revisar después y luego iterar.
📊 Entonces, ¿Kimi K3 realmente está al nivel de modelos de frontera?
Después de esta prueba, mi impresión es que Kimi K3 es un modelo bastante capaz. El resultado final está en una calidad similar a lo que habría esperado de modelos de frontera como Fable 5 o GPT 5.6 Sol para una tarea de este tipo.
No estoy diciendo que sea idéntico en cada escenario, ni que una sola prueba sea suficiente para declarar un ganador absoluto. Pero en este caso concreto, logró lo que le pedí:
- Planificó un proyecto complejo.
- Dividió tareas entre agentes especializados.
- Construyó una interfaz completa.
- Generó una landing page adicional.
- Creó una ciudad 3D navegable.
- Implementó tráfico, peatones, clima y cámaras.
- Incorporó controles de semáforos y métricas.
- Permitió una iteración posterior con sonido de accidentes.
- Validó y entregó una versión funcional en navegador.
Eso no es poco. Sobre todo si se considera que el resultado salió desde una instrucción detallada y una división autónoma del trabajo entre varios agentes.
Mi conclusión es bastante directa: Kimi K3 se comportó como un modelo de frontera en esta prueba práctica. Se demoró más de lo ideal, sí. Pero cumplió el objetivo y entregó una aplicación mucho más completa de lo que esperaba obtener de una sola ejecución.
🛠️ Dónde probar Kimi K3 y sus herramientas
Si quieres experimentar con Kimi K3, agentes Swarm o proyectos de código más complejos, puedes probar Kimi directamente.
Para trabajar con herramientas orientadas específicamente a programación, está Kimi Code. También está disponible la plataforma de Kimi API para quienes quieran integrar el modelo a sus propios productos y flujos.
Este contenido incluye una colaboración pagada con Kimi, pero la prueba se hizo con un proyecto real y con una exigencia bastante alta: crear una simulación 3D de tráfico autónomo completa, no simplemente pedir una página de ejemplo.
Y si te interesa construir aplicaciones con IA, hacer vibe coding y aprender a transformar ideas en productos funcionales, puedes unirte a la comunidad de creación de apps con IA.
✨ La lección más importante: ya podemos pedir proyectos bastante más ambiciosos
Lo más llamativo de todo esto no es solo la ciudad 3D. Es el cambio de mentalidad que permite una herramienta así.
Antes, una idea como Neopolis habría requerido diseñar la experiencia, montar un proyecto, escribir el motor, crear la escena, desarrollar la interfaz, conectar métricas y depurar todo durante bastante tiempo. Ahora puedes describir el producto, obligar al sistema a pensar por etapas, delegar trabajo especializado y luego entrar a mejorar detalles.
Eso no significa que el criterio humano deje de ser necesario. Al contrario. Sigue siendo fundamental definir una buena idea, escribir un prompt claro, revisar la arquitectura, probar el resultado y detectar lo que falta. Pero el punto de partida cambió radicalmente.
Una mini ciudad futurista con tráfico autónomo, ciclo día y noche, lluvia, cámaras, eventos de emergencia y gestión adaptativa de semáforos ya no es solo una idea para un equipo grande. Con un buen planteamiento y un sistema de agentes capaz, puede convertirse en un prototipo funcional mucho más rápido de lo que parecía posible.
