Como está avançando a reescrita do Bun em Rust?

• Embora tenha sido divulgada como um trabalho concluído em 11 dias, em 27 de julho de 2026, 6 semanas após o merge no main, ainda não havia tag de release, e o trabalho relacionado continuava
• A reescrita inicial consumiu US$ 165 mil em custos de API da Anthropic entre 3 e 14 de maio de 2026, mas isso aparentemente não inclui os custos de Buildkite CI/CD nem do trabalho posterior
• Os PRs abertos de robobun aumentaram de 1.277 em 9 de julho para 2.475 em 27 de julho; se o pipeline levar cerca de 40 minutos por PR, seria preciso executá-lo continuamente por 86 dias para processar tudo
• O uso do Claude disparou junto com o início da reescrita, e a participação de robobun e de funcionários da Anthropic em trabalho de Rust também aumentou, então é difícil cravar o momento de conclusão e o custo total real em US$ 165 mil
• Como a equipe do Bun não afirmou diretamente que a reescrita foi concluída nem qual foi o custo total, para usar resultados de coding com IA como base de avaliação de valor empresarial é preciso olhar também para o valor gerado em relação ao custo e a intervenção humana contínua

---

A reescrita continua mesmo após o merge

• Jarred Sumner afirmou em Rewriting Bun in Rust que gastou US$ 165 mil em chamadas da API da Anthropic durante 11 dias, de 3 a 14 de maio de 2026, e fez o merge do resultado da reescrita no main
  • Isso dá cerca de US$ 15 mil por dia, um valor difícil de bancar para muitos mantenedores de open source
  • Os custos de CI/CD, que aparentemente continuaram rodando no cluster Buildkite da organização, não parecem estar incluídos nesse número
• Em 27 de julho de 2026, já haviam se passado 6 semanas desde o merge, mas ainda não havia uma nova tag de release; desde a última tag, bun-v1.3.14, já se passaram 11 semanas
  • Antes disso, a última vez que houve mais de um mês sem release foi o intervalo de 6 semanas entre v0.2.2, em 26 de outubro de 2022, e v0.3.0, em 7 de dezembro
• Os PRs abertos de robobun, um indicador indireto dos PRs criados pelo Claude Code, subiram de 1.277 em 9 de julho para 2.475 em 27 de julho
  • Foi observado que as verificações do Buildkite e o merge no main normalmente levam cerca de 40 minutos, às vezes até 1 hora e 30 minutos
  • Aplicando 40 minutos por PR, seriam necessários 86 dias de execução contínua do pipeline para fazer merge de todos os 2.475
  • Alguns PRs não têm relação com código Rust, e há PRs individuais que passaram por uma quantidade muito grande de revisão

A diferença entre o custo divulgado e o esforço real

• No início da reescrita, o uso do Claude aumentou fortemente, e depois também cresceu a participação de funcionários da Anthropic e de robobun em trabalho de Rust
  • A análise inclui a suposição de que os commits de Jarred Sumner durante o período de reescrita usaram Claude
  • Como alguns PRs foram escritos por funcionários da Anthropic, é preciso considerar não só o custo de tokens, mas também a intervenção direta dos funcionários
• Se assumirmos que a reescrita continuou custando US$ 10 mil por dia, o custo acumulado se aproximaria de US$ 800 mil, mas isso é uma estimativa baseada em hipótese, não um custo real divulgado
• A equipe do Bun não afirmou que a reescrita foi totalmente concluída nem que o custo total foi de apenas US$ 165 mil
  • Só este caso não basta para concluir que a IA já substituiu mais rapidamente o trabalho de mantenedores de open source
  • A Anthropic está aplicando suas próprias ferramentas internamente, e tanto o trabalho automatizado quanto a participação de funcionários continuam
• Em vez de negar a IA em si, o texto alerta para as expectativas excessivas e a avaliação de valor empresarial, defendendo analisar se o valor gerado compensou o custo investido e se a avaliação dessa empresa é justificável
• O compilador C da Anthropic e o navegador web FastRender da Cursor estão sem commits há vários meses

[GN⁺]

Comentários do Hacker News

