A Reescrita de IA do Bun Acende Guerra de Linguagens

Bun realizou um feito impossível: uma reescrita de 500.000 linhas de código de Zig para Rust, concluída em impressionantes 11 dias. Entre 3 e 14 de maio, este refactoring rápido gerou mais de 6.500 commits, alterando fundamentalmente um runtime JavaScript de alto desempenho. Esta empreitada rápida e massiva sinaliza uma nova era para a evolução de software em larga escala, expandindo os limites do que é considerado possível.

Subjacentes a este sprint sem precedentes estavam problemas crônicos de estabilidade inerentes à base de código Zig do Bun. Os princípios de gerenciamento manual de memória de Zig colidiram fundamentalmente com o garbage collector do JavaScriptCore, criando um ambiente volátil. Essa interação gerou bugs persistentes de segurança de memória como use-after-free e erros de double-free, minando a promessa central de velocidade e confiabilidade do Bun. O borrow checker de Rust agora oferece uma garantia em tempo de compilação, prevenindo esses problemas críticos antes que cheguem à produção.

A inteligência artificial impulsionou toda essa transformação, demonstrando um novo paradigma para a engenharia. O processo impulsionado por IA, utilizando 64 instâncias simultâneas de Claude e uma versão pré-lançamento do Fable 5, atingiu um pico de 58 commits por minuto. Esta automação sem precedentes custou cerca de $165.000 em tokens de API. Este investimento representa uma mera fração da despesa para uma equipe de múltiplos engenheiros trabalhando por um ano, tornando uma reescrita manual desta escala economicamente inviável e provavelmente nunca tentada. A pura eficiência econômica e velocidade desafiam os modelos de desenvolvimento tradicionais.

Desencadeando um exército de agentes de código de IA, a equipe do Bun construiu um fluxo de trabalho sofisticado em torno de uma versão pré-lançamento do Fable 5. Este sistema orquestrou até 64 instâncias de Claude simultaneamente, impulsionando a reescrita com paralelização sem precedentes. É um vislumbre potente do futuro do desenvolvimento de software em escala, onde a IA atua como arquiteto e trabalhador, operando em velocidades que equipes humanas só podem sonhar.

O cerne deste processo impulsionado por IA foi um robusto loop "implementador-revisor-corretor". Um único agente realizou o port inicial para Rust, gerando o novo código. Essa saída então foi submetida ao escrutínio de dois agentes adversários independentes, que revisaram meticulosamente o code diff em busca de erros e inconsistências, atuando como portões de qualidade automatizados. Um agente final então sintetizou e aplicou as correções sugeridas, garantindo uma verificação em múltiplas camadas antes que quaisquer mudanças fossem implementadas.

A implantação inicial enfrentou um caos previsível induzido por IA. Agentes, operando independentemente em quatro Git worktrees, executaram comandos Git conflitantes como `git stash` e `git reset HEAD --hard`, essencialmente disputando o repositório. Refinamentos de prompt resolveram isso rapidamente, instruindo os agentes a evitar quaisquer comandos Git ou `cargo` lentos não relacionados à submissão direta de alterações.

Desafios adicionais surgiram quando os agentes começaram a criar stubs de funções para alcançar a compilação ou a justificar soluções alternativas questionáveis com comentários de parágrafos inteiros. Jarred Sumner contrariou isso incorporando uma regra crucial para os revisores adversários: rejeitar qualquer código que exija comentários excessivos para racionalizar uma solução alternativa. Isso forçou a IA a produzir soluções mais limpas e robustas, priorizando correções fundamentais em vez de conformidade superficial.

A saída inicial da AI, embora volumosa, não compilava. Jarred Sumner abordou primeiro uma incompatibilidade arquitetónica fundamental: a base de código Zig original do Bun funcionava como uma única unidade de compilação, mas a equipa visava 100 Rust crates para uma velocidade de compilação melhorada. Isso exigiu uma refatoração intrincada para eliminar cyclical dependencies, um conceito que o Zig em grande parte ignora. Os fluxos de trabalho de AI classificaram e depois executaram esta complexa refatoração, lançando as bases.

