Reescrever um projeto grande do zero é um dos maiores tabus da engenharia de software — caro, arriscado, quase sempre um tiro no pé. Foi por isso que a história do Bun virou assunto: Jarred Sumner, criador do runtime, portou 535.496 linhas de código de Zig para Rust em 11 dias, coordenando uma frota de agentes do Claude em paralelo, por cerca de US$ 165 mil em uso de API. E, no fim, a nova versão passou em 100% dos testes.
É um marco — e também uma polêmica. Vale separar o que realmente aconteceu, como foi feito, o que a comunidade criticou e, principalmente, o que dá para aprender (sem cair no hype).
O que é o Bun (e por que isso importa)
O Bun é um runtime e um kit de ferramentas para JavaScript/TypeScript: roda código, empacota (bundler), transpila, minifica, tem test runner e um gerenciador de pacotes compatível com o npm. São cerca de 22 milhões de downloads por mês, e ele está embaixo de ferramentas conhecidas — incluindo o Claude Code e o OpenCode — e de plataformas como Vercel, Railway e DigitalOcean. Um detalhe de contexto importante: a Anthropic adquiriu o Bun em dezembro de 2025, o que explica parte do que veremos adiante.
Por que reescrever: o problema estava na memória
O Bun era escrito em Zig, uma linguagem rápida, porém sem garantias de segurança de memória. Misturar o gerenciamento manual de memória do Zig com o garbage collector do JavaScript criou uma classe de bugs que insistia em voltar: use-after-free, double-free e vazamentos de memória nas bordas de erro. Sumner resumiu bem o cansaço de conviver com isso: estava “cansado de dormir preocupado com crashes no Bun”. Segundo o relato, um desses bugs chegou a ser apontado como relacionado ao vazamento do código-fonte do Claude Code.
O Rust resolve justamente isso: entrega desempenho parecido com o do Zig, mas com segurança de memória garantida pelo compilador, eliminando categorias inteiras de erro. O problema é que reescrever meio milhão de linhas à mão levaria, pela própria estimativa, cerca de um ano com três engenheiros em tempo integral.
Como foi feito: o passo a passo com IA
Em vez do trabalho manual, Sumner montou um fluxo de agentes — usando uma versão pré-lançamento do Claude Fable 5, à qual teve acesso por trabalhar na Anthropic. O processo, em etapas:
- Preparação (~3 horas). Criou, com o Claude, um guia de ~600 linhas chamado PORTING.md, mapeando padrões de Zig para Rust e fixando regras claras.
- Ensaio. O Claude reescreveu 3 arquivos de amostra (de 1.448 no total), seguidos de revisões adversariais em sessões separadas, para criticar a saída.
- Paralelização. O trabalho foi dividido entre cerca de 64 agentes atuando ao mesmo tempo em arquivos independentes, com dezenas de workflows dinâmicos (quatro “shards” em worktrees do git, cada um rodando 16 instâncias do Claude).
- Ajuste do fluxo (~1 dia). No começo, os agentes brigavam entre si com comandos de git conflitantes. A solução foi eliminá-los (sem stash/reset) e mandar cada agente commitar arquivo a arquivo, na hora.
- Execução (~2 dias). Pico de cerca de 1.300 linhas por minuto. Cada commit passava por duas revisões adversariais antes de entrar.
- Erros de compilação (~12 horas). A reescrita gerou por volta de 16 mil erros de compilação; os agentes os resolveram crate por crate, agrupando e corrigindo em lote.
- Testes (~2 dias rodando, ~3 dias corrigindo). A suíte de testes do Bun foi executada para achar e consertar o que quebrava.
As regras do PORTING.md foram parte central do sucesso — elas deram “trilhos” para a IA não se perder:
Regras (resumo do PORTING.md):
- Nada de bibliotecas async externas (tokio, rayon, hyper).
- Nada de funções async: apenas callbacks e máquinas de estado.
- Pode reformatar para agradar o borrow-checker,
desde que documentado em comentário.
- Mapear cada padrão comum de Zig para o equivalente idiomático em Rust.Os números do feito
- 11 dias, do planejamento à conclusão;
- 535.496 linhas portadas (mais de 1 milhão de linhas de Rust geradas no total);
- ~6.500 commits;
- 5,9 bilhões de tokens de entrada não-cacheados, 690 milhões de tokens de saída e 72 bilhões de leituras de cache;
- ~US$ 165 mil a preço de API.
Sobre o custo, Mitchell Hashimoto (criador do HashiCorp e do Ghostty) comentou que US$ 165 mil a preço de API é um baita negócio perto do que custaria um time de engenheiros fazendo o mesmo em 11 dias — algo que, na prática, seria impossível no prazo.
O resultado
A versão em Rust compilou e passou na suíte de testes do Bun — mais de 1 milhão de asserções — em 100%, em todas as plataformas suportadas, sem pular nem apagar nenhum teste. Houve até ganho de desempenho (cerca de 10% mais rápido no startup no Linux). Como resumiu Simon Willison, o resultado foi “chato no melhor sentido”: os usuários quase não perceberam a troca, porque tudo continuou funcionando.
A polêmica: "unreviewed slop"
Nem todo mundo aplaudiu. Andrew Kelley, criador do Zig, classificou o resultado como “unreviewed slop” (algo como “lixo não revisado”). A crítica da comunidade se apoia em pontos legítimos:
- Revisão humana de verdade. Com 535 mil linhas geradas por IA e revisadas por outra IA, quanto passou por olhos humanos de fato?
- Manutenibilidade. Código que passa nos testes não é necessariamente código bom de manter — legível, idiomático, coerente.
- Testes provam tudo? Uma suíte enorme dá muita confiança, mas nenhum teste cobre 100% dos casos; ele reduz o risco, não o zera.
Vale registrar também o contexto especial: Sumner trabalha na Anthropic (que comprou o Bun) e usou um modelo pré-lançamento. Ou seja, é um caso com condições que a maioria dos times não tem — o que não invalida o feito, mas exige cautela antes de generalizar.
O que dá para aprender (as condições que fizeram funcionar)
A análise de Gergely Orosz (do The Pragmatic Engineer) é a parte mais útil. Ele aponta três fatores sem os quais isso não teria dado certo:
- Um engenheiro especialista no comando. Foi preciso alguém com conhecimento profundo do código e muito motivado para guiar, revisar e decidir. A IA executou; o humano dirigiu.
- Uma suíte de testes robusta. Era o que dava confiança: quando os testes passavam, dá para acreditar que a reescrita funcionou. Sem isso, o feito seria impossível de validar.
- Disposição de gastar tokens sem garantia. Foi preciso investir recursos de verdade (nem sempre US$ 165 mil, mas um valor real) sem certeza do resultado.
A lição de fundo, segundo Orosz: os LLMs são ótimos no trabalho “mundano” — migrações, conversões e refatorações mecânicas — e a IA viabiliza reescritas e migrações que antes nem seriam consideradas. No caso do Bun, a alternativa realista não era “reescrever à mão”; era continuar consertando bugs para sempre.
Insights para o seu projeto
- Testes primeiro. A rede de segurança que torna uma reescrita com IA viável é a suíte de testes. Sem cobertura forte, nem tente.
- Documente as regras. Um guia como o PORTING.md — padrões, proibições, convertenções — dá trilhos e reduz drasticamente a variação da IA.
- Fatie em partes independentes. O paralelismo só funciona porque os arquivos podiam ser tratados sem dependência entre si.
- Revisão adversarial. Uma IA gera, outra critica (em sessão separada) antes de aceitar — pega muito erro que o autor não vê.
- Conserte o processo, não o código. Em vez de corrigir bug a bug à mão, ajuste o fluxo que gera o código — escala muito melhor.
- Modelos por tarefa. Dá para usar modelos mais baratos no trabalho rotineiro e reservar os caros para o planejamento e as decisões difíceis.
Conclusão
O caso do Bun não prova que “a IA reescreve qualquer coisa”. Prova algo mais específico e mais útil: com um engenheiro experiente no comando, uma suíte de testes forte e um processo bem desenhado (regras claras, paralelização e revisão adversarial), migrações antes consideradas inviáveis passam a caber em dias, não anos. A crítica sobre revisão e manutenibilidade é justa e precisa ser levada a sério — mas o recado central fica: a fronteira do que “vale a pena reescrever” acabou de se mover. 🚀
Referências
- The Pragmatic Engineer (Gergely Orosz) — What can we learn from Bun’s rapid Rust rewrite with AI?
- Simon Willison — Rewriting Bun in Rust
- The Register — Zig creator calls Bun’s Claude Rust rewrite ‘unreviewed slop’
- Techzine — Bun switches from Zig to Rust with Claude’s help