Reescrever 960.000 linhas de código em 6 dias soa como o tipo de coisa que aparece num post satírico do HN. Mas foi exatamente o que o time do Bun — agora parte da Anthropic — relatou em maio de 2026: um port experimental do core do runtime de Zig para Rust, feito majoritariamente por agentes de IA, com 99,8% dos testes passando no Linux x64.

O Jarred Sumner, criador do Bun, foi imediato em contextualizar: “isso é código que provavelmente vai ser jogado fora.” Mas o experimento em si levanta questões mais interessantes do que o resultado. O que acontece quando você usa IA não pra escrever uma feature, mas pra traduzir um runtime inteiro de uma linguagem pra outra? Quais são os limites reais dessa abordagem? E por que Rust, se o Zig estava funcionando?

Contexto: A Anthropic Comprou o Bun

Em 2 de dezembro de 2025, a Anthropic anunciou a aquisição do Bun. Na época, a leitura óbvia foi: “empresa de IA quer uma runtime JavaScript rápida pra rodar agentes.” A leitura mais estratégica é diferente: a Anthropic está construindo infraestrutura — o Claude Code, o Claude Agent SDK — e precisava de uma camada de execução que fizesse sentido com o toolchain que ela já usa internamente.

O Rust é a linguagem da casa na Anthropic. A base de código do Claude Code e do Agent SDK usa Rust extensivamente. O Bun era Zig. Essa fricção é o ponto de partida de tudo que veio depois.

O Problema com o Zig (segundo o Jarred)

Antes de falar dos agentes, é importante entender por que a reescrita foi sequer considerada. O Jarred foi público sobre isso:

“Estou tão cansado de me preocupar e gastar tempo consertando memory leaks, crashes e problemas de estabilidade. Seria tão bom se a linguagem fornecesse ferramentas mais poderosas para prevenir essas coisas.”

O Zig, diferente do Rust, não tem borrow checker. A gestão de memória é manual — mais parecida com C do que com Rust. Isso dá controle total, mas cobra um preço em bugs difíceis de encontrar. Pra um runtime JavaScript que precisa de estabilidade sob carga, cada memory leak é um problema de produção real.

O Rust resolve isso em tempo de compilação. O borrow checker garante que você não vai ter use-after-free, double-free, ou data races — e o compilador te diz exatamente onde o problema está antes do código rodar. O custo é uma curva de aprendizado íngreme e tempos de compilação mais longos.

O Experimento: 960 Mil Linhas em 6 Dias

Aqui está o que foi reportado: em aproximadamente 6 dias de trabalho com agentes de IA, o time do Bun converteu ~960.000 linhas de Zig para Rust com 99,8% dos testes passando no Linux x64 glibc. Os commits chegavam a 27.000 linhas por pull request.

Pra colocar em perspectiva: o Linux kernel tem ~30 milhões de linhas. Um dev experiente, trabalhando sozinho numa conversão de linguagem, consegue fazer talvez algumas centenas de linhas por hora com qualidade — e isso sendo otimista. 960.000 linhas em 6 dias equivale a mais de 6.000 linhas por hora de trabalho. Sem agentes, isso não é fisicamente possível.

Como os Agentes Claude Fizeram Isso

O processo não foi “manda o arquivo Zig, recebe o arquivo Rust”. Foi uma pipeline estruturada com três papéis distintos:

• @robobun — agente responsável pela geração de código. Recebe o Zig, aplica ~300 regras de conversão, produz o Rust equivalente
• @coderabbitai e @claude — agentes de review. Analisam o código gerado, identificam padrões incorretos, sugerem correções antes do merge
• Humano — aprovação final obrigatória antes de qualquer commit entrar na branch

As ~300 regras de conversão são o detalhe mais interessante. Não é tradução mecânica linha a linha — é um mapeamento semântico de padrões. “Quando ver esse padrão de alocação em Zig, use este idiom de Rust.” “Quando ver este uso de ponteiro, converta para este tipo de referência.” Essas regras foram provavelmente extraídas de conversões anteriores de trechos menores, refinadas iterativamente.

