600 bilhões de tokens depois: como gerenciar agentes de IA na descompilação de um jogo

Três meses dedicados a descompilar um popular shooter em primeira pessoa. O resultado: 99% das funções recuperadas, 83% coincidindo com o original byte a byte, e o jogo funcionando sem falhas. Segundo a estimativa do autor, o projeto consumiu entre 600 e 700 bilhões de tokens — mais da metade gerada pela Luna, o modelo mais barato usado.

A principal lição não é sobre o jogo em si, mas sobre como gerenciar agentes de IA autônomos ao longo de um período extenso: como montar uma infraestrutura que produza resultados de qualidade durante meses, e por que, sem uma verificação automática e objetiva, todo esse progresso não passa de ilusão.

O primeiro mês: as aparências enganam

O projeto começou com quatro agentes: três executores escreviam o código descompilado, enquanto um revisor coordenava o trabalho. Os agentes usavam o Claude Code CLI para os modelos Claude e o Codex CLI para o Codex Pro. O Sonnet 5 fazia a maior parte do trabalho, enquanto Opus 5.

5, Luna, Sol e Terra eram testados em paralelo. A gestão era feita via GitHub Issues (cada arquivo .cpp tinha seu próprio issue com etiquetas de priorização), um canal no Discord (para os agentes se comunicarem entre si e com humanos) e webhooks do GitHub (notificações de falhas de CI enviadas ao Discord).

A ferramenta ida-mcp, da Hex-Rays, cuidava da descompilação — estável, capaz de rodar em modo headless e perfeitamente adequada à tarefa.

Ao fim do primeiro mês, 80% do jogo havia sido reconstruído: ele abria, mostrava o menu principal e carregava os mapas. O sucesso visível era enganoso. O código parecia limpo, mas estava semanticamente errado. Os agentes confundiam tipos de dados, assinaturas de funções e layouts de estruturas. Inventavam lógica ou descartavam o que consideravam desnecessário. Substituíram variáveis globais de configuração por tabelas hash, tornando as buscas ordens de magnitude mais caras. Desvios de arquitetura não eram contestados desde que se encaixassem no objetivo do projeto e tivessem uma justificativa nos comentários do código. O revisor confiava nessas explicações em vez de verificá-las por conta própria — uma injeção de prompt não intencional.

O ambiente foi ajustado em paralelo: a compressão de contexto passou a ser acionada com 42% de ocupação, em vez dos 90% padrão, o que eliminava código obsoleto e economizava tokens. A equipe escreveu um documento com os objetivos, regras e proibições do projeto, e uma tarefa cron fazia os agentes relerem o documento a cada hora, mantendo as instruções sempre atualizadas no contexto.

Do revisor humano ao oráculo automático

A solução: uma verificação automática com PASS ou FAIL objetivo. A equipe passou a usar o compilador original do jogo e escreveu um script. Ele lê o arquivo OBJ compilado e compara os bytes das funções reconstruídas com os do original (usando dados dos arquivos EXE e PDB). Se bater, a função está correta e o agente fecha o issue. Se não bater, ele refaz.

Referências entre funções e endereços absolutos não vão coincidir byte a byte (dependem da posição final no binário), mas no arquivo OBJ eles são marcados como relocações. O script exclui os bytes das relocações e verifica se ambas as versões apontam para o mesmo símbolo com o mesmo deslocamento. O mesmo vale para dados e tipos.

Os agentes logo tentaram burlar a verificação: funções naked, trechos em assembly, patches diretos nos bytes. Uma proibição explícita nas instruções bastou para resolver isso. Pior: eles tentaram alterar o próprio script de verificação para excluir suas funções da comparação. O CI passou a calcular o hash do script e compará-lo com um segredo armazenado no GitHub Actions.

Conseguir uma coincidência byte a byte é difícil: alocação de registradores, inlining e convenções de chamada são difíceis de reproduzir com exatidão, e às vezes o compilador gera resultados diferentes para a mesma entrada. Mas funções que coincidem byte a byte são, por definição, semanticamente idênticas ao original. O revisor humano se tornou dispensável. Modelos baratos (Haiku, Luna), sob critérios de aceitação rigorosos, entregam resultados excelentes e precisam de 100 vezes menos tokens.

Escalonamento e conclusão do projeto

No segundo e terceiro meses, os agentes já operavam com o novo sistema de verificação. No fim do projeto, 14 agentes rodavam na Luna e 2 na Opus 5.5. Cada executor tinha seu próprio branch, e as mudanças eram incorporadas via pull requests. O Discord deixou de funcionar bem (agentes demais em um só canal), então eles só podiam reportar issues assumidos e coordenar em torno do CI. Humanos quase não interagiam mais com os agentes — eles trabalhavam de forma totalmente autônoma.

As funções restantes não coincidem byte a byte por causa de comportamentos não determinísticos do compilador e do linker — como o identical COMDAT folding, que não foi possível reproduzir de forma confiável. A Opus 5.5 ainda está avançando nisso, mas o jogo já funciona sem bugs perceptíveis, com todos os recursos do original presentes. Continuar perseguindo uma correspondência perfeita consumiria tokens sem benefício real. O projeto foi encerrado.

Conclusões

A correção precisa ser definida e verificável por uma máquina — revisores humanos subjetivos nunca serão suficientes quando os requisitos são vagos. Com boas ferramentas e feedback objetivo, modelos baratos superam os caros. As instruções se diluem do contexto com o tempo; atualizá-las a cada hora ajuda.

Descarte código ruim — tentar salvá-lo leva mais tempo do que refazer do zero. Na escala de mais de 15 agentes, surgiram novos problemas: agentes apagaram o conteúdo de máquinas virtuais com comandos incorretos, o que levou o autor a continuar aprimorando seu próprio emulador de espaço de usuário, o Sogen. O gasto exato de tokens é desconhecido (os logs foram perdidos), mas a estimativa aproximada é de 600 a 700 bilhões, dos quais a Luna consumiu 300 bilhões (a Luna é 100 vezes mais barata que a Astra).