16 agentes Claude escreveram em duas semanas um compilador C de 100 000 linhas por $20 000

Nicholas Carlini, pesquisador da equipe de Safeguards da Anthropic, conduziu um experimento: 16 instâncias do Claude Opus 4.6 trabalharam em paralelo em um repositório compartilhado e escreveram, em Rust, um compilador C do zero. Quase não houve intervenção humana. Em duas semanas e cerca de 2000 sessões do Claude Code, os agentes produziram 100 000 linhas de código. O compilador gera um kernel Linux 6.9 inicializável em x86, ARM e RISC-V. A conta da API ficou um pouco abaixo de $20 000.

Como funciona o esquema de agentes

A base da arquitetura é simples. O Claude roda em um loop infinito: terminou uma tarefa, pega a próxima. Cada agente vive em um contêiner Docker próprio, clona um repositório git bare compartilhado e envia (push) suas alterações para lá. Para evitar que os agentes resolvam o mesmo problema, o esquema usa travas: o Claude cria um arquivo de texto como current_tasks/parse_if_statement.txt, e o git impede que um segundo agente assuma a mesma tarefa. Conflitos de merge acontecem com frequência, mas o modelo os resolve sozinho.

Não há orquestrador, e também não existem canais de comunicação comuns entre os agentes. Cada um decide por conta própria o que fazer em seguida e, em geral, pega o problema "mais óbvio da vez". Em um episódio, um agente executou pkill -9 bash por acidente e interrompeu o próprio loop.

A maior parte do esforço foi para o ambiente, não para os prompts: testes, logs e feedback. A saída dos testes é limitada a poucas linhas, para não poluir o contexto. Os erros são escritos em uma única linha, com o marcador ERROR para facilitar o grep. Para lidar com a "cegueira temporal" dos agentes, foi adicionada a opção --fast, que executa uma amostra de 1% ou 10% dos testes, determinística para cada agente.

Onde o limite apareceu

Enquanto os testes são independentes, paralelizar é fácil: cada agente pega seu teste que falhou. Mas o kernel do Linux é uma tarefa gigantesca e única. Os 16 agentes esbarravam no mesmo erro e sobrescreviam as correções uns dos outros. A saída foi usar o GCC como oráculo de referência: o GCC compilava uma parte aleatória dos arquivos do kernel, e o Claude compilava o restante. Assim, os agentes passaram a corrigir bugs diferentes em arquivos diferentes. Para os pares de arquivos que só quebravam juntos, foi aplicado delta debugging.

Os agentes também receberam papéis: um consolidava código duplicado, outro acelerava o próprio compilador, um terceiro cuidava da eficiência do código gerado, um quarto atuava como crítico da arquitetura sob a ótica de um desenvolvedor Rust, e um quinto mantinha a documentação.

Números e limitações

• Tamanho: cerca de 100 000 linhas em Rust, sem dependências além da biblioteca padrão.
• Recursos: 2 bilhões de tokens de entrada e 140 milhões de tokens de saída, quase $20 000.
• Testes: 99% na maioria dos conjuntos, incluindo o GCC torture.
• Compila: Linux 6.9 (x86, ARM, RISC-V), QEMU, FFmpeg, SQLite, Postgres, Redis, Doom.
• Desenvolvimento clean-room: o Claude não tinha acesso à internet.
• Sem assembler e linker próprios: esses módulos foram os últimos a ser automatizados e ainda apresentam bugs.
• O x86 de 16 bits para real mode não foi implementado: a saída passa de 60 KB, e o limite do kernel é de 32 KB, por isso o GCC é chamado nesse trecho.
• O código é menos eficiente que o do GCC, mesmo com as otimizações desativadas.

Carlini escreve sem rodeios que o compilador chegou perto do limite das capacidades do Opus: novas funcionalidades e correções quebravam, com frequência, o que já funcionava. O avanço ao longo da linha é visível: os primeiros Opus 4 mal conseguiam produzir um compilador funcional, e o Opus 4.5 passou pela primeira vez em grandes suítes de teste, mas não compilava projetos reais.

Lições práticas

A principal lição para quem constrói agentes autônomos: a qualidade do mecanismo de verificação importa mais que o próprio modelo. Se o verificador é impreciso, o agente resolve com toda a confiança o problema errado. Por isso, os testes precisam ser escritos pensando no modelo: saída curta, logs compatíveis com grep, subamostras rápidas e determinísticas, e uma CI que impeça quebrar commits anteriores.

Segundo: paralelismo exige decomposição. Se a tarefa é monolítica, agentes extras só atrapalham, e uma referência funcional conhecida ajuda a dividi-la em partes independentes.

Terceiro: $20 000 por um compilador capaz de compilar o Linux é muito mais barato que uma equipe de engenheiros, mas ainda bem mais caro que uma assinatura. O código foi publicado e pode ser testado em projetos C próprios. O próprio autor faz uma ressalva: o desenvolvimento totalmente autônomo traz riscos reais, e por ora não dá para dispensar a supervisão humana sobre a qualidade e a segurança do código.