Cómo una sola persona dirige un estudio de juegos con 7 agentes de IA
Un director humano, siete agentes especialistas y un archivo de reglas que se cumple como código. Qué hace bien la IA, dónde decide una persona y qué se lleva cualquier empresa.
En Kynora Labs no queríamos contar cómo se trabaja con agentes de IA: queríamos hacerlo, en producción, con algo que se pudiera mirar desde afuera. Por eso armamos un estudio de juegos para celular y navegador. Los juegos están publicados en play.kynoralabs.com y algunos en CrazyGames, uno de los portales de juegos web más grandes, donde un equipo de revisores decide qué entra y qué no.
El estudio tiene una sola persona: el director. El resto del trabajo lo hacen siete agentes de IA especialistas (agentes Claude, cada uno con su rol escrito). Esta nota cuenta cómo está organizado, qué aprendimos y qué partes de este esquema sirven para cualquier empresa, haga juegos o no.
Los siete agentes y el director
Cada agente es un archivo de texto corto que dice tres cosas: qué lee antes de empezar, de qué es responsable y con qué principios decide. No es un "asistente para todo": es un puesto de trabajo con límites.
| Agente | De qué se ocupa | Qué no hace |
|---|---|---|
| Diseñador de juego | Mecánicas, progresión, pantallas. Mantiene el documento de diseño (GDD) como fuente de verdad | No escribe código |
| Programador de gameplay | Implementa lo que dice el GDD en TypeScript y Phaser 3 | No cambia el diseño por su cuenta: reporta desvíos |
| Diseñador de niveles y balance | Curvas de dificultad y economía, medidas con bots que simulan partidas | No cambia números sin medir antes y después |
| Artista y sonidista por código | Paleta, animaciones, partículas, íconos y sonido, todo generado con código | No usa imágenes externas (salvo CC0 registradas) |
| QA | Compila, corre pruebas, revisa capturas y reporta problemas por gravedad | No rediseña: encuentra y documenta |
| Analista de datos y anuncios | Eventos de analítica, embudos, retención y dónde puede ir un anuncio | No pone un anuncio que baje la retención |
| Marketing y tiendas | Nombres, fichas de tienda, guiones de videos cortos | No promete en un anuncio algo que el juego no tiene |
El director no programa ni dibuja. Elige qué se hace, en qué orden, a qué agente le toca, y revisa el resultado. Es el mismo trabajo que el de un gerente con un equipo, con una diferencia: el equipo nunca se cansa, pero tampoco tiene criterio propio sobre el negocio. Ese criterio lo pone la persona.
Hay una regla que hace que esto funcione: cada rol tiene una definición de "terminado". El programador no termina cuando el código compila; termina cuando pasan las pruebas, corre la batería de capturas sin errores de consola, miró esas capturas y reportó qué cambió y cómo probarlo. Sin esa definición, un agente da por cerrada una tarea a medio hacer con total seguridad.
Las reglas viven en un archivo, no en la cabeza de nadie
Todo el estudio se rige por un archivo llamado CLAUDE.md, que los agentes leen antes de cada tarea. No es un manual de buenas intenciones: son reglas concretas, verificables, que funcionan casi como código. Algunas de las que más nos rindieron:
- La lógica no depende del motor gráfico. Todo lo que decide el juego (generar un nivel, simular una partida, calcular puntos) vive en módulos puros que no saben que existe una pantalla. Gracias a eso, un bot puede jugar miles de partidas en segundos y las pruebas corren sin abrir un navegador.
- Todo lo aleatorio usa una semilla. El nivel 7 es siempre el mismo nivel 7. Si alguien reporta un problema, se puede reproducir exacto.
- Ningún número suelto. Todos los valores de balance están en un único archivo de configuración. Cuando el agente de balance cambia algo, cambia ahí, y el cambio se ve.
- Los servicios externos son opcionales. El juego se abre y se juega sin internet. Si un servicio falla, el juego lo oculta con elegancia; nunca frena al jugador.
- Reglas sobre publicidad que no se negocian: el anuncio con recompensa siempre es opcional, nunca se interrumpe una partida en curso y hay un mínimo de niveles y de tiempo entre anuncios. Ningún agente puede "optimizar" eso.
La ventaja de tener las reglas escritas no es solo que los agentes las siguen. Es que cuando algo sale mal, la corrección se convierte en una regla nueva y no se vuelve a discutir. Volvemos sobre esto en el caso de CrazyGames.
QA automatizado con capturas de pantalla
Un juego puede compilar perfecto y verse roto. Por eso cada juego tiene un comando de QA que lo abre en el Chrome instalado (con playwright-core), lo recorre solo y saca capturas en los momentos clave: el arranque, la primera partida, los menús, las pantallas de resultado, el modo sin conexión.
Para que una prueba automática pueda "jugar", cada juego expone en modo depuración un pequeño panel de control (window.__GAME_DEBUG__) con el estado y acciones como resolver un nivel o saltar al nivel 50. Así QA prueba los casos borde sin jugar media hora para llegar a ellos.
Después viene la parte que más sorprende: el agente de QA mira cada captura, con una herramienta de lectura de imágenes, y busca textos cortados o superpuestos, botones demasiado chicos para un dedo, elementos fuera de pantalla en un celular de 390 píxeles de ancho y estados incoherentes, como un contador que no coincide con lo que se ve.
Una lección que nos costó cara: nunca una verificación detrás de una espera fija. Una prueba esperaba 160 milisegundos entre tocar una ficha y tocar la casilla. En una máquina cargada, ese tiempo no alcanzaba, el primer toque se perdía y la prueba fallaba tres pasos después, con un error que no apuntaba a la causa. Sobrevivió cuatro días, y dos agentes se la atribuyeron mutuamente. La regla que quedó: esperar a que el estado cambie, no al reloj. Antes de tocar el código del juego, además, comprobamos que la puntería era exacta: 177 toques sobre casillas vacías en tres corridas, con la máquina muy cargada, y cero fuera de lugar. El problema era la prueba, no el juego.
Lo que la IA hace bien
Después de varios juegos publicados, esto es lo que vemos que los agentes resuelven con solvencia:
- Volumen y constancia. Correr las mismas veinte verificaciones en cada cambio, sin saltearse ninguna por cansancio.
- Medir antes de opinar. El agente de balance no "siente" que un nivel es difícil: lanza bots, mide intentos por nivel y presenta una tabla de antes y después.
- Seguir reglas explícitas. Si la regla dice "todos los textos en español e inglés, en un solo archivo", se cumple siempre.
- Documentar. Cada revisión externa, cada arreglo y cada comando que lo verifica queda escrito, con fecha.
Dónde tiene que decidir una persona
Y esto es lo que no delegamos, porque lo probamos y no funciona:
- El gusto. La primera música de fondo de un juego era técnicamente impecable: sin cortes, sin costuras. El director la escuchó en su teléfono y dijo que parecía "un sonido de motor que va cambiando de nota". Tenía razón, y ninguna prueba automática lo iba a detectar. Se rehízo y quedó una regla nueva para todos los juegos.
- El concepto. Aprendimos que un juego que se parece a lo que ya existe no prospera, por bien hecho que esté, y escribimos un filtro de originalidad de cuatro preguntas. Contestarlas bien es una decisión de negocio, no una tarea.
- Lo que solo se ve en el mundo real. Safari, un celular de verdad, un Chromebook modesto, si el contenido es apropiado. Nuestra lista de publicación tiene una sección que se llama, literalmente, "filas que decide una persona".
- Verificar lo que dicen los propios documentos. Durante tres semanas, uno de nuestros documentos daba por bueno un resultado que no lo era, y nadie lo había corregido. Esa frase guió decisiones. Desde entonces, toda respuesta externa se anota con fecha y cita textual, aunque sea mala.
También aprendimos que el QA automático tiene un techo. Uno de nuestros juegos ya publicado tenía un 2,77% de partidas que se rompían jugando. Nuestro QA daba cero errores. La causa era una pérdida de memoria que solo aparecía cuando cambia el alto de la pantalla, por ejemplo con la barra de direcciones del celular, algo que una ventana de prueba fija nunca hace. La pista vino de las métricas de la plataforma, no de nuestras pruebas. Tras el arreglo, la tasa bajó a 0,71%. Cómo es hoy ese control de calidad, y qué agregamos después de este caso, lo contamos en QA automático con IA.
Lo que se lleva cualquier empresa
No hace falta hacer juegos para aplicar esto. Si estás pensando en sumar agentes de IA a tu operación, estas son las ideas que trasladaríamos tal cual:
- Roles chicos y con límites. Un agente que "hace todo" no hace nada bien. Definí qué lee, de qué responde y qué no puede tocar.
- Reglas escritas y verificables. "Ser cuidadoso con los datos" no es una regla. "Nunca enviar el email de un cliente a un sistema externo sin su consentimiento" sí lo es.
- Definición de terminado. Decidí de antemano qué prueba que una tarea está hecha. Si no, el agente decide por vos.
- Revisión humana en los puntos que importan. Tono de marca, decisiones con clientes, cosas irreversibles. El resto puede ir solo.
- Cada error se convierte en regla. Es la diferencia entre equivocarse una vez y equivocarse siempre igual.
- Medí afuera, no solo adentro. Las pruebas internas dicen si el sistema hace lo que pensaste. Los datos reales dicen si eso era lo correcto.
Si querés ver cómo se elige entre un asistente conversacional y un agente que ejecuta tareas, lo explicamos en la guía Chatbot o agente de IA: cuál necesita tu empresa.