O Harness Era o Produto: Lições da Reescrita do Bun em Rust

O Bun portou 535.496 linhas de Zig para Rust em 11 dias, conduzido por 64 agentes Claude que produziram 6.502 commits. Esse é o número que todo mundo cita. O número que importa mais é 3: a execução de teste começou com três arquivos. Os 1.448 completos vieram só depois. O texto de Jarred Sumner, Rewriting Bun in Rust, se lê como uma história de throughput. Na prática é uma história de harness, e o harness é a parte que você consegue copiar.

Uma revelação logo de início, para você pesar a fonte. O Bun virou uma empresa da Anthropic em dezembro de 2025, Sumner e boa parte do time do Bun trabalham hoje na Anthropic, e ele usou uma versão pré-lançamento do Claude Fable 5 durante boa parte da reescrita. Trate o modelo específico e o enquadramento de marketing com o ceticismo que eles merecem. Os quatro movimentos operacionais por baixo, porém, não dependem de qual modelo os executou. São orquestração, e orquestração é portável.

Os céticos foram barulhentos, e as objeções deles merecem ficar à vista. Na thread do Hacker News sobre o branch de porte, comentaristas invocaram o “Things You Should Never Do” de Joel Spolsky (regra um: nunca reescreva do zero), levantaram a Síndrome do Segundo Sistema e apontaram que o Zig havia recém-rejeitado uma contribuição do Bun sob uma política de “nada de código de IA”. O próprio Sumner chamou o branch de altamente experimental, com, nas palavras dele, “uma chance muito alta de todo esse código ser jogado fora”. Segure essa tensão. A engenharia pode ser excelente e o resultado ainda ficar incerto. O que vem a seguir credita a mecânica sem comprar o veredito.

Se você quer a pergunta companheira, se “revisado por dois agentes” é de fato suficiente para confiar na saída, tratamos disso à parte em revisado por dois agentes é uma alegação. Este texto trata da mecânica de rodar a frota. Se a frota estava certa é outra questão.

Movimento 1: Codifique o contexto compartilhado como arquivos duráveis

Sessenta e quatro agentes não conseguem manter uma conversa. Conseguem ler o mesmo arquivo. Essa distinção é o primeiro movimento inteiro.

A preparação do Bun produziu dois artefatos. O primeiro foi o PORTING.md, um documento de mapeamento de padrões destilado de cerca de três horas de conversa com o Claude sobre como cada idioma do Zig deveria virar um idioma do Rust. O segundo foi o LIFETIMES.tsv, gerado por um workflow dinâmico que leu cada campo de struct em cada arquivo, traçou o fluxo de controle, propôs um lifetime de Rust para cada caso, submeteu a proposta a dois agentes de revisão adversarial e serializou o resultado aceito em uma tabela que outros agentes podiam carregar.

O padrão aqui é contexto-como-artefato, sobre o qual já escrevemos em seu harness, sua memória. Uma frota paralela não tem memória de trabalho compartilhada. Cada agente sobe frio, faz uma unidade de trabalho e morre. Se a verdade sobre “como mapeamos uma union taggeada” mora na janela de contexto de um agente, os outros 63 vão cada um inventar a própria resposta, e você recebe 64 dialetos de Rust. Escrever essa decisão no PORTING.md colapsa 64 palpites em uma consulta.

O LIFETIMES.tsv é o exemplo mais afiado, porque lifetimes são exatamente onde um porte para Rust dá errado. Em vez de deixar cada agente raciocinar sobre ownership do zero (lento, e inconsistente entre agentes), a fase de preparação fez o raciocínio uma vez, de forma adversarial, e congelou a resposta em uma linha por caso. Um agente implementador não decide mais um lifetime. Ele lê um.

A regra copiável: antes de escalar uma frota, pergunte com o que todo agente precisa concordar, e escreva esse acordo em um arquivo que os agentes leem ao subir. O artefato precisa ser durável e inspecionável, algo que você consegue diffar, revisar e regenerar. Um prompt não serve.

Movimento 2: Reduza o risco com uma execução de teste antes de escalar

O trabalho completo era de 1.448 arquivos. A primeira execução foi de 3.

Este é o movimento que a maioria dos times pula, porque três arquivos parecem um erro de arredondamento contra mil e quinhentos. É a redução de risco mais barata que você jamais vai comprar. Nesses três arquivos, o Bun rodou o loop exato que pretendia rodar em escala: um agente implementador escreveu o arquivo .rs, dois agentes revisores adversariais checaram que ele batia com o comportamento do .zig original e honrava o PORTING.md mais o LIFETIMES.tsv, e um agente corretor aplicou as sugestões aceitas. Quatro papéis, um arquivo, rodado até o fim antes de qualquer coisa escalar.

Uma execução de teste responde perguntas que um prompt não responde. O revisor pega desvio comportamental real, ou carimba de qualquer jeito? O corretor aplica sugestões de forma limpa, ou introduz quebras novas? Os dois artefatos de fato contêm o que o implementador precisa, ou há uma lacuna que só aparece sob carga? Três arquivos revelam essas respostas pelo preço de três arquivos. Mil e quinhentos arquivos as revelam pelo preço de mil e quinhentos.

A economia é dura. Um defeito de loop encontrado no arquivo 3 custa três arquivos de retrabalho. O mesmo defeito encontrado no arquivo 900 já contaminou 897 commits. Escalar um loop não provado multiplica o raio de impacto de cada falha que o loop contém, e não economiza tempo algum.

