Bun reescreve 535 mil linhas de Zig para Rust em 4 meses com ajuda de IA, eliminando vazamentos de memória
Jarred Sumner, criador do Bun, anunciou recentemente que o Bun — um runtime, bundler e gerenciador de pacotes para JavaScript e TypeScript — foi completamente reescrito de Zig para Rust. O objetivo da reescrita é eliminar vulnerabilidades recorrentes de segurança de memória por meio do borrow checker do Rust. A reescrita assistida por IA foi concluída em 4 meses de trabalho, em vez dos 12 meses estimados.
Sumner resumiu a motivação por trás do que começou como um teste:
Uma grande porcentagem dos bugs [...] são use-after-free, double-free e "esqueci de liberar a memória" em um caminho de erro. No Rust seguro, esses são erros do compilador e limpeza automática similar a RAII com Drop. Erros do compilador são um ciclo de feedback melhor do que um guia de estilo. Historicamente, reescritas são uma péssima ideia. [...] Bun tem 535.496 linhas de Zig. Uma reescrita em outra linguagem levaria a um pequeno time de engenheiros um ano inteiro. Significaria congelar correções de bugs, correções de segurança ou desenvolvimento de features por todo esse tempo. Felizmente, a própria suíte de testes do Bun é escrita em TypeScript, o que significa que não depende da linguagem de programação do runtime. E se, em vez disso, eu gastasse uma semana testando se o novo modelo da Anthropic consegue reescrever Bun em Rust? No começo, eu não esperava que funcionasse. Poucos dias depois, uma alta porcentagem da suíte de testes começou a passar e vi como o novo código Rust se alinhava com a base de código Zig original. Minha opinião mudou de "isso vale a pena tentar" para "vou fazer o merge disso".
Arquitetura da reescrita com IA
Sumner executou uma porta automatizada all-at-once aproveitando, para a maior parte da reescrita, uma versão pré-lançamento do Claude Fable 5 orquestrado em aproximadamente 50 workflows dinâmicos. O código Zig seria transpilado para Rust (possivelmente usando Rust unsafe que poderia ser refatorado depois) e validado contra a suíte de testes existente com mais de um milhão de assertions. Um guia de porting ajudaria Claude a mapear padrões e tipos de Zig para padrões e tipos de Rust. Revisões de código adversárias por agentes detectariam problemas antes que chegassem ao port final. O loop de implementação seria melhorado após cada erro, aprimorando o processo de implementação em vez de corrigir manualmente os artefatos de implementação (por exemplo, o código).
O processo constante de melhoria revelou padrões úteis. A fase de planejamento é crítica para o sucesso e deve resultar na antecipação e mitigação dos principais desafios. O arquivo PORTING.md (descrevendo o mapeamento de Zig para Rust) e o arquivo LIFETIMES.tsv (descrevendo os tempos de vida de cada campo de struct na base de código) foram fatores-chave de sucesso para o port.
Um agente implementador usaria esses arquivos para traduzir arquivos Zig em código Rust. O agente implementador enfrentaria dois agentes revisores adversários executados em janelas de contexto isoladas com acesso apenas aos diffs de arquivo, tendo como única tarefa descobrir bugs e divergências comportamentais. Sumner enfatiza:
O implementador não revisa. O revisor não implementa.
Sugestões e problemas encontrados pelos agentes revisores eram tratados por um agente corretor.
Paralelização e recursos computacionais
A eficiência do processo de implementação aproveita massivamente a paralelização das tarefas de implementação. Isso, porém, requer lidar com atualizações concorrentes da base de código compartilhada e a falta de recursos computacionais limitados.
O esforço foi distribuído entre quatro shards de workspace executando 16 agentes cada, operando 64 instâncias de Claude em paralelo. No pico de velocidade, o sistema gerava aproximadamente 1.300 linhas de código por minuto e registrava até 695 commits por hora.
Para que a suíte de testes completa passasse, foram necessários US$ 165 mil em tokens — em contraste com a estimativa de Sumner do esforço de engenharia humana:
Pré-merge, isso levou 5,9 bilhões de tokens de entrada sem cache, 690 milhões de tokens de saída e 72 bilhões de leituras de token de entrada em cache — aproximadamente US$ 165 mil no preço da API. À mão, acho que isso teria levado 3 engenheiros com contexto completo da base de código cerca de um ano.
Testes e validação
Ter mais de 1 milhão de linhas de código passando na suíte de testes foi seguido por testes e validação adicionais, que revelaram problemas adicionais.
A natureza mecânica do port introduziu 19 regressões semânticas sutis enraizadas em similaridades sintáticas entre Zig e Rust. 11 rounds de revisão de segurança do Claude Code Security corrigiram vários problemas de segurança. Fuzzing 24/7 orientado por cobertura de cada parser em Bun resultou em 15 PRs.
De acordo com o time do Bun, a implementação Rust resultante no Bun v1.4.0 resolveu 128 bugs de longa duração presentes na v1.3.14 enquanto entregava benefícios notáveis. Vazamentos de memória nativa foram tratados. Testes de bundling in-process executando 2.000 operações consecutivas de Bun.build() ficaram estáveis em 609 MB em Rust em vez de ultrapassar 6,7 GB. A taxa de transferência HTTP aumentou de 2% a 5%.
O Bun v1.4.0 foi finalmente lançado em agosto de 2026.
Reações críticas
Andrew Kelley, criador de Zig, publicou uma reação criticamente aguçada intitulada "My Thoughts on the Bun Rust Rewrite", que incluiu os seguintes comentários:
Há uma dicotomia sendo apresentada onde você tem que escolher entre um "guia de estilo" ou um recurso de linguagem de programação para evitar bugs. O truque distrai o leitor da principal forma como os bugs são eliminados: dedicando recursos de engenharia a isso. [...] O argumento para enviar todo o milhão de linhas de código não revisado é que a suíte de testes é boa o suficiente para pegar tudo. Então por que você está dizendo que tem tantos bugs irritantes no código Zig? O que aconteceu com a suíte de testes sendo suficiente para pegar tudo? Não é suficiente para pegar bugs no código Zig mas é suficiente para pegar bugs em 1 milhão de linhas de lixo não revisado?
Concorrentemente, o usuário vitaminCPP sugeriu que fazer merge de mais de um milhão de linhas de código transpilado por máquina estabelece Bun como um canário crítico da indústria para saber se enormes bases de código geradas por LLM podem permanecer mantíveis ao longo do ciclo de vida da engenharia de software.
Observe que o Bun foi adquirido pela Anthropic em dezembro de 2025.
