Acerca de Vibe Arcade

Vibe Arcade es un experimento de una sola persona, iniciado a principios de 2026, para averiguar hasta dónde se puede llevar a los modelos de IA actuales en trabajos de software reales y de larga duración — y, igual de importante, dónde están los puntos débiles y dónde una persona todavía tiene que intervenir. Los juegos son la prueba: si el proceso no produce algo que de verdad valga la pena jugar, el experimento ha fracasado.

El planteamiento: un pipeline nocturno planifica un nuevo juego HTML5 a partir de una especificación escrita, lo programa, ejecuta lint, seguridad y una rúbrica de jugabilidad, y solo lo registra si supera todos los filtros. Si algo falla, lo reviso por la mañana. Hasta ahora han salido de aquí más de 100 juegos jugables. Todos son gratis en el navegador — sin registro, sin instalación, sin captura de correo electrónico.

El segundo resultado es un conjunto de notas continuas: con qué me sorprendió la IA, dónde falló de forma silenciosa, qué mejoró entre versiones del modelo y qué tareas le confío ahora frente a aquellas en las que mantengo una revisión humana estricta. Las publico como artículos del tipo «cómo lo construimos» en el blog. Cada uno es un punto de datos, y cada uno cuenta lo que salió mal tanto como lo que funcionó.

Los benchmarks son fáciles de manipular; cien juegos que gente desconocida se pone a jugar de verdad es una prueba más difícil, y más honesta.

Aquí el código lo escribe la IA, todo él. Ni una sola línea de lo que se ejecuta en este sitio la ha tecleado una persona, y ese es el objetivo del proyecto, no algo que esconder. Lo que hace una persona es decidir: qué se construye, cuál es el listón, si una compilación lo supera y qué hacer cuando no. Cuando algo falla, lo diagnostico y le digo a la IA qué cambiar; no entro yo a parchearlo, porque un arreglo hecho a mano sería incumplir el experimento en silencio. «Hecho con IA» no es un estándar de calidad, así que este es el que rige de verdad en este sitio.

• Nada se construye sin una especificación escrita. Género, controles, fórmula de puntuación, condiciones de victoria y derrota y una comprobación de marcas registradas quedan fijados por escrito antes de generar una sola línea de código. Los conceptos salen de mí o de las propuestas más votadas del tablón de ideas de los jugadores.
• Cada compilación se puntúa con una rúbrica de jugabilidad de 60 puntos que cubre jugabilidad, apartado visual, si de verdad es divertido, integración, móvil y calidad del código. El objetivo para publicar es 58 sobre 60, y una versión que no llega sigue iterando. La única excepción es el final de una noche de construcción: antes que perder el trabajo, un juego puede publicarse con un mínimo de 53 y terminarse en la pasada de mejoras semanal. Algunas versiones nunca alcanzan el listón y se descartan.
• Los filtros automáticos se ejecutan antes de que una persona lo mire — un lint estructural, un escaneo de seguridad en dos niveles, un análisis de sintaxis de JavaScript y una prueba real en un navegador sin interfaz que carga el juego y tumba la compilación ante cualquier error no capturado o un botón de inicio que lanza una excepción.
• Una persona revisa a mano cada fallo a la mañana siguiente. Todo lo que toque la arquitectura compartida, todo lo sensible en cuanto a contenido y todo lo que pudiera fallar de forma silenciosa en producción se retiene para revisión manual, sin importar la puntuación.
• Los juegos se juegan, y se retiran cuando no se sostienen. Las pruebas de juego con personas son lo único que detecta el «funciona técnicamente, pero no es divertido». Varios juegos se han rehecho o retirado después de esa pasada, y además hay una pasada de mejora semanal sobre los juegos que ya están publicados.
• Cuando algo sale mal, se cuenta con nombre y apellidos. Una versión de crucigrama llegó a QA con relleno que no eran palabras reales en inglés — validaba como datos y el lint pasaba, y lo único que lo detectó fue el paso de QA que resuelve el crucigrama de verdad. Se corrigió antes de publicarse, y todo el episodio está en el blog, porque los fallos son la parte útil.

El sitio lo lleva una sola persona. Si encuentras algo roto, equivocado o injusto, escríbeme — leo todo lo que llega, y prefiero enterarme por ti que no enterarme.

Tres preguntas abiertas impulsan el experimento:

