La Pipeline Nocturna: Cómo la IA Lanza un Juego de Navegador Mientras Duermo
Vibe Arcade ha lanzado 25 juegos en unas seis semanas. No porque alguien esté trabajando todo el día, sino porque la pipeline lo está. Aquí está exactamente cómo funciona.
La premisa suena a truco: lanza una build antes de acostarte, despierta a un nuevo juego de navegador listo para revisión. Pero este es el flujo de trabajo real detrás de Vibe Arcade — aproximadamente 25 juegos lanzados en seis semanas, de tres a cinco builds exitosos por semana. Algunos son genuinamente buenos. Algunos se descartan en la mañana. La parte interesante no es la IA. Es todo el andamiaje alrededor de la IA que evita que lance basura.
Este es un recorrido por ese andamiaje: qué corre, en qué orden, y qué se rompe.
De Dónde Vienen las Ideas de Juegos
Cada ejecución de pipeline empieza con un concepto. Los nuestros vienen de dos fuentes.
La primera es una lista curada de huecos de género — tipos de juego que están subrepresentados en el espacio de juegos de navegador gratis o que llenarían un hueco en nuestro catálogo. ¿Qué están buscando las personas? ¿Qué mecánicas clásicas no han recibido un tratamiento moderno HTML5? Es un documento vivo, no estático.
La segunda fuente son envíos comunitarios. Los jugadores sugieren ideas de juegos directamente, y otros usuarios votan por ellas. Las ideas más votadas son promovidas a la cola de entrada de la pipeline. Las personas que juegan los juegos tienen un canal directo para influir en qué se construye a continuación. Más sobre ese loop después.
Fase 1: Planificación (~10 Minutos)
La primera fase usa un modelo avanzado de planificación — una IA más lenta y más capaz que es buena razonando a través de problemas de diseño. Su trabajo es producir una spec detallada, no código: mecánicas del juego, esquema de control, dirección de diseño visual, curva de dificultad, layout de UI y requisitos de integración del leaderboard.
La spec es deliberadamente detallada porque la siguiente fase usa un modelo diferente, más rápido, que necesita instrucciones claras. La ambigüedad en la spec se convierte en bugs en la build. Una spec que dice "la dificultad aumenta con el tiempo" es peor que una que dice "la velocidad enemiga aumenta 8% cada 30 segundos, con un tope de 2x velocidad base." El trabajo del modelo de planificación es eliminar ambigüedad, no ser creativo.
Fase 2: Implementación (1-4 Horas)
Un modelo de implementación más rápido toma la spec y construye el juego. Para juegos directos, esta es una build de una sola pasada que toma una o dos horas. Para juegos complejos, múltiples sub-agentes trabajan en diferentes módulos en paralelo: loop central del juego, capa de UI, integración del leaderboard.
La salida es un juego HTML5 completo — HTML, CSS, JavaScript — corriendo en un navegador sin dependencias. Cada juego incluye soporte móvil, input de teclado y táctil, pantalla de inicio, flujo de game-over y cableado del leaderboard. El modelo de implementación sigue reglas de autoría que codifican todo lo que hemos aprendido sobre qué hace que un juego de Vibe Arcade funcione. Esas reglas se iteran constantemente — el modelo en el día uno estaba trabajando con un conjunto de instrucciones mucho más delgado que el que corre hoy.
Las Puertas de Calidad
Una build terminada no se lanza. Pasa por cuatro puertas — tres automatizadas, una humana. La IA es impresionante pero poco confiable. Las puertas son lo que hace la pipeline confiable.
Puerta 1: Lint Estructural
La primera comprobación automatizada es un conjunto de reglas de coincidencia de patrones que capturan errores estructurales y de cableado — un linter basado en grep específicamente diseñado para nuestro formato de juego. Cada juego debe llamar la integración del leaderboard correctamente, incluir ciertos elementos meta, y seguir patrones específicos para manejo de input y envío de puntuación.
Estas reglas son baratas de ejecutar y capturan los bugs más comunes — del tipo donde el juego funciona bien en aislamiento pero no se integra correctamente con el sitio. El conjunto de lint crece con el tiempo: cada nueva clase de bug de cableado obtiene una regla nueva. La primera versión tenía quizás cinco reglas; la versión actual tiene sustancialmente más. Esta es la puerta de calidad más efectiva por volumen de bugs reales capturados. Las comprobaciones estructurales son poco glamorosas y subvaloradas.
Puerta 2: Comprobaciones de Seguridad
Las comprobaciones de seguridad automatizadas corren contra cada build. También tenemos procesos adicionales de revisión manual de seguridad. Voy a dejar los detalles deliberadamente vagos aquí — describir qué buscan las comprobaciones es contraproducente. Existen, corren en cada build, y un humano revisa su salida.
Puerta 3: Rúbrica de Jugabilidad
La rúbrica de jugabilidad es un sistema de puntuación — aproximadamente 60 puntos a través de ocho categorías — que evalúa si vale la pena jugar el juego. Las categorías incluyen:
- Claridad del objetivo — ¿entiende el jugador inmediatamente qué está tratando de hacer?
- Rampa de dificultad — ¿se vuelve más difícil el juego a un ritmo que se siente justo?
- Respuesta de input — ¿se sienten ajustados los controles, especialmente en móvil?
- Calidad de feedback — ¿comunica el juego cambios de estado (puntuación, daño, power-ups) claramente?
- Completitud del loop — ¿hay un ciclo satisfactorio de jugar, fallar, reintentar?
Y tres categorías más cubriendo pulido visual, pistas de audio y motivación del leaderboard. Un juego necesita superar un umbral mínimo de puntuación para pasar.
Aquí radica la debilidad, y quiero ser directo al respecto: la IA puntúa su propio trabajo. La misma clase de modelo que construyó el juego evalúa si el juego es bueno. Esto es pedirle al estudiante que califique su propio examen. Un juego que un humano honestamente calificaría 40/60 podría puntuarse a sí mismo 55. La rúbrica captura juegos genuinamente rotos pero es menos fiable distinguiendo "técnicamente funcional pero aburrido" de "realmente divertido." Hemos ajustado los criterios varias veces y añadido condiciones de puntuación negativa para modos específicos de fallo. Pero hoy, la rúbrica es la puerta automatizada más débil, y lo sabemos.
Puerta 4: El Humano
Un humano revisa cada pull request antes de mergear. Cada uno. Esta es la puerta más importante en la pipeline y no es opcional.
La revisión matinal: abre el PR, lanza el juego, juégalo. ¿La curva de dificultad se siente divertida, no solo presente? ¿Funcionan los controles en un teléfono? Luego va a usuarios reales — familia, niños, amigos que no saben ni les importa cómo se construyó. "Esto es aburrido tras 30 segundos" es más valioso que cualquier puntuación automatizada.
Basándose en esa revisión, un juego se lanza, se envía de vuelta para arreglos específicos, o se descarta. La tasa de descarte es real. La pipeline es lo suficientemente barata como para que tirar una build fallida está bien. El trabajo del humano no es arreglar el trabajo de la IA; es juzgar si el trabajo vale la pena arreglarlo.
Auto-Merge vs. Triaje Matinal
Si las tres puertas automatizadas pasan por encima de sus umbrales, la build se auto-mergea. Si algo se marca, espera al triaje matinal — arréglalo, redirígelo a un concepto diferente, o descártalo. El ritmo real: de tres a cinco juegos exitosos por semana. "Exitoso" significa pasó todas las puertas, sobrevivió la revisión humana y se lanzó. El número total de ejecuciones de pipeline es más alto; algunas builds fallan automatización, algunas pasan automatización pero son rechazadas por un humano.
Arreglar una Vez, Arreglar en Todas Partes
Este es el principio que hace que la pipeline mejore con el tiempo en lugar de solo crecer.
Cada arreglo de bug se captura en un lugar compartido para que no pueda repetirse. Tres ubicaciones canónicas: estilos globales que cada juego hereda, reglas de lint contra las que cada build futura se verifica, y las instrucciones de autoría que sigue el modelo de implementación.
Ejemplo: los juegos tempranos tenían un problema de input táctil en tablets — los botones requerían un double-tap. El arreglo fue una sola regla CSS en la hoja de estilos global. Un commit, cada juego del sitio recibió el arreglo. Sin parches por juego. De forma similar, cuando encontramos juegos cableando ocasionalmente el envío del leaderboard incorrectamente, añadimos una regla de lint. Cada build futura ahora recibe esa comprobación automáticamente.
Este efecto compuesto es el multiplicador real de fuerza. El juego número 25 se construye sobre todas las lecciones de los juegos 1 al 24. Las reglas de autoría son más gruesas, el conjunto de lint es más grande, los estilos globales manejan más casos edge. Cada juego es ligeramente mejor que el anterior no porque la IA esté mejorando, sino porque los guardarraíles lo están.
Lo Que No Funciona
La honestidad requiere listar las cosas que esta pipeline no puede hacer bien, al menos no aún.
Arte de juego. La pipeline produce visuales basados en CSS — formas geométricas, efectos de partículas, la estética neon. No puede producir arte original de sprites o ilustraciones de personajes. Cada juego se ve como si perteneciera a la misma familia, lo que es simultáneamente una fortaleza de marca y una limitación artística.
Mecánicas novedosas. La IA es excelente ejecutando mecánicas de juego conocidas — snake, breakout, tower defense, juegos de tipeo. Es menos fiable inventando mecánicas genuinamente nuevas. Cuando la spec pide algo que no mapea a un género existente, el modelo de implementación se apoya en patrones familiares. La innovación aún requiere pensamiento humano de diseño.
Proyectos multi-sesión. La pipeline está optimizada para builds nocturnos únicos. Los juegos que necesitan múltiples ciclos build-test-iterate a lo largo de varios días son posibles pero incómodos — la pipeline pierde contexto entre sesiones. Nuestros juegos más complejos se construyeron parcialmente fuera de la pipeline con más dirección humana práctica.
Auto-evaluación. La pipeline no puede decirte fiablemente si un juego es divertido. Puede decirte que el juego está estructuralmente correcto, seguro, y cumple una lista de criterios de diseño. "Divertido" es un juicio humano. No estoy seguro de que pueda automatizarse.
El Loop Comunitario
La parte de este sistema que me parece más interesante no es la pipeline — es el ciclo de retroalimentación con las personas que juegan los juegos.
Los usuarios sugieren ideas. Otros votan. Las ideas más votadas entran a la pipeline. La pipeline las construye de noche. Los usuarios juegan los resultados, lo que provoca nuevas ideas, que se envían y se votan. El loop: sugerir, votar, construir, jugar, sugerir de nuevo.
Esto resuelve el problema más difícil en la pipeline: decidir qué construir. La IA puede construir casi cualquier cosa que especifiques. La pregunta es si alguien quiere jugarla. La votación comunitaria es un proxy imperfecto para la demanda, pero mejor que adivinar. Y cuando los usuarios ven sus sugerencias volverse juegos reales dentro de una semana, la tasa de sugerencias sube. El loop se acelera a sí mismo.
La contribución real de la pipeline no es velocidad — es que la brecha entre "alguien tiene una idea" y "alguien está jugando el resultado" es lo suficientemente corta para sostener un loop de retroalimentación. Lo suficientemente rápido para tirar una build mala e intentar un enfoque diferente mañana por la noche.
El Sistema Construye; el Humano Juzga
El desarrollo de juegos asistido por IA no es juegos generados por IA. La pipeline es aproximadamente 90% andamiaje y guardarraíles — reglas de lint, comprobaciones de seguridad, instrucciones de autoría, la rúbrica de jugabilidad, la infraestructura de arreglo global. La IA proporciona las manos rápidas. Las reglas acumuladas escritas por un humano son lo que evita que lance basura.
La pipeline es impresionante. Pero la parte más importante es la persona que juega el juego en la mañana, lo muestra a sus hijos, y decide si es realmente bueno. Esa parte no se automatiza.
Lectura relacionada: ¿Qué Es Vibe Coding? · Cómo Construimos Neon Snake Con IA · Herramientas de Vibe Coding: De Chatbots a IDEs con IA · Construyendo un Leaderboard Universal