Agentes de IA descompilaron un shooter en tres meses y gastaron hasta 700 mil millones de tokens

Un grupo de entusiastas dirigió durante tres meses a agentes de IA que descompilaron un popular shooter en primera persona y reconstruyeron su código en C++. Según el autor del proyecto, se ha recuperado el 99% de las funciones, el 83% de ellas coincide byte a byte con el original y el juego funciona sin errores apreciables. El autor estima el consumo en 600–700 mil millones de tokens. Relató la historia en Habr, y el foco está en la orquestación de los agentes, no en el juego en sí.

La precisión como requisito

El objetivo era obtener una reconstrucción exacta y estable, no demostrar que los agentes son capaces de hacerlo. La diferencia es fundamental. Cuando solo se busca algo «parecido en comportamiento», el agente puede producir código verosímil y no hay forma de comprobarlo. Cuando se necesita un código comparable con el original a nivel de bytes, cada función recibe un veredicto inequívoco: coincide o no coincide.

Esa es la tesis central del autor: sin una verificación objetiva y automática, este esquema no funciona. Un agente cuyo trabajo se evalúa a ojo, o con otra red neuronal, acumula errores a lo largo de semanas y avanza con seguridad en la dirección equivocada. El compilador y la comparación byte a byte no discuten ni se cansan.

La escala en cifras

Hagamos las cuentas a partir de los datos declarados. 600–700 mil millones de tokens en tres meses, es decir, unos 90 días, equivalen a entre 6,7 y 7,8 mil millones de tokens al día. Por segundo, son de media entre 77 y 90 mil tokens de forma continua, de día y de noche. Una persona no puede alcanzar ese ritmo en ningún caso. Solo es posible con muchos agentes trabajando en paralelo, y eso exige infraestructura: colas de tareas, aislamiento de entornos, control de costes y reinicio automático.

Resultados finales del proyecto:

• duración: unos tres meses;
• consumo: 600–700 mil millones de tokens (estimación del autor);
• funciones recuperadas: 99%;
• coincidencia byte a byte con el original: 83% de las recuperadas, es decir, alrededor del 82% del total de funciones;
• resultado: el juego se ejecuta y funciona sin errores apreciables.

Quedan en torno al 17% de las funciones que no coincidieron byte a byte. Algunas de ellas pueden comportarse de forma idéntica, aunque se compilen de otra manera. En un proyecto cuyo objetivo es la precisión, esa es la zona que queda por pulir.

El papel de las personas

El autor subraya que los agentes estaban dirigidos por miembros de la comunidad. Aquí, autonomía no significa ausencia de supervisión: la persona fija el marco y vigila las métricas en lugar de leer cada línea. El autor detalla la infraestructura y los ajustes en el artículo original. Nos basamos únicamente en su parte introductoria y no especulamos sobre los detalles de la implementación.

Qué conviene aprovechar

Primero: elija tareas cuyo resultado pueda verificar una máquina. La descompilación con comparación byte a byte, la migración de código con un conjunto de pruebas y la optimización con un benchmark pertenecen a esta clase. Las tareas del tipo «hazlo bonito» no.

Segundo: incluya el presupuesto de tokens como una partida de gasto. Cientos de miles de millones de tokens ya son una cuestión de planificación financiera, no un experimento de fin de semana.

Tercero: mida la tasa de éxito por funciones, módulos o pruebas, no por impresiones. Una métrica como «83% coincide» permite decidir si merece la pena lanzar otra ronda de trabajo de los agentes o si ha llegado el momento de poner a una persona con la cola de casos restantes.

Cuarto: revise el aspecto legal. La descompilación de software comercial depende de la licencia y de la jurisdicción, y que sea técnicamente posible no resuelve esa cuestión.