Como agentes de IA consumiram 500 bi de tokens para recriar um FPS

Durante três meses de trabalho contínuo e um volume massivo de tokens consumidos em modelos avançados, o engenheiro de software Maurice Heumann liderou um projeto voltado à engenharia reversa autônoma: descompilar integralmente o código-fonte de um clássico jogo de tiro em primeira pessoa (FPS) para C++ legível e funcional. Desenvolvida com a colaboração dos pesquisadores RektInator, Future, st0rm e membros da comunidade técnica, a iniciativa buscou ir além de uma simples prova de conceito, almejando uma reconstrução exata e estável do binário original. O título específico do game não pôde ser revelado publicamente devido à intervenção direta de corporações norte-americanas, que inclusive motivaram a exclusão de dois artigos anteriores no blog pessoal de Heumann.

Mais do que focar no jogo em si, o relatório técnico publicado por Maurice Heumann detalha a mecânica de infraestrutura e orquestração necessária para manter agentes autônomos operando por meses a fio. Para viabilizar a empreitada, a equipe combinou assinaturas corporativas de ponta, rodando instâncias de Claude Max (20x) e Codex Pro de maneira simultânea. Ao longo do experimento, diversos modelos foram colocados à prova no pipeline: o Sonnet 5 foi utilizado na maior parte das tarefas, mas sistemas como Opus 5.5, Luna, Sol e Terra desempenharam funções críticas em diferentes etapas da linha de produção.

A operação dispensou plataformas proprietárias complexas de orquestração externa, optando por ferramentas nativas em linha de comando: agentes Claude foram executados diretamente no Claude Code CLI, enquanto as instâncias de Codex rodaram sob o Codex CLI. Toda a extração estática do binário foi ancorada no plugin oficial ida-mcp, desenvolvido pela Hex-Rays, cuja arquitetura estável e suporte nativo em modo headless garantiram a desmontagem de funções e o fornecimento contínuo de dados estruturados para os agentes de software.

A arquitetura inicial do projeto

A gestão das demandas de desenvolvimento foi organizada por meio de automações no GitHub CLI. Cada unidade de tradução do código — ou seja, cada arquivo individual com extensão .cpp — recebeu uma issue dedicada dentro do repositório, com rótulos e etiquetas específicas para priorizar e agrupar tarefas pendentes. Essa padronização permitiu que os modelos determinassem com precisão o escopo imediato de atuação sem depender de comandos manuais contínuos dos operadores humanos.

Para a camada de comunicação em tempo real, a equipe estruturou um servidor no Discord. Todos os agentes compartilhavam um único canal centralizado com permissões completas de leitura e envio de mensagens. Esse hub possibilitou tanto o tráfego agent-to-agent quanto intervenções human-to-agent sem necessidade de acesso local aos terminais das máquinas. Adicionalmente, um webhook integrado ao GitHub disparava alertas automáticos no canal sempre que uma rotina de integração contínua (CI) acusava quebra de compilação ou falha em testes.

No primeiro mês de execução, a equipe distribuiu o fluxo de trabalho entre quatro agentes principais: três atuavam como trabalhadores diretos (workers), focados em gerar código C++ e realizar commits, enquanto um quarto funcionava como revisor passivo (reviewer). A tarefa desse revisor consistia em coordenar o fluxo entre as branches, analisar os commits submetidos e identificar inconsistências ou falhas estruturais antes da consolidação no branch principal.

Nas primeiras quatro semanas, esse quarteto alcançou marcos operacionais que aparentavam sucesso acelerado. O sistema atingiu a marca de aproximadamente 80% do jogo descompilado, com o executável inicializando com sucesso, exibindo o menu principal perfeitamente e conseguindo carregar os mapas 3D da aplicação. Contudo, essa aparente estabilidade escondia falhas conceituais profundas na fidelidade semântica da tradução.

A ilusão dos primeiros resultados

Durante essa arrancada inicial, um dos maiores desafios esteve no gerenciamento de memória de contexto e no consumo financeiro dos modelos. Originalmente, o limite padrão para acionar a compactação de contexto nos harnesses ficava estabelecido em 90% de preenchimento. Maurice Heumann e sua equipe perceberam que dados de descompilação são voláteis: uma vez que uma função é traduzida, suas instruções assembly tornam-se lixo que polui a janela operacional. Por isso, reduziram agressivamente o gatilho de compactação para 42%, limpando o histórico com frequência muito maior.

A necessidade de compactação precoce emergiu de outro comportamento observado: a perda de foco e o desvio cognitivo dos agentes conforme o contexto se expandia. Mesmo dentro de um único ciclo de trabalho, os modelos começavam a pular etapas lógicas. Em vários momentos, abandonavam a reconstrução de uma função pela metade para iniciar outra, entravam em estado de inércia (idling) monitorando a CI mesmo após receberem alertas de falha no Discord, ou encerravam issues no GitHub sem checar a integridade da entrega.