• A reescrita em Rust do Bun está em produção no Claude Code há mais de um mês, mas quase ninguém percebeu, e no geral está funcionando bem
  Não pretendem lançar antes de passar nos testes de compatibilidade com Node.js no nível prometido no vídeo do Bun v1.4; se o PR relacionado for mergeado, há boa chance de lançar a v1.4 por volta da próxima terça-feira

  • Podem gastar o tempo necessário para garantir a qualidade do software. Ficar um mês sem lançamento não é grande coisa, e se algum recurso for urgente, dá para contribuir ou fazer o build por conta própria
    Até o Node.js, tirando correções de segurança, costuma passar de 4 a 6 semanas todo dezembro sem lançamentos significativos, então essa crítica, feita em tom irritado sem nem perguntar primeiro aos envolvidos, tem pouca base. Digo isso como mantenedor do Node.js
  • O próprio Claude Code tem bugs e incidentes frequentes após lançamentos, então não é surpreendente que os usuários não tenham conseguido distinguir bugs causados pela migração do Bun para Rust dos bugs normais de sempre
  • Fiquei curioso se alguém pode responder sobre os custos estimados no texto, especialmente os custos do Buildkite
  • Entendo por que isso gera preocupação com o futuro do Bun: muitos projetos de vibe coding começam com força e depois podem ser abandonados, como o Anthropic C. O Bun é rápido e agradável de usar, então espero que dure por muito tempo, como o GCC

• Depois de um grande refactor ou de uma reescrita em larga escala, é normal levar um tempo para recuperar o ritmo habitual de desenvolvimento, então é difícil concluir muita coisa olhando só para a quantidade de commits e a cadência de releases
  Mesmo que os desenvolvedores conheçam a estrutura, eles ainda precisam se readaptar ao codebase em Rust e provavelmente estão focados em tarefas como rastrear usos de unsafe, não em recursos visíveis para o usuário. Como quase não foram percebidos grandes problemas nem mudanças no canal canário, há bons motivos para resolver pendências em vez de apressar o lançamento
  Vi o compilador C da Anthropic e o navegador FastRender do Cursor mais como experimentos de capacidade do que como projetos contínuos, e espero que ninguém esteja dependendo deles diretamente agora

  • Todos os usuários do Claude Code foram migrados para a nova versão há um mês, então, em certo sentido, isso já foi um lançamento em produção. Como recebe bastante atenção e não há necessidade de correr para o lançamento oficial, parece que estão fazendo isso de forma gradual
  • A perspectiva de custos de CI/CD é interessante. Normalmente, ao contestar o ROI de IA, diz-se que mais código não significa mais valor, mas se cada execução de CI é cobrada, a receita real aumenta
    Isso também se conecta ao fato de que CI e testes adicionais são essenciais para impedir que trabalho repetitivo gerado por IA saia do controle
  • Mesmo do ponto de vista de quem escreveu o texto, não está claro o quanto dá para concluir a partir desses números. Espero que, após o próximo release, a Anthropic ou o Bun publiquem uma retrospectiva revelando o custo total

