Acerca de Vibe Arcade — Un Experimento en Programación Autónoma con IA

Qué Es Esto

Vibe Arcade es un experimento de una sola persona, iniciado a principios de 2026, para averiguar qué pueden hacer realmente los modelos de IA actuales de forma autónoma 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 un humano todavía tiene que intervenir.

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

Los juegos en sí son un producto secundario. El resultado real es un conjunto de notas continuas: con qué me sorprendió la IA, dónde falló de forma silenciosa, qué mejoró entre versiones del modelo, qué tipo de tareas le confío ahora frente a aquellas en las que todavía 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 dentro del experimento más amplio.

Los benchmarks son fáciles de manipular; este sitio es un intento de generar una señal real de seguimiento en su lugar.

Lo Que Estoy Intentando Averiguar

Tres preguntas abiertas impulsan el experimento:

1. ¿Cuánto de un proyecto de software no trivial puede manejar la IA de forma autónoma?

Juego a juego, ¿qué fracción del trabajo supera cada filtro sin intervención humana? Tras ocho semanas, más noches publican limpiamente de las que no — pero los modos de fallo siguen siendo informativos cuando ocurren.

2. ¿Dónde aparecen los puntos débiles — y cómo cambian a medida que los modelos mejoran?

Algunas categorías de fallo se repiten (calidad de contenido que pasa el lint estructural, mecánicas novedosas que necesitan muchas pasadas de QA humano, problemas de iframe entre entornos). Hacer un seguimiento a lo largo de las versiones del modelo me dice qué está mejorando realmente en la práctica, no en los benchmarks.

3. ¿Dónde sigue siendo necesario que intervenga un humano?

El auto-merge supera seguridad, lint y la rúbrica de jugabilidad. Mantengo la revisión manual para todo lo que toque la arquitectura central, todo lo sensible a la calidad del contenido y todo lo que pudiera fallar de forma silenciosa en producción. La frontera entre esas categorías se sigue moviendo a medida que mejoran la rúbrica y los filtros de lint.

Cómo Funciona el Pipeline

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).

1. Especificación

Un modelo de planificación escribe una especificación detallada a partir del concepto — género, tema, fórmula de puntuación, lista de integración, nombres, notas sobre marcas registradas. O bien soy yo quien escribe el concepto, o tomo la propuesta más votada del tablón de ideas del sitio.

2. Andamiaje + iteración

Los modelos de implementación construyen el juego por iteraciones. Cada iteración ejecuta una rúbrica de QA de 60 puntos (jugabilidad, apartado visual, diversión, integración, móvil, código) y deja comentarios para la siguiente pasada. La mayoría de juegos superan el umbral de 56 puntos en 3 o 4 iteraciones.

3. Filtro de lint (basado en grep)

Reglas estructurales: conexión del leaderboard, dimensiones del canvas, etiquetas del schema, prohibición de ciertos imports, etc. Grep es aproximadamente 10× más barato que una pasada del modelo y detecta una cantidad sorprendente de problemas — así que el pipeline ejecuta lint primero y solo gasta tokens del modelo en aquello que grep no puede comprobar.

4. Filtro de seguridad (en dos niveles)

Primero las categorías universales (las del estilo OWASP), después una capa específica del proyecto orientada a la infraestructura concreta que usa este sitio. La capa específica del proyecto detecta más problemas reales que la universal — los modelos genéricos pueden pasar por alto patrones propios del framework.

5. Rúbrica de jugabilidad y decisión de publicación

Pasada de puntuación final. Si la puntuación supera el umbral y todos los filtros están en verde, la compilación se fusiona automáticamente. Si algo falla, la ejecución pasa a revisión manual por la mañana.

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.

Lo Que He Encontrado Hasta Ahora

Tras ocho semanas. Observaciones concretas, 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, cada juego tiene 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.

Gratis, Solo, Código Cerrado

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 anuncios, sin compras integradas y sin muro de pago. Los leaderboards funcionan con un nombre elegido por juego.
Una sola persona. 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.