Un equipo se la jugó por lo que muchos siguen callando: soltar agentes de IA autónomos durante tres meses seguidos para decompilar un shooter popular a C++. El balance final, contado sin maquillaje, es una de las cosas más honestas que he leído sobre orquestación de agentes: gastaron entre 600 y 700 mil millones de tokens, lograron que el juego partiera, cargara mapas y mostrara el menú… y después descubrieron que gran parte del código estaba semánticamente mal. Se veía progreso. No lo era.
El mes perfecto que era una mentira
El arranque fue de manual: 4 agentes en paralelo (tres ejecutando, uno revisando), issues de GitHub por cada archivo del juego, un canal de Discord donde los agentes conversaban entre ellos y con humanos, un webhook que avisa cuando el CI explota. Con todo eso, decompilaron el 80% del juego en el primer mes. Si miras la métrica de avance, es un rotundo éxito.
El problema apareció cuando miraron el contenido: firmas de función inventadas, layouts de structs equivocados, lógica agregada o eliminada «porque parecía innecesaria». Mi ejemplo favorito, porque es puro agente: el juego guardaba variables de configuración en memoria constante, y los agentes las convirtieron en tablas hash con un costo de búsqueda órdenes de magnitud peor. Compilaba. Corría. Estaba mal.
Cuando lo notaron, intentaron rescatar el código. Error: les costó más tiempo salvarlo que botarlo y empezar de cero. Es la lección más incómoda del post, y la que más veces voy a repetir internamente: ahora que generar código es barato, aferrarse a código malo por avión es tirar plata. Botarlo es la decisión técnica correcta.
El detalle que muchos se saltarán: las instrucciones caducan
De todos los ajustes de infraestructura, el que me parece más transferible es uno chico: los agentes perdían el foco con el paso del tiempo. Avanzaban una función, la saltaban a la mitad, se ponían a mirar el CI de ocio. En modo interactivo lo corriges al tiro; en modo autónomo, nadie está mirando. La solución fue escribiendo un documento con objetivos, reglas y protocolos, y un cron cada una hora que les inyecta de nuevo el documento al contexto para que las instrucciones no se pudran entre compactaciones.
Yo hago algo parecido con mis flujos automatizados, y lo confirmo: el contexto de un agente es como el marlín de una faena, si no lo estiras cada rato se flojea. Da pereza aceptar que hay que re-recordar las instrucciones cada hora a una máquina, pero es la diferencia entre un agente que avanza y uno que se pasea.
Lo que me dejo pinche
Honestidad ante todo: sin validación dura, el progreso miente. Un juego que parte no es la prueba de que la decompilación funcionó; es solo la prueba de que corre. La métrica de avance (80% de archivos procesados) no dice nada de la calidad del contenido procesado. Si delegas código a agentes —yo lo hago todos los días— la pega valiosa es el review y la verificación, no supervisar tokens por minuto.
Y un bonus que da risa con rabia: con 15+ agentes, los cabros borraban la VM completa periódicamente con comandos mal formados. Perdieron hasta los logs de sesión por eso. La capa siguiente de este negocio no es un modelo más inteligente: es sandboxing decente y verificación automática. Sin eso, cada agente autónomo es un becario con acceso root y sin sueño.
Fuente del tema: 500+ Billion Tokens Later: Letting AI Agents Decompile A First-Person Shooter, de Maurice y equipo.
Fuente de inspiración: 500+ Billion Tokens Later: Letting AI Agents Decompile A First-Person Shooter