• É impressionante usar LLMs para traduzir um projeto em pouco tempo ou criar de uma vez um clone de um produto de escritório, mas a essência do software não está na geração inicial rápida, e sim em desenvolvimento de funcionalidades e manutenção de longo prazo
  Um clone do Word também pode ganhar funções básicas rapidamente, mas é nos detalhes — estrutura de página, tabelas, imagens, rotação — que as LLMs começam a falhar. Mesmo que você porte o SQLite de C para Rust e passe em todos os testes, ele provavelmente ainda será mais lento por não ter anos de otimizações da implementação anterior, e ainda será preciso lidar com novos bugs trazidos pela mudança de linguagem e com o suporte futuro
  No Reddit, vivem aparecendo projetos dizendo que implementaram X, Y e Z, mas correção de bugs, suporte a usuários, segurança e trabalho com estruturas de dados e bancos de dados em evolução não são atraentes, então acabam sendo abandonados ainda mais rápido do que o vibe coding avança
  Se você não entende profundamente o software que criou, ele acaba explodindo, e a frase reescrevi X em Z em Y dias por si só não significa nada. Acelerar o começo e entender, evoluir e manter o código portado são coisas totalmente diferentes, e os resultados de busca podem acabar poluídos por uma versão em Rust abandonada e posts promocionais, enquanto a versão em Zig continua sendo mantida

  • Gostaria que mais gente documentasse esse processo. Pessoalmente, estou aprendendo ao criar projetos com forte dependência de LLM, e quando recursos complexos começam a funcionar rápido isso dá uma sensação muito forte de prazer, mas integração, organização e polimento de UI ficam ainda mais dolorosos depois que você prova a velocidade inicial
    Quando o código fica emaranhado demais em soluções improvisadas, chega-se a um ponto de inércia em que a LLM não consegue mais avançar sem gerar uma confusão ainda maior; aí é preciso corrigir a arquitetura, jogar tudo fora e recomeçar, ou voltar até o último ponto em que tudo ainda estava normal. É como desenvolver com um jetpack: você chega mais rápido ao objetivo, mas também bate na parede mais rápido e com mais dor
    No meio das discussões sobre se a IA é a melhor ou a pior coisa do mundo e das disputas sobre como usar ferramentas, falta informação sobre o que funciona e o que falha, e sobre como adaptar o próprio comportamento durante o uso. Até quero escrever um relato de uso, mas criar recursos novos ou corrigir defeitos de UI é mais divertido, então vou adiando
  • No GitHub já existiam, antes mesmo das LLMs, milhares de engines de jogo e compiladores para linguagens inventadas que foram abandonados. Nos fóruns de sistemas operacionais do começo dos anos 2000, quase todo mundo fazia o próprio OS, e alguns chegavam até a rodar o Firefox
    Nem todo software precisa ser comercial ou altamente polido para ser útil; experimentos de aprendizado por si só já podem ensinar muita coisa
  • Quanto mais fundo se vai na parte técnica, mais fácil é ser visto como algo substituível. Isso vem da premissa, comum nas organizações, de que o valor nasce da capacidade técnica pura, e não de você ou das suas relações
    Mas parece que as pessoas estão começando a aceitar que fatores contingentes como efeitos de rede, propriedade e responsabilização também importam. Ainda assim, há o paradoxo de que muitos técnicos entraram na área justamente para fugir de ambientes em que nepotismo, avaliações arbitrárias e papo furado valem mais do que competência técnica
  • Trabalhei numa startup que parou até o desenvolvimento de funcionalidades para reescrever completamente um codebase grande, mas, mesmo tendo perdido todo o processo por estar em outro projeto, quando voltei quase não houve curva de aprendizado
    Isso porque, embora a linguagem tivesse mudado, a arquitetura central, as estruturas de dados e os conceitos continuavam os mesmos. O Bun também não foi redesenhado do zero; primeiro foi apenas portado para a nova linguagem. Mesmo olhando para experiências anteriores às LLMs, se a meta é fazer o time migrar rápido, o certo é portar para outra linguagem da forma mais simples e rápida possível, então minimizar os X dias da reescrita é um bom objetivo
  • A postura de não entender profundamente o próprio código é um caso de curtoprazismo extremo. Os mantenedores vão aprender da forma difícil onde está a fronteira entre código gerado por IA e código que um ser humano consegue manter

• Alguém disse que modernizou a implementação original em Zig e aplicou boas práticas para corrigir bugs, alcançando build incremental em menos de 1 segundo. Isso sugere que o problema que justificou a reescrita foi, na verdade, autoinfligido e solucionável por conta própria
  https://ziggit.dev/t/buz-a-drop-in-replacement-for-bun-using...
  A versão em Zig também usa LLM, então isso não tem relação com guerra cultural. Quem realmente entende bem o domínio do problema sempre pôde obter resultados melhores do que quem apenas despeja recursos como centenas de milhares de dólares em tokens

  • O ponto central que justificou a reescrita não era a velocidade de build, mas os bugs de memória, especialmente ao interagir com objetos JavaScript gerenciados por coleta de lixo. Em Zig não há um meio geral de bloquear isso, e também não parece haver alegação de que o Buz tenha resolvido esse problema
  • Este projeto parece mais um meme ou uma piada do que uma tentativa séria. Ele define as 600 mil linhas existentes como código caótico gerado por IA e declara que rejeitará contribuições escritas por humanos até que a maioria dos subsistemas seja reescrita
    É difícil levar a sério um projeto que quer arrumar código bagunçado com LLM enquanto proíbe contribuições humanas

• Graças à reescrita do Bun, passaram a tentar com muito mais ousadia portar e reescrever código, além de vendorizar dependências externas, e isso permite especializar mais para necessidades internas mesmo que não se encaixe em projetos upstream
  Ao mesmo tempo em que passaram a delegar tarefas mais ambiciosas aos modelos de código, também passaram a focar muito mais em harnesses de teste e validação fora das fronteiras da linguagem. Já participei de grandes reescritas ao longo de vários anos, mas avalio o Bun, que manteve testes e equivalência funcional enquanto ainda adicionava melhorias, como um enorme sucesso de engenharia