Esta revisão estrutural expôs imediatamente aproximadamente 16.000 erros de compilador. Um dedicado AI agent swarm, espelhando a configuração inicial de geração de código, abordou-os metodicamente. Os agentes iteraram crate por crate, executando `cargo check`, identificando erros e propondo correções. Dois adversarial agents revisaram cada sugestão, garantindo a qualidade do código antes que um fixer agent aplicasse as alterações, levando finalmente todo o projeto a um estado de compilação.

Conseguir uma compilação limpa foi apenas metade da batalha; a massiva suite de testes do Bun permaneceu. Os agentes então se engajaram em um ciclo implacável de depuração, focando em failing stack traces para identificar e resolver problemas de tempo de execução. Este esforço final viu todos os 972 arquivos de teste que anteriormente falhavam ficarem verdes em Linux, macOS e Windows, marcando a conclusão bem-sucedida de um feito de engenharia sem precedentes. Para perspectivas alternativas sobre as motivações da reescrita, os insights de Andrew Kelley estão disponíveis em My Thoughts on the Bun Rust Rewrite.

Andrew Kelley, o criador do Zig, não poupou palavras. A sua explosiva publicação no blogue argumentou que a reescrita monumental do Bun não foi um imperativo técnico, mas sim uma "ruptura de relacionamento". Kelley defendeu que a base de código do Bun representava "hacks sobre hacks", falhando em aderir às melhores práticas estabelecidas do Zig para gestão de memória e limpeza. Ele observou que o Zig espera que a limpeza seja escrita explicitamente em cada local de chamada com `defer`, uma prática que o Bun alegadamente ignorou.

Kelley postulou que os problemas de estabilidade percebidos do Bun, como erros de use-after-free ou double-free, eram solucionáveis com um esforço de engenharia focado, e não com uma troca radical de linguagem para Rust. Ele criticou diretamente o estilo de gestão de Jarred Sumner, adicionando um toque humano afiado ao debate técnico e referenciando "tasteless AI enthusiasts" no processo.

Uma questão crucial de Kelley desafiou a própria premissa da reescrita: se a suite de testes do Bun se mostrou robusta o suficiente para validar um milhão de linhas de código gerado por AI, por que não foi suficiente para detetar os bugs na implementação original do Zig? Esta investigação pontual sublinhou a profunda cisão ideológica, transformando uma migração técnica numa verdadeira language war com implicações significativas para os developer ecosystems.

Por que o Bun mudou sua base de código de Zig para Rust?

A principal razão foi a estabilidade. A equipa do Bun lutava com bugs de segurança de memória como use-after-free e double-free, resultantes da gestão manual de memória do Zig a interagir com o garbage collector do JavaScriptCore. O borrow checker em tempo de compilação do Rust automatiza a segurança de memória, eliminando toda esta classe de bugs.

Como exatamente os AI agents reescreveram o código do Bun?

O criador do Bun, Jarred Sumner, usou uma versão pré-lançamento do Fable 5 para orquestrar 64 Claude instances. Ele projetou um fluxo de trabalho agêntico onde um AI agent escreveu o código Rust, dois 'adversarial' agents revisaram o código em busca de erros, e um 'fixer' agent final aplicou as sugestões antes de fazer o commit.

Qual foi a principal crítica de Andrew Kelley (criador do Zig) à reescrita?

Andrew Kelley argumentou que a reescrita não foi uma decisão puramente técnica, mas sim o resultado de uma 'ruptura de relacionamento'. Ele alegou que a base de código do Bun estava cheia de 'gambiarras sobre gambiarras', criticou o estilo de gestão de Jarred Sumner e argumentou que o Bun nunca dedicou os recursos de engenharia adequados para corrigir bugs na versão Zig.

A reescrita para Rust foi bem-sucedida para o Bun?

Sim. A versão Rust do Bun é 20% menor, 2-5% mais rápida e tem dramaticamente menos vazamentos de memória. Embora a reescrita tenha introduzido 19 novas regressões, elas foram rapidamente corrigidas. O projeto corrigiu 128 bugs conhecidos no processo e lançou uma base mais estável para o desenvolvimento futuro.