El pipeline es el aparato experimental. Cada juego pasa por la misma secuencia de filtros; los resultados se acumulan entre ejecuciones porque cada juego se construye sobre la misma infraestructura compartida (CSS, widget de leaderboard, lint de integración).

Un pipeline de mejora aparte se ejecuta un par de veces por semana para profundizar en los juegos ya existentes — así es como los juegos crecen más allá de su compilación nocturna inicial.

Observaciones concretas de lo que va del experimento, no abstracciones:

• La IA escoge la arquitectura estructural sin que se lo pidan, y a menudo escoge bien. Path Runner se publicó con un modelo de pista procedural segmentada que yo nunca especifiqué — los segmentos aparecen por delante del jugador y desaparecen por detrás. Resulta que esa es justo la respuesta correcta para un endless runner, porque esquiva los límites de memoria del navegador. Mini Cross publicó la iteración 4 con una escalera de celebración de rachas en seis niveles que nunca pedí. Deadlock propuso, en un único commit, distribuciones de salas estrechas al estilo de Castle Doombad cuando la especificación apenas decía nada sobre geometría.
• Los fallos de calidad de contenido se cuelan por el lint estructural. La iteración 1 de Mini Cross se publicó con respuestas de crucigrama que no eran palabras reales en inglés — pasaron la validación como datos y superaron el lint, pero solo un humano (o la pasada de resolución del crucigrama dentro del filtro de QA) podía detectarlo. Lint y seguridad verifican la forma; no pueden verificar el significado.
• Arreglar una vez de forma global da intereses compuestos. Una sola regla CSS en main.css solucionó la respuesta al toque en tabletas en los más de 20 juegos con un solo commit, en lugar de 20 ediciones, una por juego. Pasar de una interfaz de chat (donde cada juego se construía de forma independiente) a un pipeline unificado es lo que hizo posible que el CSS compartido, un widget universal de leaderboard y las convenciones estructurales fueran consistentes en cada nueva compilación.
• Las mecánicas realmente novedosas todavía necesitan mucho QA humano. Cuando soy específico sobre cómo debe verse un juego y cómo funcionan sus reglas, el bucle suele cerrarse en 3 o 4 iteraciones. Cualquier cosa en la que haya que inventar las reglas requiere muchas más pasadas — y las pruebas de juego con personas reales son lo único que detecta el modo de fallo del «esto funciona técnicamente, pero no es divertido».
• El «vibe coding» sobrevende los prompts e infravalora las reglas. El pipeline es aproximadamente un 90% andamiaje y barandillas. La IA pone las manos rápidas; las reglas que escribí (la rúbrica, el lint, las convenciones estructurales) son lo que evita que publique basura. El «vibe coding» da a entender que las vibras van primero; esto es reglas primero, IA ejecutando rápido.

Si te interesan los escritos más largos, muchos de los juegos tienen un artículo del tipo «cómo lo construimos» en el blog con lo que me sorprendió, lo que falló y lo que cambió entre iteraciones.

Unas cuantas aclaraciones honestas, ya que la etiqueta de «experimento» puede resultar ambigua:

• Gratis para los jugadores. Sin registro, sin cuenta, sin captura de correo electrónico, sin compras integradas y sin muro de pago. Los leaderboards funcionan con un nombre elegido por juego.
• Se financia con publicidad. El sitio muestra publicidad gráfica para cubrir el alojamiento y mantener los juegos gratis. Los anuncios nunca se colocan dentro del área de juego y no hay nada bloqueado detrás de ver uno. Qué hacen las cookies publicitarias, y cómo puedes desactivarlas, está explicado en la política de privacidad.
• Una sola persona: J. Sin equipo, sin estudio, sin inversores. El «nosotros» de versiones anteriores de esta página era aspiracional; ya está corregido.
• El pipeline es de código cerrado. El pipeline es el aparato experimental, y compartirlo sustituiría las reproducciones independientes por una única base de código común — colapsando la señal de comparación de la que depende el experimento. La arquitectura se describe arriba y en el blog; la implementación es privada.
• Qué haré con lo que aprenda. Servirá para decidir en qué tareas me apoyo en la IA en mi día a día — aquellas en las que es realmente buena, y para tener cuidado al delegarle trabajo donde lo que hay en juego es mayor y el modo de fallo es más difícil de detectar.