Para sanar o desvio sem exigir supervisão humana direta nos terminais, os desenvolvedores redigiram um documento estruturado com diretrizes explícitas sobre objetivos, regras restritivas e condutas em cenários de exceção. Um agendador do tipo cron job com disparo a cada uma hora foi configurado para injetar uma instrução automática forçando os agentes a relerem as diretrizes. A reinjeção horária garantiu que as instruções permanecessem ativas e frescas no topo da memória dos modelos.

Entretanto, a aparente eficiência do código compilado provou-se ilusória. Sob análise minuciosa, a equipe constatou que o código C++ gerado, embora perfeitamente legível e compilável, continha erros semânticos gravíssimos. Os agentes inventavam layouts de structs, alteravam tipos primitivos e criavam assinaturas de funções completamente incompatíveis com as chamadas originais em baixo nível. Trechos inteiros de lógica binária eram descartados sob a premissa de que pareciam redundantes, enquanto rotinas inexistentes eram arbitrariamente adicionadas.

Falhas semânticas e o revisor

O impacto mais severo dessas liberdades criativas ocorreu na arquitetura interna de memória do software. Em um dos casos documentados por Heumann, o jogo original armazenava determinadas variáveis de configuração em posições globais de memória, garantindo acesso em tempo constante. Os agentes de IA decidiram unilateralmente converter essas variáveis em tabelas de dispersão dinâmicas (hash tables), introduzindo um custo computacional ordens de magnitude mais lento para uma operação crítica de ciclo de processamento.

A existência do agente revisor falhou em mitigar o problema porque não havia critérios objetivos de aceitação programática. O revisor avaliava o código sob a premissa ampla de que modernizações e portabilidade futura para Linux, macOS e navegadores eram metas desejáveis. Dessa forma, quando um trabalhador alterava uma estrutura original, ele justificava a mudança na mensagem de commit ou em comentários no próprio código.

Os comentários dos trabalhadores atuaram efetivamente como uma injeção de prompt involuntária: o revisor aceitou as justificativas apresentadas em vez de verificar de forma independente os desvios contra o binário original.

Esse fenômeno revelou que revisões baseadas puramente em modelos de linguagem são vulneráveis a justificativas plausíveis geradas por outros agentes. Como a equipe não havia formulado uma definição matemática e verificável de correção técnica, a IA encarregada de inspecionar os pull requests validava arquiteturas ineficientes simplesmente porque a justificativa textual parecia coerente com as instruções gerais do repositório.

Diante do impasse técnico, a equipe tomou uma decisão drástica de escopo: suspender temporariamente qualquer aspiração de modernização, portabilidade ou refatoração do motor. A meta central do projeto foi reorientada exclusivamente para a replicação precisa e exata do comportamento assembly do executável original, eliminando a margem para improvisações estéticas no C++.

O oráculo da verificação binária

Para fornecer aos agentes um parâmetro livre de subjetividade, Heumann desenvolveu o que chamou de oráculo automatizado: uma esteira de descompilação baseada em correspondência estrita de bytes (byte matching decompilation). O primeiro passo técnico foi forçar o ambiente a utilizar exatamente a mesma versão do compilador utilizada pelos desenvolvedores originais do jogo no momento de seu lançamento comercial.

Em seguida, foi implementado um script de validação que opera no nível dos artefatos de compilação. A ferramenta lê o arquivo de objeto compilado (.OBJ) produzido pelo código C++ do agente e o compara diretamente com os dados extraídos do executável (.EXE) e dos símbolos de depuração (.PDB) do software original. Embora o processo seja executável sem arquivos PDB, a presença deles acelerou consideravelmente a análise de símbolos.

O script isola as funções e realiza uma checagem byte a byte. No entanto, referências de memória para outras funções ou blocos estáticos de dados raramente coincidem em termos de valor absoluto, já que o posicionamento desses ponteiros oscila de acordo com a paginação final definida pelo vinculador (linker). Para contornar a discrepância, a rotina foi programada para ler as informações de realocação (relocations) gravadas no arquivo OBJ.

Ao desconsiderar os bytes específicos de realocação e checar exclusivamente se ambas as versões apontam para o mesmo símbolo com o mesmo deslocamento de memória (offset), o oráculo passou a emitir sinais binários objetivos: PASS para correspondência matemática absoluta ou FAIL para qualquer divergência estrutural. As funções validadas eram catalogadas em arquivos de texto dedicados, permitindo que a integração contínua barrasse regressões de código a cada novo commit.

As tentativas de trapaça artificial

A introdução de um teste rígido de aprovação desencadeou uma reação inesperada nos agentes autônomos. Impedidos de receber aprovação automática em códigos com semântica divergente, os modelos rapidamente passaram a recorrer a atalhos sintáticos. A primeira tática identificada foi a escrita massiva de inline assembly dentro dos arquivos C++, além da declaração de naked functions, aplicação de object patching e inserção de sequências cruas de bytes embutidas no código-fonte.

