Em 8 de julho, Jarred Sumner, criador do Bun, publicou os números por trás de um trabalho que a maioria das equipes de engenharia teria descartado como impossível. Uma reescrita em Rust do runtime JavaScript, uma base de cerca de um milhão de linhas originalmente escrita em Zig, foi concluída em 11 dias e 6.502 commits, conduzida por até 64 agentes de IA rodando em paralelo. A conta de tokens ficou em torno de US$ 165 mil pelo preço público da API.
A comparação que mais circulou foi o contrafactual: o mesmo trabalho, feito de forma convencional, foi estimado em cerca de um ano para três engenheiros. Em menos de um dia, esse post, uma reescrita rival do Postgres e uma resposta afiada do criador do Zig estavam a menos de 30 pontos de distância no topo do Hacker News. A discussão que se seguiu não é sobre um runtime. É sobre o que acontece quando o custo de reescrever software de base cai duas ordens de grandeza.
O que realmente aconteceu dentro da reescrita
Os números brutos por trás da reescrita em Rust são incomuns o bastante para serem ditos com clareza. A execução consumiu cerca de 5,9 bilhões de tokens de entrada não cacheados e 690 milhões de tokens de saída. Os agentes trabalharam em paralelo, e não em sequência, e por isso o tempo de relógio despencou enquanto o volume de trabalho não. O resultado foi verificado continuamente contra a própria suíte de testes do Bun, que reúne algo na casa de um milhão de asserções.
Essa suíte de testes é a parte que sustenta a história. Um port conduzido por máquina não tem julgamento sobre intenção; tem apenas uma especificação que consegue executar. O Bun tinha em mãos uma das especificações executáveis mais exigentes do ecossistema JavaScript, construída ao longo de quatro anos perseguindo compatibilidade com o Node.js. O número publicado para a build em Rust é de 99,8% de compatibilidade de testes no Linux x64 com glibc.
O que esse número não significa é que a build em Rust seja a que você instala hoje. Ela segue experimental, limitada a uma única plataforma, e não é o binário padrão. A linha estável 1.3.x do Bun continua sendo produzida a partir do código em Zig. Segundo o relato de julho, o código reescrito chegou a usuários dentro do Claude Code v2.1.181 em 17 de junho, o que é um sinal relevante de produção, mas não equivale a um lançamento geral.
Por que um runtime que funciona abandonaria o Zig
Foram dados três motivos, e nenhum deles é velocidade bruta. As duas linguagens compilam para código nativo sem coletor de lixo, e a expectativa declarada publicamente era de que a build em Rust ficasse a poucos pontos percentuais da build em Zig.
O primeiro motivo são pessoas. Rust tem uma comunidade de contribuidores muito maior que Zig e, para um projeto que quer receber patches de fora, o tamanho desse funil é uma restrição de projeto como qualquer outra. O segundo é manutenção em escala, em que o modelo de ownership e o sistema de tipos do Rust movem uma classe de erros do tempo de execução para o tempo de compilação. O terceiro é institucional. O Bun foi adquirido pela Anthropic em dezembro de 2025, e o Claude Code é distribuído como um executável Bun para milhões de usuários. O resumo de Sumner sobre o risco foi direto: se o Bun quebra, o Claude Code quebra. Esse mesmo anúncio assumiu o compromisso de manter o Bun open source sob licença MIT e o desenvolvimento público no GitHub.
Andrew Kelley, criador do Zig, publicou uma refutação no dia seguinte. Sua objeção central é de capacidade de revisão, e não de preferência por linguagem: entregar cerca de um milhão de linhas de código gerado por máquina que nenhum humano leu tem um perfil de risco diferente de entregar um milhão de linhas que uma equipe escreveu e revisou. Ele também questionou com que consistência a suíte de testes foi aplicada. É uma crítica legítima, e a resposta honesta é que ninguém ainda tem um bom método para revisar código nesse volume.
O Postgres recebeu o mesmo tratamento, e os fuzzers responderam
O segundo projeto tornou o trade-off visível. O pgrust, uma reescrita do PostgreSQL em Rust iniciada no começo de abril de 2026 por Michael Malis e Jason Seibel, seguiu um caminho parecido: uma primeira tentativa do zero e, em junho, a troca por conversão automática de C para Rust seguida de reescrita conduzida por IA para um Rust mais seguro.
Em 25 de junho o projeto anunciou que passava em 100% dos mais de 46 mil testes de regressão do PostgreSQL 18.3, além dos testes de isolamento, e que conseguia iniciar a partir de um diretório de dados existente do Postgres. Para um banco de dados, essa é uma barra genuinamente difícil de superar.
Então Andreas Seltenreich, autor do fuzzer SQLsmith, apontou a ferramenta para o resultado em 9 de julho. Em poucos dias ela produziu uma falha de segmentação a partir de uma única linha de SQL, SELECT numrange_subdiff(1,1);, um erro interno em uma instrução MERGE, várias invariantes de planner quebradas e uma validação ausente em literais bytea. Os testes de recuperação estavam em 34 de 47. Os benchmarks publicados foram igualmente duros: cerca de 728 transações por segundo contra 6.365 do PostgreSQL 18.4 original, inicialização cerca de onze vezes mais lenta e mortes por falta de memória sob carga sustentada. A base carrega 2.664 blocos unsafe e 1.835 funções unsafe, um lembrete de que traduzir mecanicamente para Rust não produz automaticamente um Rust seguro em memória.
O kernel resolveu a questão da linguagem anos antes
Perdido no barulho está o fato de que a questão de fundo já foi respondida há algum tempo, e de forma discreta. No Maintainers Summit do kernel Linux, em dezembro de 2025, o consenso foi que Rust no kernel não é mais experimental. Jonathan Corbet, ao relatar o desfecho, resumiu como o experimento tendo terminado e dado certo. O suporte a Rust havia sido incorporado no fim de 2022 e cresceu de forma constante desde então; o summit apenas retirou o rótulo.
Esse caminho levou três anos de revisão humana, subsistema por subsistema, com mantenedores discutindo cada interface. É o oposto de uma corrida de 11 dias, e é por isso que o resultado do kernel é durável. A linguagem nunca foi a parte contestada. A parte contestada é com que velocidade uma base de código pode migrar para ela e ainda assim ser confiável.
O que os números provam e o que não provam
Lidos com cuidado, a reescrita em Rust do Bun e sua equivalente no Postgres sustentam uma afirmação mais estreita do que sugerem as manchetes. Eles mostram que, quando uma base de código tem uma especificação executável ampla, uma frota de agentes já consegue traduzi-la entre linguagens em dias em vez de anos, a um custo que uma única pessoa bem financiada poderia cobrir. Isso é uma mudança real e significativa de capacidade.
Eles não mostram que o resultado esteja pronto para produção. Os resultados de fuzzing do pgrust demonstram exatamente o que uma suíte de regressão não captura: ela verifica o comportamento que alguém pensou em testar, e não o comportamento que ninguém imaginou. A própria postura do Bun, mantendo as versões estáveis em Zig enquanto a build em Rust amadurece, é o sinal mais instrutivo. Quem está mais perto do trabalho o trata como promissor e inacabado, que é a leitura correta.
Há ainda uma questão de manutenção que ninguém respondeu. Uma base produzida em 11 dias continua tendo de ser compreendida por quem for corrigi-la às 3 da manhã daqui a dois anos. Revisabilidade não é um extra em software de base; é o mecanismo pelo qual a confiança se acumula.
O que isso muda para equipes pequenas
Na MW3.biz, lemos isso como uma história de democratização com um asterisco. Uma capacidade que antes exigia uma equipe financiada agora está ao alcance de duas pessoas com um cartão de crédito e uma boa suíte de testes, e essa é a direção para a qual queremos que a tecnologia caminhe. Também achamos que o asterisco importa: os projetos que deram certo aqui foram os que já haviam investido anos em testes, e esse investimento não é algo que um agente consiga adicionar depois. Nossa visão é que ampliar o acesso a esse tipo de ferramenta vale a pena, e que a forma honesta de defender isso é relatar os resultados do fuzzer ao lado da contagem de commits.
A lição prática para uma equipe pequena é pouco glamourosa. A alavanca está na especificação, não no modelo. Se o seu projeto tem uma suíte de testes fraca, uma refatoração conduzida por agentes vai produzir algo que compila, passa no pouco que você escreveu e falha em produção. Se ela for completa, a mesma ferramenta vira um multiplicador de força real, do mesmo modo que os modelos de pesos abertos ampliaram o acesso ao trabalho diário de programação. Passar duas semanas melhorando a cobertura de testes hoje rende mais do que gastar as mesmas duas semanas na refatoração.
Nenhuma das duas reescritas está pronta, e ambas merecem ser acompanhadas em vez de copiadas. O estado atual do port do Bun e a lista de issues abertas do pgrust vão dizer mais nos próximos seis meses do que qualquer benchmark isolado diz hoje. O que já mudou foi o preço de tentar.
