Claude Opus 4.6 gasta US$ 20 mil em tokens tentando criar um compilador C

Claude Opus 4.6 gasta US$ 20 mil em tokens tentando criar um compilador C

A Anthropic decidiu testar os limites do seu modelo mais recente, o Claude Opus 4.6, com uma tarefa que poucos humanos aceitariam assumir sozinhos: criar um compilador C do zero, capaz de compilar o kernel do Linux. O experimento, conduzido por Nicholas Carlini, pesquisador da equipe de Safeguards da empresa, levou duas semanas, consumiu quase 2 mil sessões do Claude Code, 2 bilhões de tokens de entrada e custou cerca de US$ 20 mil em uso de API.

O resultado foi um compilador escrito em Rust, com aproximadamente 100 mil linhas de código, capaz de compilar o Linux 6.9 para x86, ARM e RISC-V. Um feito impressionante, mas que deixou o próprio pesquisador dividido entre entusiasmo e preocupação.

Apresentando os “agent teams”

O experimento girou em torno de um conceito chamado agent teams, no qual múltiplas instâncias do Claude trabalham em paralelo sobre o mesmo repositório de código, sem intervenção humana constante. Diferente do uso tradicional de um LLM, em que o modelo responde a comandos pontuais, aqui os agentes operam de forma contínua e autônoma.

Para isso, Carlini precisou criar um harness, uma espécie de estrutura de controle, que colocava o Claude em um loop infinito: ao terminar uma tarefa, o modelo automaticamente escolhia a próxima. Não havia um “orquestrador central” nem supervisão ativa. Cada agente decidia o que fazer com base no estado atual do projeto.

Na prática, isso transformou o Claude em algo mais próximo de um time de desenvolvedores júnior extremamente rápidos, persistentes e incansáveis.

Um compilador que funciona, mas não como um humano faria

Tecnicamente, o compilador criado pelo Opus 4.6 é real e funcional. Ele consegue compilar não apenas o kernel do Linux, mas também projetos complexos como SQLite, Redis, PostgreSQL, QEMU, FFmpeg e Lua, além de passar por boa parte das suítes de teste usadas para compiladores C.

Ainda assim, ele está longe de ser um substituto direto para GCC ou Clang. O código gerado é pouco eficiente, mesmo com otimizações ativadas, e o próprio Carlini reconhece que a qualidade do código Rust está “razoável”, mas muito abaixo do que um programador experiente produziria.

Existem também “atalhos”. Para gerar código em x86 de 16 bits, necessário no processo de boot do Linux, o compilador simplesmente chama o GCC externamente. Em outras palavras: quando a tarefa ficou difícil demais, o Claude trapaceou.

Curiosamente, a maior parte do esforço humano não foi escrever código, mas ensinar o Claude a entender se estava progredindo ou não. Carlini destaca que testes mal projetados levam o modelo a “resolver o problema errado” de forma extremamente eficiente.

Entre as lições aprendidas estão recomendações quase filosóficas, como “se colocar no lugar do Claude”. Isso significa evitar saídas de teste gigantescas, escrever mensagens de erro claras, manter a documentação constantemente atualizada e estruturar logs para que o modelo consiga processá-los automaticamente.

Outro ponto curioso: o Claude não tem noção de tempo. Se deixado sozinho, ele pode passar horas rodando testes em vez de avançar no código. Para contornar isso, o sistema executava apenas amostras determinísticas dos testes, permitindo progresso sem sobrecarregar o contexto do modelo.

Paralelismo ajuda — até deixar de ajudar

Rodar 16 agentes em paralelo funcionou muito bem enquanto havia muitas tarefas independentes. Mas quando o objetivo passou a ser compilar o kernel do Linux, tudo virou um gargalo único: todos os agentes tropeçavam nos mesmos bugs, sobrescrevendo correções uns dos outros.

A solução foi usar o GCC como oráculo, compilando parte do kernel com ele e parte com o compilador do Claude, isolando os arquivos problemáticos. Só assim o paralelismo voltou a ser útil.

Entusiasmo, ceticismo e desconforto

Apesar do sucesso técnico, a reação da comunidade foi mista. No GitHub, muitos questionaram o custo real do projeto, lembrando que o modelo foi treinado sobre décadas de código escrito por humanos.

O próprio Carlini termina o relato com um alerta. Como ex-penetration tester, ele vê riscos reais em um futuro onde software complexo é gerado e implantado sem que ninguém realmente o compreenda por completo.

No fim, o experimento mostra que desenvolvimento autônomo de software já é possível, ainda que imperfeito.

Fique por dentro das principais novidades da semana sobre tecnologia e Linux: receba nossa newsletter!