• Na discussão em torno da reescrita do Bun há muita condenação dramática e ataques pessoais, e parece que cada lado projeta interesses ideológicos mais profundos. Este texto é cético sobre até que ponto a IA pode substituir programadores com sucesso, e o ponto levantado pelo mantenedor de Zig estava mais próximo da ética e do futuro do open source na era dos LLMs
  Para quem vê as capacidades da IA com otimismo, não há grande motivo para duvidar que um desenvolvedor experiente possa conduzir LLMs de ponta para traduzir bibliotecas inteiras. As perguntas de acompanhamento mais importantes são o custo atual e se no futuro haverá uma divisão entre o campo de adoção total de IA e o de não adoção

  • Não havia ninguém com experiência em Rust na equipe
  • O port de Zig→Rust do Bun oferece pouquíssimas lições que possam ser generalizadas sobre Zig, Rust, portabilidade entre linguagens ou uso de LLMs. Há características demais nos codebases antes e depois que são difíceis de quantificar, além da interferência de preferências sobre linguagens, método de port e coding com LLM
    Se não se obtém o mesmo resultado ou se o custo em tokens é maior, pode-se dizer que a ferramenta foi usada de forma errada; se o resultado for decepcionante, pode-se escapar dizendo que era apenas uma prova de conceito e que os modelos melhoraram nos últimos 6 meses, então não dá para comparar, o que dificulta chegar a uma conclusão verificável
  • Há muitos motivos para ver os LLMs com ceticismo, porque eles são excelentes em produzir resultados plausíveis, mas errados. Independentemente da veracidade do resultado, este trabalho é claramente um evento de marketing, e a Anthropic tem histórico de anúncios exagerados ou factualmente incorretos, então é necessária uma verificação mais rigorosa

• Suspeitei que tanto o anúncio declarando vitória quanto a análise aprofundada que parecia sincera foram um tanto precipitados
  O principal risco da febre dos LLMs é oferecer resultados imediatos a desenvolvedores experientes cansados de digitação e raciocínio manual, ao custo de hipotecar décadas de experiência acumulada em software. A conta de verdade chega muito mais tarde

  • Digitação é secundária em engenharia de software, mas os LLMs podem ter valor em situações em que ela realmente é o gargalo. Só que essas situações são raras

• A confiabilidade do texto aumentaria se ele refletisse o fato de que o Bun baseado em Rust está em produção no Claude Code desde 17 de junho e também foi disponibilizado em versão canary depois de entrar na main. Para uma reescrita desse porte, um longo período em canary é totalmente justificável

  • O texto já tratou do uso interno em produção na Anthropic

• A Anthropic talvez não tenha muito interesse em lançar publicamente a próxima versão. A versão em Rust já está em produção há mais de um mês no Claude Code, usado por milhões de pessoas, e é possível que o objetivo da aquisição do Bun também tenha sido o Claude Code
  O projeto open source em si pode não ser tão importante para eles

  • Se o que realmente importasse fosse apenas o Claude Code, teria sido muito mais eficiente reescrever o próprio Claude Code em Rust do que mudar a linguagem do runtime TypeScript. O custo de cerca de 800 mil dólares pode ter saído do orçamento de marketing da Anthropic, mirando um grande efeito promocional
  • É improvável que abandonem a comunidade mais ampla, e quanto mais outros usuários houver, mais a Anthropic também se beneficia. Se houver problemas neste lançamento, podem receber críticas fortes e perder a confiança da comunidade, então parecem estar sendo mais cautelosos do que o normal
  • O Bun é um componente importante do ecossistema web, então o simples fato de a Anthropic desenvolvê-lo com IA já gera um enorme efeito promocional
  • O Claude Code provavelmente poderia rodar em qualquer runtime JavaScript, então fico me perguntando por que o Bun era necessário
  • No fim, parece um evento de marketing para anunciar reescrita de código com Claude. A mensagem de que, para eliminar um codebase incômodo, basta gastar muito dinheiro com a Anthropic foi transmitida com sucesso
    Se o objetivo era o Claude Code, poderiam ter começado reescrevendo isso; e se vinham enfatizando que já não escrevem código diretamente, então a linguagem de implementação também não deveria importar

• Quem já reescreveu software consegue entender a etapa atual. A maior parte funciona, mas ainda é preciso continuar corrigindo para evitar regressões, e a pressão em torno do lançamento também é enorme
  Acho que a decisão de reescrever foi correta, mas eu não iria querer colocar isso em produção desde o começo. Se, em vez de lançar logo a versão estável, o Jarred oferecesse primeiro uma release candidate, isso reduziria a pressão