A regra copiável: nunca rode uma frota em largura total na primeira execução. Escolha o menor N que exercita o loop completo, rode até o fim, inspecione a saída à mão, e só então alargue. A execução de teste economiza muito mais do que custa: separa depurar um loop de depurar a saída dele na escala de mil e quinhentos arquivos.

Movimento 3: Restrinja o ambiente de operação, e deixe a falha ensinar as restrições

A primeira tentativa da execução completa falhou, e a falha não estava no código. Agentes paralelos, cada um tentando gerenciar o próprio estado de trabalho, rodaram git stash, git stash pop e um git reset forçado. Esses comandos são globais. O reset forçado de um agente apagou o trabalho não commitado de outro. Os agentes estavam pisando uns nos outros através do próprio sistema de controle de versão.

O conserto foi para o workflow, não para o código. Sumner proibiu qualquer comando git não atômico: nada de stash, nada de reset, nenhuma operação que muta estado compartilhado de um jeito que outro agente possa observar em pleno voo. Ele também baniu cargo e outros comandos lentos do loop do agente, porque um comando lento é uma janela longa durante a qual o estado pode derivar e agentes podem colidir. O ambiente de operação ficou mais estreito, de propósito, e as colisões pararam.

Este é o movimento que só a falha ensina, e ele mapeia direto para um perigo que catalogamos no andar de dados da stack de contenção de agentes: agentes corrompem o substrato compartilhado através de operações que são perfeitamente legais em isolamento. Um humano rodando git stash está bem, porque um humano roda um de cada vez. Sessenta e quatro agentes rodando git stash ao mesmo tempo são um evento de perda de dados. O comando nunca foi o problema em um mundo de um ator só. A concorrência o transformou em um.

A regra copiável: enumere toda operação no seu loop de agente que toca estado compartilhado de forma não atômica, e proíba as que podem colidir. Você não vai prever todas de antemão. Rode a frota, observe-a se corromper, leia a falha, e escreva a restrição. As restrições descobertas pela falha valem mais que as que você adivinhou, porque são as que de fato mordem.

Movimento 4: Shard por worktree para paralelizar sem colisão

Uma vez imposto o git só-atômico, o throughput ainda precisava de estrutura. O Bun dividiu o trabalho em quatro worktrees git separados, cada um rodando 16 instâncias Claude que commitavam e faziam push de arquivos de forma independente. Quatro pistas, dezesseis agentes por pista, sessenta e quatro no total, cada um commitando atomicamente no próprio worktree.

Shard por worktree é a expressão física do mesmo princípio por trás da regra de commit atômico: reduzir a superfície onde agentes disputam. Sessenta e quatro agentes em um diretório de trabalho disputam em cada operação de arquivo. Dezesseis agentes espalhados por quatro worktrees disputam muito menos, porque a maior parte do trabalho fica isolada no próprio checkout, e a superfície compartilhada é um push, que o sistema de controle de versão já sabe serializar. É isso que um agent harness faz na camada de infraestrutura: molda o ambiente para que o paralelismo seja seguro por construção, não por esperança.

No pico, a frota moveu cerca de 1.300 linhas por minuto, cada linha revisada por dois revisores adversariais separados mais uma rodada de correção antes do commit. E aqui está a frase sobre a qual Sumner é honesto: ao fim daqueles 6.502 commits, “absolutamente nada disso funcionava ainda”. Compilação e correção ainda estavam pela frente. O harness entregou throughput. Throughput não é o mesmo que pronto, que é precisamente por que a pergunta de governança do texto companheiro importa.

A regra copiável: quando um único diretório de trabalho vira o ponto de disputa, faça o shard. Dê a cada cluster de agentes um worktree isolado, deixe-os commitar atomicamente lá dentro, e deixe a camada de controle de versão cuidar do merge. Você paraleliza o trabalho ao longo de fronteiras que as ferramentas já sabem defender.

Faça isto agora

Pegue um workflow de agentes que você já roda em paralelo, mesmo com N igual a 2, e audite-o contra os quatro movimentos. Que contexto compartilhado seus agentes estão cada um re-derivando que deveria morar em um arquivo lido ao subir? Você já rodou o loop no menor N possível antes de escalar, ou ele vai direto para largura total? Quais operações no loop tocam estado compartilhado de forma não atômica, e você observou o que acontece quando dois agentes as atingem ao mesmo tempo? Onde está o diretório ou recurso único que todo agente disputa, e dá para fazer o shard?

Os artefatos e as restrições são o harness. O prompt é quase incidental. A reescrita do Bun vale ser estudada não porque uma frota escreveu muito Rust rápido, mas porque o texto mostra exatamente quais quatro decisões transformaram uma pilha de agentes paralelos em um sistema que não se corrompeu. Copie as quatro decisões. Pese as alegações sobre o modelo e o veredito final por conta própria.

Fontes

Bun. “Rewriting Bun in Rust.” Julho de 2026.
Hacker News. “Discussão do guia de porte Zig para Rust.” Julho de 2026.
The Register. “Zig creator calls Bun’s Claude Rust rewrite ‘unreviewed slop’.” Julho de 2026.

A Victorino ajuda times a desenhar o harness, os artefatos e as restrições que deixam uma frota de agentes rodar sem se corromper: contato@victorino.com.br | www.victorino.com.br