O resultado passou 99,8% dos testes no Linux x64 — mas não passou no Mac ou Windows. Isso é um dado importante: a paridade de comportamento entre plataformas é um dos problemas mais difíceis numa conversão de linguagem, porque envolve diferenças de ABI, de system calls, de comportamento de alocadores. Os agentes resolveram o caso principal; os edge cases de plataforma ficaram pra depois.

Zig vs. Rust: A Comparação Real

Se você não conhece bem as duas linguagens, aqui está o resumo honesto:

O ponto sobre “treinamento de IA” não é óbvio mas é crucial nesse contexto: há muito mais código Rust público do que código Zig. Isso significa que o Claude tem muito mais exemplos de Rust idiomático pra aprender — o que torna a geração de código Rust pelo Claude substancialmente melhor do que a geração de Zig. É um loop de feedback: Rust é mais comum → IA entende melhor → IA gera código Rust de maior qualidade → faz mais sentido usar Rust em projetos liderados por IA.

O que o Jarred Sumner Realmente Disse

A internet reagiu como a internet reage — com alarme. “O Bun vai ser reescrito em Rust!” “O Zig está morto!” O Jarred precisou esclarecer no HN:

“Esse thread inteiro é uma reação exagerada. 302 comentários sobre código que não funciona. Nós não nos comprometemos a reescrever.”

E mais diretamente: “tem uma chance muito alta de todo esse código ser jogado fora completamente.”

Isso é importante. O experimento foi feito pra responder a uma pergunta: é viável reescrever o Bun em Rust? A resposta foi: sim, tecnicamente — mas há ressalvas. O código passou no Linux, não no Mac e Windows. O código tem 99,8% de paridade, não 100%. E 750.000 linhas de código gerado por IA numa codebase de produção levanta questões de manutenibilidade que vão além do “os testes passam”.

O Problema da Manutenibilidade

Desenvolvedores que analisaram o código gerado identificaram alguns padrões preocupantes: uso excessivo de trait objects onde generics seriam mais eficientes, abstrações que fazem sentido em Zig mas ficaram estranhas em Rust, e alguns idioms que “funcionam” mas que nenhum dev Rust experiente escreveria.

Isso não é surpreendente. IA gera código que compila e passa nos testes — mas não necessariamente código que um time vai conseguir evoluir com confiança daqui a dois anos. A Zig Software Foundation, aliás, tem uma política explícita de “no AI code” — o que cria uma fricção interessante pra qualquer projeto que queira contribuir de volta pro ecossistema Zig.

O código gerado por agente é uma forma de dívida técnica diferente: não é dívida por atalho consciente, é dívida por falta de contexto semântico profundo. O compilador aceita, os testes passam, mas o engenheiro que herdar aquele código vai ter que entender por que foi escrito assim — e muitas vezes não vai ter resposta.

O que Isso Significa pra Você

Tem dois ângulos práticos aqui.

Primeiro: o Bun não vai sumir, nem virar outra coisa de repente. A versão atual em produção continua sendo Zig. Qualquer transição para Rust, se acontecer, vai ser gradual e com ciclos de estabilização longos. Se você usa Bun em produção, não muda nada agora.

Segundo: o experimento demonstra algo mais amplo sobre o estado da IA em engenharia de software. Não é que agentes de IA podem substituir engenheiros — o experimento exigiu humanos no loop, regras cuidadosamente definidas, e ainda assim produziu código que “provavelmente vai ser jogado fora”. É que agentes de IA podem realizar trabalho de escala antes impraticável — traduzir 960k linhas de código — com qualidade suficiente para ser o ponto de partida de uma decisão estratégica real.

A Anthropic não fez esse experimento pra poder dizer “olha, nossa IA é boa”. Fez pra responder uma pergunta de engenharia real com dados reais. O resultado foi ambíguo o suficiente pra pausar a decisão — o que é exatamente o que deveria acontecer num processo de engenharia bem feito.

Jarred Sumner disse que há “grande chance de todo o código ser descartado.” Mas a resposta à pergunta — conseguimos fazer isso? — foi sim. E isso, independente do que acontece com o código específico, muda o que é possível considerar no próximo projeto de larga escala.

Fonte de inspiração: Anthropic’s Bun team trials port from Zig to Rust