El sistema de evidencia.
"Funciona" es un video.
Los agentes de IA construyen rápido — y también pueden decir "listo" cuando una función apenas compila. Este es el sistema de verificación que ejecutamos para atar cada afirmación de nuestros juegos a algo que puedes ver: grabaciones de la compilación real, capturas de mismo estado antes/después, y auditorías ligadas a revisiones exactas del código.
Por qué existe esto: en el desarrollo con agentes, la frase más barata es "funciona". El sistema de evidencia la vuelve cara: cada función aceptada debe publicarse con una grabación de ejecución, una comparación de mismo estado y una auditoría ligada al código — o se queda en la columna de "no probado" del tablero de estado.
El modo de fallo que esto arregla
Así se pudre en silencio el desarrollo de juegos con IA: un agente implementa una función, ejecuta las pruebas que él mismo escribió, declara éxito y sigue. Tres días después el sistema de guardado se rompe en un camino que nadie grabó. El código parecía correcto. Las pruebas pasaron. La afirmación nunca fue verdad — solo no había sido falsada.
Nuestra respuesta toma prestado del QA industrial en lugar del unit testing: la unidad de verificación es una grabación del juego en ejecución, no una marca verde.
Regla 1: ninguna afirmación sin evidencia de ejecución
Cada función que cuenta como terminada deja atrás una captura en tiempo real — una grabación sin cortes de una compilación real, recorriendo exactamente el camino que la función dice soportar. No una captura de un buen día; la interacción completa. Cuando decimos "el bucle de decisión de despacho funciona en un teléfono de 844×390", hay un video de 20 segundos donde puedes verlo: las unidades salen, la producción se pausa, las recompensas esperan en el gremio.
Esta sola regla cambia el comportamiento de los agentes más que cualquier prompt: un agente que sabe que debe producir una grabación visible deja de recortar esquinas que habrías descubierto una semana después.
Regla 2: capturas antes/después de mismo estado
Para cambios de interfaz y comportamiento, las capturas antes/después deben tomarse del mismo estado — mismo guardado, misma pantalla, mismo viewport — o no prueban nada. "Ahora se ve mejor" no significa nada si la foto de antes era partida nueva y la de después a mitad de progreso.
| Lo que atrapan las capturas de mismo estado | Lo que las capturas sueltas pierden |
|---|---|
| Deriva de diseño en otros tamaños de viewport | Todo lo que queda fuera de la única captura |
| Renderizado dependiente del estado (bloqueado/disponible/agotado) | Solo el estado "camino feliz" |
| Regresiones en interfaz adyacente que comparte el componente | Todo lo que el autor no estaba mirando |
En la práctica: congela el estado, captura cada tamaño de teléfono (320 → 430px, más modo de letra grande), cambia, y vuelve a capturar. La revisión del diff es mecánica — que es exactamente por qué funciona a escala de agentes.
Regla 3: auditorías ligadas al código
Evidencia sin revisión es un rumor. Cada lote aceptado recibe una auditoría que ata sus grabaciones y capturas a una revisión exacta del código — un hash, un commit, un manifiesto. Si el código se mueve después, la evidencia vieja no lo bendice en silencio; el lote se re-verifica o la afirmación se retira. Esto también es lo que hace posible el traspaso: un revisor puede comprobar que la compilación que mira es demostrablemente el código que produjo la evidencia.
El ciclo de vida del contenido (de nuestra propia tubería)
Cada pieza de contenido — evento, función, recurso — pasa por estados explícitos, y nada se salta un paso:
| Estado | Significado |
|---|---|
drafted | Escrito/generado |
validated | Referencias y números verificados |
integrated | Carga en el runtime |
rendered | Aparece en una pasada de render real con aserciones de diseño |
runtime-seen | Alcanzado por la entrada normal del jugador y renderizado |
manually-played | Un humano recorrió las ramas principales |
accepted | Pasó la puerta de calidad del capítulo |
Por eso nuestros tableros pueden decir "305 eventos renderizan limpio, y la afirmación de 20 horas de contenido no está aceptada todavía" en la misma frase — los estados son separados, y la tubería se niega a difuminarlos.
Regresión sobre toda la superficie
Todo sistema aceptado se congela como línea base: sus interfaces no pueden cambiar sin una actualización de contrato. Cada lote nuevo vuelve a ejecutar la suite de regresión en todos los viewports de teléfono y ambos modos de letra, y escanea errores de motor y fugas. Las suites son aburridas por diseño — su trabajo es atrapar la milésima rotura pequeña, no ser interesantes.
Lo que este sistema todavía no ve (sección honesta)
- Diversión. Nada aquí mide si el juego es disfrutable. La evidencia prueba comportamiento, no deleite.
- Feel. Los tiempos de animación y el "juice" pasan todas las verificaciones técnicas sintiéndose mal; solo un humano lo nota.
- Exploits nuevos. Las suites verifican caminos conocidos; los jugadores inventan nuevos. La simulación atrapa algunos; el playtesting atrapa el resto.
Por eso el sistema de evidencia es un piso, no un techo: garantiza que nada se publique roto, y deja el juicio de bueno donde corresponde — con los humanos.
Cómo empezar pequeño
- Elige una función — algo con un flujo visible, como menú → acción → resultado.
- Grábala una vez, sin cortes — una captura en tiempo real de la compilación real, no un screencast re-timed.
- Congela un par antes/después — mismo estado, dos tamaños de teléfono.
- Átala a una revisión — incluso un nombre de archivo con el hash del commit es mejor que nada.
Ese es todo el sistema en miniatura. Todo lo demás — estados de ciclo de vida, líneas base de regresión, auditorías — es este patrón escalado. Pruébalo en tu próxima función; la primera regresión que atrapes pagará el hábito.
¿No es demasiado lento grabar cada función?
Es más rápido que depurar a ciegas. Una grabación de 20 segundos tarda menos en producirse que escribir una suite de pruebas exhaustiva — y a diferencia de las pruebas, no puede pasar mientras el juego está visiblemente roto. Lo lento es hacerlo después de saltárselo.
¿Pueden los agentes revisar la evidencia ellos mismos?
En parte — los agentes pueden mirar grabaciones, comparar capturas y marcar diferencias mecánicamente. Eso es la mayor parte del volumen. La revisión humana se concentra en el gusto y los casos límite, que es exactamente donde vale la pena gastar tiempo humano.
¿Reemplaza esto a las pruebas unitarias?
No — son capas. Las pruebas unitarias verifican la lógica en aislamiento; el sistema de evidencia verifica el juego en ejecución. El código generado por IA se beneficia de ambas, porque pasar pruebas es barato de falsificar por accidente y grabar un juego funcionando no lo es.