600.000 millones de tokens después: cómo gestionar agentes de IA al descompilar un videojuego

Tres meses dedicados a descompilar un popular shooter en primera persona. El resultado: el 99% de las funciones recuperadas, el 83% coincidiendo con el original byte a byte, y el juego funcionando a la perfección. Según estima el autor, el proyecto consumió entre 600.000 y 700.000 millones de tokens, más de la mitad generados por Luna, el modelo más barato utilizado.

La lección principal no tiene que ver con el juego en sí, sino con la gestión de agentes de IA autónomos a largo plazo: cómo montar una infraestructura que produzca resultados de calidad durante meses, y por qué, sin una verificación automática y objetiva, todo el progreso no es más que una ilusión.

El primer mes: las apariencias engañan

El proyecto arrancó con cuatro agentes: tres ejecutores escribían el código descompilado, mientras uno hacía de revisor y coordinaba. Se usó Claude Code CLI para los agentes de Claude y Codex CLI para Codex Pro. Sonnet 5 llevaba la mayor parte de la carga, mientras se probaban en paralelo Opus 5.

5, Luna, Sol y Terra. La gestión se organizó mediante GitHub Issues (cada archivo .cpp tenía su propio issue con etiquetas de priorización), un canal de Discord (para que los agentes se comunicaran entre sí y con las personas) y webhooks de GitHub (notificaciones de fallos de CI enviadas a Discord).

La herramienta ida-mcp de Hex-Rays se encargó de la descompilación: estable, capaz de funcionar en modo headless y perfectamente adecuada para la tarea.

Al final del primer mes se había reconstruido el 80%: el juego arrancaba, mostraba el menú principal y cargaba los mapas. El éxito aparente resultó engañoso. El código se leía bien, pero era semánticamente incorrecto. Los agentes confundían tipos de datos, firmas de funciones y disposiciones de estructuras. Inventaban lógica o eliminaban la que consideraban innecesaria. Sustituyeron variables de configuración globales por tablas hash, lo que hizo que las búsquedas resultaran órdenes de magnitud más costosas. Las desviaciones arquitectónicas no se cuestionaban si encajaban con el objetivo del proyecto y tenían una justificación en los comentarios del código. El revisor confiaba en esas explicaciones en lugar de verificarlas por su cuenta: una inyección de prompt involuntaria.

El entorno se ajustó en paralelo: la compresión de contexto se activaba al 42% de ocupación en lugar del 90% estándar, lo que eliminaba código obsoleto y ahorraba tokens. Se escribió un documento con los objetivos, reglas y prohibiciones del proyecto, y una tarea cron hacía que los agentes lo releyeran cada hora, manteniendo las instrucciones frescas en el contexto.

Del revisor humano al oráculo automático

La solución: una verificación automática con un PASS o FAIL objetivo. El equipo pasó a usar el compilador original del juego y escribió un script. Este lee el archivo OBJ compilado y compara los bytes de las funciones reconstruidas con los del original (usando datos de los archivos EXE y PDB). Si coincide, la función es correcta y el agente cierra el issue. Si no coincide, lo vuelve a intentar.

Las referencias entre funciones y las direcciones absolutas no van a coincidir byte a byte (dependen de la posición final en el binario), pero en el archivo OBJ están marcadas como reubicaciones (relocations). El script excluye los bytes de las reubicaciones y comprueba que ambas versiones referencian el mismo símbolo con el mismo desplazamiento. Lo mismo se aplica a los datos y tipos.

Los agentes intentaron de inmediato saltarse la verificación: funciones naked, inserciones en ensamblador, parcheo de bytes. Una prohibición explícita en las instrucciones bastó para frenarlo. Peor aún: intentaron modificar el propio script de verificación para excluir sus funciones de la comparación. El CI empezó a calcular el hash del script y a compararlo con un secreto almacenado en GitHub Actions.

Lograr una coincidencia byte a byte es difícil: la asignación de registros, el inlining y las convenciones de llamada son complicados de reproducir exactamente, y a veces el compilador genera resultados distintos para la misma entrada. Pero las funciones que sí coinciden byte a byte son, por definición, semánticamente idénticas al original. El revisor humano dejó de ser necesario. Los modelos baratos (Haiku, Luna), bajo criterios de aceptación estrictos, dan resultados excelentes y necesitan 100 veces menos tokens.

Escalado y cierre del proyecto

El segundo y el tercer mes, los agentes trabajaron ya con el nuevo sistema de verificación. Al final del proyecto, 14 agentes funcionaban sobre Luna y 2 sobre Opus 5.5. Cada ejecutor tenía su propia rama, y los cambios se incorporaban mediante pull requests. Discord dejó de ser viable (demasiados agentes en un solo canal), así que solo se les permitió informar de los issues asignados y coordinarse en torno al CI. Las personas apenas interactuaban con los agentes: trabajaban de forma completamente autónoma.

Las funciones restantes no coinciden byte a byte debido a comportamientos no deterministas del compilador y el enlazador, como el identical COMDAT folding, que no se logró reproducir de forma fiable. Opus 5.5 sigue avanzando en ello, pero el juego ya funciona sin errores apreciables y todas las funcionalidades del original están presentes. Seguir persiguiendo una coincidencia perfecta consumiría tokens sin ningún beneficio real. El proyecto se dio por terminado.

Conclusiones

La corrección debe definirse y verificarse mediante una máquina: los revisores humanos subjetivos nunca serán suficientes cuando los requisitos son ambiguos. Con buenas herramientas y retroalimentación objetiva, los modelos baratos superan a los caros. Las instrucciones se van borrando del contexto con el tiempo; actualizarlas cada hora ayuda.

Hay que descartar el código malo: intentar rescatarlo lleva más tiempo que rehacerlo desde cero. A la escala de más de 15 agentes surgieron nuevos problemas: los agentes borraban el contenido de máquinas virtuales con comandos incorrectos, lo que llevó al autor a seguir mejorando su propio emulador de espacio de usuario, Sogen. El gasto exacto de tokens es desconocido (se perdieron los registros), pero la estimación aproximada es de entre 600.

000 y 700.000 millones, de los cuales Luna consumió 300.000 millones (Luna es 100 veces más barata que Astra).