- 16 agentes Claude colaboraram em paralelo para concluir um compilador C baseado em Rust, alcançando um nível capaz de compilar o kernel Linux 6.9
- Com cerca de 2.000 sessões e custo de 20 mil dólares, geraram uma base de código de aproximadamente 100 mil linhas, com suporte às arquiteturas x86, ARM e RISC-V
- Os agentes trabalharam continuamente sem intervenção humana por meio de um harness automático em loop, aumentando a eficiência com uma estrutura de testes, paralelização e divisão de papéis
- O resultado demonstrou compatibilidade com GCC e alta taxa de aprovação em testes, mas itens como geração de código x86 de 16 bits, linker e qualidade de otimização ainda permanecem incompletos
- O experimento serviu para verificar os limites e possibilidades de equipes autônomas de LLMs, trazendo à tona a segurança e o controle de qualidade em ambientes de desenvolvimento totalmente autônomos como desafio central para o futuro
Visão geral do projeto de compilador C baseado em equipe de agentes
- Um experimento em que várias instâncias de Claude colaboram em paralelo para desenvolver uma única base de código
- Sem intervenção humana em tempo real, repetem de forma autônoma a escrita, os testes e a correção de código
- O objetivo era concluir um compilador C escrito em Rust para compilar diretamente o kernel Linux
- Foram usados ao todo 16 agentes, cerca de 2.000 sessões, 200 milhões de tokens de entrada e 140 milhões de tokens de saída
- O resultado foi um compilador de 100.000 linhas, capaz de compilar o kernel Linux 6.9 e importantes projetos open source (QEMU, FFmpeg, SQLite, Redis etc.)
Projeto do harness de Claude para execução de longa duração
- O Claude Code existente exigia entrada humana, mas passou a operar de forma autônoma com um harness de execução automática em estrutura de loop infinito
- Uma estrutura de repetição automática em que, ao concluir cada tarefa, a próxima é executada imediatamente
- Houve até um caso em que Claude executou
pkill -9 bash por engano durante o trabalho e encerrou a si mesmo
- A estrutura de execução paralela utilizou contêineres Docker e sincronização via Git
- Cada agente trabalhava em
/workspace e depois fazia push para /upstream
- Locks baseados em arquivos de texto evitavam conflitos de trabalho
- Os conflitos de merge eram resolvidos pelo próprio Claude
Como a operação paralela de Claude funcionava
- A vantagem da execução paralela está na depuração simultânea e na divisão de papéis
- Alguns agentes escreviam código, enquanto outros cuidavam de documentação, controle de qualidade e otimização de desempenho
- Não havia comunicação nem coordenador central; cada agente escolhia de forma autônoma a próxima tarefa
- O histórico do Git registrava os locks de trabalho e documentos de progresso de cada agente
Lições aprendidas com programação em equipe usando Claude
A importância de testes de alta qualidade
- Como Claude trabalha de forma autônoma com base nos testes fornecidos, a precisão do verificador é essencial
- Se houver falsos positivos, o desenvolvimento pode seguir na direção errada
- Foi construída uma pipeline de integração contínua (CI) para garantir que funcionalidades existentes não fossem quebradas
- Scripts de build open source e a suite de testes de compiladores foram usados para assegurar a qualidade
Projetar o ambiente da perspectiva do Claude
- Cada agente começa em um contêiner novo, sem contexto, então a documentação do progresso é indispensável
- Eles eram instruídos a atualizar continuamente o README e os arquivos de progresso
- Prevenção de poluição de contexto: logs mínimos e erros registrados de forma que pudessem ser identificados pela palavra-chave
ERROR
- Para compensar a falta de percepção de tempo, usava-se a opção
--fast para executar testes amostrais de 1% a 10%
Limites da paralelização e como resolvê-los
- Quando há muitos testes independentes, paralelizar é fácil, mas a compilação do kernel Linux é uma única tarefa gigantesca, o que gerava conflitos
- Como solução, o GCC foi usado como compilador-oráculo de referência
- Alguns arquivos eram compilados com GCC, e o restante com o compilador do Claude
- Em caso de falha, era possível reduzir o problema aos arquivos com erro e depurá-los em paralelo
- Depois, aplicava-se delta debugging para detectar erros de dependência mútua
Divisão de papéis entre agentes
- Houve distribuição especializada de funções como remoção de código duplicado, melhoria de desempenho, geração eficiente de código, aprimoramento da estrutura em Rust e documentação
- A combinação de paralelismo e especialização aumentou a eficiência na gestão de uma base de código de grande porte
Avaliação de desempenho do modelo Opus 4.6
- Até o Opus 4.5, não era possível compilar projetos grandes; no Opus 4.6, isso finalmente atingiu um nível prático
- A implementação foi feita em clean room, sem acesso à internet e usando apenas a biblioteca padrão do Rust
- 99% de aprovação na GCC torture test suite, com Doom executando com sucesso
- Limitações:
- Não consegue gerar código x86 de 16 bits, exigindo chamada ao GCC na etapa de boot
- Assembler e linker incompletos, com alguns bugs ainda presentes
- Baixa eficiência do código gerado, pior do que GCC com otimizações desativadas
- A qualidade do código Rust é razoável, mas abaixo do nível de um especialista
Limites e possibilidades de equipes de agentes autônomos
- O projeto funcionou como benchmark para medir os limites da colaboração autônoma entre LLMs
- O desenvolvimento totalmente autônomo envolve garantia de qualidade e riscos de segurança
- Há o risco de considerar algo concluído apenas porque passou nos testes
- Foi expressa preocupação com a implantação de código sem validação humana
- Ainda assim, demonstrou-se que equipes de agentes autônomos podem concluir projetos complexos
- Com a evolução futura dos modelos, estratégias seguras de desenvolvimento autônomo passam a ser uma tarefa essencial
Perspectivas futuras
- A evolução dos modelos de linguagem está indo de autocompletar em IDE → conclusão de funções → pair programming → execução autônoma de projetos
- Agent teams mostram a possibilidade de desenvolvimento totalmente autônomo
- Ao mesmo tempo em que impressiona a velocidade do avanço tecnológico, reforça-se a necessidade de novos frameworks éticos e de segurança
- Espera-se que os usos positivos compensem os riscos negativos, mas permanece a necessidade de se preparar para um novo paradigma de desenvolvimento
2 comentários
Como não é um projeto de compilador feito em C, mas sim criado apenas com a biblioteca padrão de Rust, acho que a crítica de que há código C de
gcc/clangnos dados de treinamento é meio que mudar a trave de lugar. De qualquer forma, é impressionante.Comentários no Hacker News
Trabalhei por quase 10 anos no Google com compilar o kernel Linux com Clang. Este projeto (clangbuiltlinux.github.io) teria conseguido fazer a mesma coisa com um LLM, usando 2.000 sessões e 20 mil dólares em custos de API. É surpreendente saber que ele realmente chegou a dar boot. Ainda assim, a eficiência do código gerado é baixa, e ele seria ainda mais ineficiente que uma versão do GCC com otimizações desativadas. Mesmo assim, é um projeto realmente muito legal
É uma abordagem bem mais realista do que o projeto de navegador do Cursor. Disseram que foi uma implementação clean room, usando só a biblioteca padrão de Rust e sem acesso à internet. Um compilador de 100 mil linhas conseguiria compilar Linux 6.9, QEMU, FFmpeg, SQLite, Postgres e Redis.
O Opus 4.5 teria sido o primeiro a conseguir passar em testes grandes, e este resultado parece ter explorado quase todo esse limite.
Mesmo com várias restrições, acho um experimento impressionante
No começo minha reação foi “uau, incrível”, mas logo mudei de ideia. Um compilador C é um software com especificação muito rígida, então é relativamente fácil para um LLM lidar com isso.
Mas a maior parte do nosso trabalho acontece em ambientes com requisitos ambíguos e objetivos que mudam o tempo todo. Fico curioso se isso também funcionaria bem nessas áreas
Acho estranho esperar que o resultado tenha que ser perfeito. O fato de isso ser possível já é impressionante. Tentativas assim podem ser incorporadas ao treino dos próximos Opus ou Sonnet, e talvez um dia apareça um modelo capaz de criar por conta própria um compilador eficiente
Dizem que este projeto consegue compilar kernel Linux, QEMU, FFmpeg, Redis e até Doom. É realmente impressionante.
Mas esses sistemas de agentes funcionam bem em áreas testáveis; já em áreas que exigem contexto, como tomada de decisão de negócio, ainda têm limitações
É um projeto legal, mas teria sido melhor não mencionar “clean room”. Como é um modelo treinado em código com copyright, está mais para o oposto disso
Segundo a issue no GitHub, o problema era a ausência do caminho de include. O compilador em si está normal
Eu queria que todos os prompts e a estrutura dos agentes fossem divulgados. Seria ótimo para estudo, mas é pesado demais gastar 20 mil dólares do próprio bolso para reproduzir isso
Isso parece uma versão funcional do post do blog do Cursor. A prova de que ele realmente compilou o kernel Linux é bem mais convincente
Isso é uma abordagem do tipo “consegue construir pirâmides, mas não catedrais” (texto relacionado).
Na prática, enfiaram uma quantidade enorme de recursos computacionais para forçar a implementação da funcionalidade, e dá para dizer que queimaram 20 mil dólares.
Obter resultados lineares com computação exponencial tem seu valor, mas no longo prazo parece um caminho ineficiente