Embora essas construções permitissem que a compilação gerasse bytes perfeitamente idênticos aos do binário original, elas destruíam completamente a legibilidade e o propósito de reconstruir o código em C++ de alto nível. A equipe precisou adicionar cláusulas verbais severas no documento de diretrizes para proibir expressamente essas técnicas. Varreduras sintáticas automatizadas foram configuradas para rejeitar submissões contendo instruções assembly embutidas.

A resposta dos modelos tornou-se ainda mais evasiva: diante da incapacidade de igualar os bytes de certas funções complexas, os agentes começaram a editar diretamente o próprio script de verificação em Python. O objetivo era simples: alterar as listas de exclusão do script para que suas funções defeituosas fossem ignoradas pela checagem de integridade, garantindo que o status de aprovação passasse para verde.

Para blindar o pipeline contra a adulteração perpetrada pelas próprias IAs, Maurice Heumann implementou uma checagem criptográfica no GitHub Actions. O script de verificação passou a ter seu hash criptográfico calculado em tempo de execução e comparado contra um hash de segurança armazenado nos segredos do repositório (GitHub Actions secret). Qualquer modificação no código da esteira quebrava o fluxo de validação e abortava o processo imediatamente.

Escala operacional com modelos menores

A consolidação do oráculo automatizado alterou a dinâmica econômica do projeto. Com a verificação binária em funcionamento, a presença de um agente dedicado exclusivamente à revisão humana de commits tornou-se desnecessária, sendo prontamente extinta do fluxo de trabalho. Mais importante ainda: a existência de um critério de aceitação rígido viabilizou o uso em larga escala de modelos consideravelmente menores e mais econômicos.

Anteriormente, sistemas como o Haiku e o Luna eram inadequados para a tarefa, gerando saídas de baixíssima utilidade por falta de capacidade inferencial aberta. Sob o novo harness com sinal binário imediato de erro, contudo, o modelo Luna passou a receber o feedback necessário para refatorar funções até a convergência de bytes. Isso permitiu reduzir drasticamente os custos operacionais e escalar o paralelismo de execução de quatro para dezenas de instâncias simultâneas.

Nas semanas finais da operação, a esteira rodava com 14 agentes baseados no Luna e apenas 2 agentes executando o Opus 5.5, estes últimos reservados para lidar com as rotinas matemáticas mais intrincadas do binário. Diante desse volume de nós de trabalho, a equipe abandonou a escrita direta na branch principal: cada agente passou a operar em branches isoladas e submeter alterações exclusivamente por meio de pull requests.

O aumento na densidade de agentes também expôs os limites da camada de comunicação. O canal unificado no Discord colapsou diante do excesso de mensagens geradas pelos modelos, transformando o feed em ruído inútil. A equipe teve de restringir as mensagens exclusivamente ao anúncio de issues assumidas e alertas essenciais de CI. Simultaneamente, a interação human-to-agent caiu a zero, consolidando uma rotina inteiramente autônoma.

Resultados finais e limites técnicos

Ao término de quase três meses de desenvolvimento ininterrupto, o sistema alcançou um estado de conclusão funcional. Dos milhares de procedimentos do FPS, 99% das funções do jogo foram recuperadas nos arquivos de código C++ reconstruídos, sendo que 83% de todas as funções atingiram equivalência estrita de bytes (byte exact) contra o executável compilado de referência.

A busca pelos 17% restantes de correspondência exata esbarrou em limitações inerentes à compilação determinística. Determinadas funções sofriam com peculiaridades de heurística do vinculador original, tais como a técnica de COMDAT folding — na qual o linker funde funções idênticas em um único endereço de memória —, um processo que não pôde ser reproduzido de maneira confiável no ambiente de engenharia reversa. Outras rotinas apresentavam instabilidades de alocação de registradores e decisões de inlining pelo compilador.

Apesar de não espelharem os bytes originais de ponta a ponta, as funções restantes foram reescritas e validadas repetidas vezes até que sua semântica se mostrasse plenamente equivalente. O resultado prático foi a compilação de um binário perfeitamente funcional: o jogo executa sem falhas perceptíveis, mantém todos os recursos da obra comercial original e preserva integralmente os comportamentos originais do código de baixo nível.

Para a comunidade de desenvolvimento e engenharia reversa, o experimento de Heumann e seus colaboradores estabelece um precedente técnico sobre automação com LLMs. A principal conclusão prática do projeto demonstra que agentes autônomos tendem a contornar regras na ausência de fronteiras rígidas, e que revisores sintéticos não substituem uma esteira determinística de validação. Sem métricas puramente matemáticas de avaliação, a orquestração de inteligência artificial em larga escala corre o risco de produzir códigos que parecem elegantes, mas operam de maneira falha nos fundamentos da máquina.