Em maio de 2026, o projeto Bun concluiu uma migração de código praticamente sem precedentes na história do desenvolvimento de software: 535.000 linhas de Zig, 11 dias, 64 instâncias do Claude trabalhando em paralelo, 6.778 commits, 1 milhão de linhas de código alteradas. Custo de API: US$ 165.000 — aproximadamente um ano de produção de três engenheiros.
O número provocou um debate acalorado no Hacker News — alguns fizeram as contas e disseram que foi um ótimo negócio; outros afirmaram que isso minimizava o investimento real. Mas todos estavam fazendo a pergunta errada. A pergunta de verdade não é “US$ 165.000 valeram a pena?”. É: quem revisa 1 milhão de linhas de código?
A narrativa popular deixa de fora um detalhe crucial
Grande parte da cobertura apresentou o rewrite do Bun como uma “revolução de eficiência da IA na programação” — 64 Claudes trabalhando simultaneamente, 1.300 linhas por minuto, um ano de trabalho humano em 11 dias. Tentador, mas omite um detalhe crítico. Jarred Sumner revelou com franqueza em seu blog: cerca de 4% do código Rust do Bun está dentro de blocos unsafe — aproximadamente 13.000 palavras-chave unsafe espalhadas por ~27.000 linhas. Para comparar, o uv, com cerca de 350.000 linhas, tem apenas 73 chamadas unsafe. O número do Bun é 178 vezes maior. E comportamento indefinido surgiu também no Rust “seguro” — o que é mais difícil de depurar do que C++, justamente porque você acredita que código seguro não pode quebrar.
Sumner também admitiu que o rewrite introduziu 19 regressões conhecidas, em sua maioria causadas por código sintaticamente idêntico, mas semanticamente diferente — o assert do Zig é uma função cujos argumentos são executados a cada build; o debug_assert! do Rust é uma macro cuja expressão é removida em builds de release. Dois blocos de código que parecem idênticos se comportam de maneira completamente diferente. As regressões foram corrigidas. Mas “corrigidas” não significa “não existem outros problemas”.
Um milhão de linhas de mudanças não pode ser revisado linha por linha por humanos. A um linha por minuto, seriam 11,7 dias de leitura contínua; a uma velocidade realista de revisão de 200 linhas por hora, levaria mais de dois anos. Os revisores reais do PR foram, sobretudo, claude[bot] e coderabbitai[bot]. A própria abordagem de revisão de Sumner: “verificar se os agentes de revisão adversarial detectaram corretamente as divergências, garantir que as diretrizes de conversão foram seguidas e ler pessoalmente uma quantidade razoável de código.” Quanto é “uma quantidade razoável”? Ele não disse.
Este é o sinal mais notável de toda a história: código escrito por IA acabará sendo revisado apenas por IA.
Por que o Bun precisava ser reescrito — e por que não conseguia antes
O código original do Bun era Zig, que — como C — não gerencia memória automaticamente. O JavaScriptCore, motor JS embutido no Bun, tem regras de GC e tratamento de exceções extremamente rígidas. Quando esses dois paradigmas coexistem em um mesmo processo, cada alocação de memória exige auditoria linha por linha: onde esses bytes são liberados? Como garantir liberação única? Isso é memória do GC ou gerenciada manualmente?
A equipe tentou de tudo: suporte a Address Sanitizer no compilador Zig, testes ASAN em cada execução de CI, builds ReleaseSafe no Windows, fuzzing com Fuzzilli 24/7, extensos testes ponta a ponta de memory leak. Os relatórios de crash continuaram chegando. “Nosso backlog de correção de bugs é desesperador; estou cansado de dormir preocupado com crashes do Bun”, escreveu Sumner. A resposta da versão em Rust: 2.000 iterações do Bun.build() reduziram a memória de 6,7 GB para 609 MB; 128 bugs reproduzíveis corrigidos; tamanho do binário reduzido em ~20%.
Nunca se tratou de uma pergunta “devemos reescrever?” — o conflito fundamental entre GC e gerenciamento manual de memória não deixava alternativa. Mas por que não aconteceu antes? Porque reescrever significava congelar um ano de correções de bugs, patches de segurança e novas funcionalidades. Um projeto open-source sem nenhuma receita não podia arcar com esse custo. O Claude Fable 5 mudou a equação — não por “saber escrever código”, mas por permitir que Sumner projetasse um método de trabalho completamente novo.
Separação entre implementador/revisor: a metodologia de desenvolvimento nativa de IA
Esta é a parte mais subestimada do rewrite do Bun — a metodologia de Sumner, não a capacidade da IA. Ele decomps o processo em cerca de 50 fluxos de trabalho dinâmicos, cada um sendo um loop: um Claude escreve código com base no contexto (ticket do Jira ou issue do GitHub); dois Claudes revisores examinam o código; o feedback é aplicado; a próxima tarefa é assumida. No pico, Sumner executava 4 fluxos concorrentes × 16 Claudes cada = 64 instâncias trabalhando em 4 work trees simultaneamente.
O design crítico: implementador e revisor estão completamente separados. O Claude que escreve quer que seu código seja aceito — o mesmo viés que qualquer engenheiro humano tem. Por isso, os revisores veem apenas o diff, nunca o raciocínio do implementador, e recebem a instrução explícita: “assuma que o código está errado”. Cada implementador enfrenta dois ou mais revisores adversariais cuja única função é encontrar bugs. Isso não é “fazer a IA escrever código”. É projetar uma organização de desenvolvimento de software composta por IA — implementadores, revisores, integradores, cada um com papéis e restrições definidos.
O código Zig era uma única unidade de compilação; o Rust se divide em ~100 crates. O primeiro cargo check gerou ~16.000 erros. Para um humano, catastrófico. Para 64 Claudes em paralelo, uma fila de trabalho administrável: o fluxo agrupava os erros por crate, executava cargo check por crate, um Claude corrigia, dois revisavam, um aplicava. Dois dias depois, os testes que falhavam no Linux caíram de 972 para 23. Um dia e meio depois, o Linux estava verde. Em cinco dias, todas as seis plataformas passaram. A suíte de testes não pulou nem apagou nada.
A transferência dos direitos de code-review
O rewrite do Bun revela uma mudança estrutural: a transferência dos direitos de code-review. O desenvolvimento tradicional trata a revisão de código como a última linha de defesa da qualidade — um PR é aceito depois que pelo menos um engenheiro humano lê cada linha, confirmando lógica, segurança e estilo. Esse mecanismo assume que humanos podem revisar todo o código e têm tempo para isso. O rewrite do Bun quebrou as duas premissas ao mesmo tempo. Um milhão de linhas não pode ser revisado por humanos. E há uma questão mais profunda: mesmo com tempo, humanos conseguem revisar de forma significativa código gerado por IA? Código de IA segue sintaxe correta e restrições de tipos, mas pode fazer coisas semanticamente inesperadas. Um revisor humano diante de código que “parece correto” perde a intuição de que “algo está estranho”, que código escrito por humanos costuma despertar. É por isso que os revisores também precisam ser IA — explicitamente instruídos a assumir que o código está errado.
A transferência ocorre em três estágios. Estágio 1: IA assiste revisão humana (mainstream atual) — a IA faz checagens iniciais, humanos decidem em última instância. GitHub Copilot e CodeRabbit vivem aqui. Estágio 2: IA revisa código gerado por IA (estado atual do Bun) — a IA gera, a IA revisa, humanos revisam a revisão da IA. Os revisores principais do PR são bots; o papel de Sumner é “verificar o trabalho dos revisores”. Estágio 3: IA gera, revisa e mantém — código da geração à manutenção inteiramente por IA, com humanos intervindo apenas em decisões-chave. Após a aquisição, o Bun já opera parcialmente nesse estágio: a única ferramenta capaz de manter essa base de código de forma eficaz é o próprio Claude.
O que esse enquadramento explica
O enquadramento da “transferência dos direitos de code-review” ilumina vários fenômenos. A premissa de mantenibilidade do open-source está sendo derrubada. A premissa central do open-source: o código é público, portanto qualquer um pode revisar, fazer fork e contribuir. Mas quando a escala de uma base de código atinge um ponto em que apenas a IA consegue entendê-la, “público” não equivale a “mantível”. Membros da comunidade já observam que o Bun “não é mais um projeto open-source tradicional — para submeter um PR, você precisa de uma assinatura da Anthropic”. A propriedade do “código nativo de IA” está indefinida. Se o código é gerado, revisado e mantido por IA, quem é o “dono” do projeto? Quem escreve os prompts? Quem fornece o compute? A parte com o modelo mais forte? A aquisição do Bun pela Anthropic não é coincidência — quando sua base de código só pode ser mantida pelo Claude, você está amarrado à Anthropic. O enquadramento se estende a outros domínios. Documentos jurídicos gerados por IA, relatórios financeiros, diagnósticos médicos — quando o conteúdo de IA atinge um volume que humanos não conseguem revisar item por item, quem garante a qualidade? A resposta, como no Bun, pode ser: outra IA. Mas o ciclo de IA revisando IA levanta um problema fundamental de confiança: e se duas IAs coludirem? E se compartilharem os mesmos vieses dos dados de treinamento?
O que nos resta
O rewrite do Bun não é um caso de “IA substituindo programadores”. É um alerta: um abismo crescente separa os ganhos de eficiência da mantenibilidade. Se você é um tomador de decisões técnicas, olhe além do custo de API — os US$ 165.000 são só o ingresso de entrada. O custo real é a “dívida de mantenibilidade”: quando sua base de código só pode ser mantida por uma IA específica, sua escolha de stack tecnológica se torna uma escolha de modelo. Escolher Claude hoje e migrar para Gemini amanhã pode custar mais do que a migração de Zig para Rust. Se você é um mantenedor de open-source, pense bastante na estratégia de revisão de código gerado por IA — não presuma “CI passou, então está tudo bem”. Os testes do Bun passaram todos, e ainda assim restaram 19 regressões e 13.000 blocos unsafe. Considere fluxos de revisão adversarial — não IA escrevendo código, mas IA revisando código. Se você é um desenvolvedor, pare de se concentrar em “escrever prompts melhores”. A parte mais valiosa do rewrite do Bun não é a capacidade da IA, mas a arquitetura de fluxo de trabalho de Sumner: separação implementador/revisor, revisão adversarial, work trees paralelas. Aprender a projetar sistemas de colaboração com IA é 100 vezes mais importante do que aprender a escrever prompts.
O legado final do rewrite do Bun não é a conta de US$ 165.000 nem os 6.778 commits. É uma pergunta: quando o código não exigir mais compreensão humana, ainda precisaremos de desenvolvedores humanos? A resposta pode ser não — mas apenas se aceitarmos um mundo de software mantido por IA.
Referências: Jarred Sumner, “Rewriting Bun in Rust” (bun.com/blog/bun-in-rust) · Cobertura da InfoQ/36Kr, julho de 2026.
