'Revisado por Dois Agentes' É uma Alegação. Teste-a como Tal.

Jarred Sumner portou 535.496 linhas de Zig, distribuídas em 1.448 arquivos, para Rust em 11 dias, de 3 a 14 de maio de 2026. Seus agentes produziram cerca de um milhão de linhas de Rust em 6.502 commits, com pico próximo de 1.300 linhas por minuto. Nenhum humano leu essas linhas do jeito que um revisor lê um pull request. Ninguém conseguiria. Então o time de Bun substituiu essa leitura por outra evidência de que o código estava correto: dois revisores adversariais por tarefa, uma suíte de testes já existente e um fluxo de trabalho desenhado para corrigir o processo que gerava o código.

Essa substituição é a parte interessante, e é a parte que merece discussão. Quando a IA escreve um milhão de linhas, a revisão humana linha a linha deixa de ser um controle. Algo precisa ocupar o lugar dela. O que ocupa esse lugar vira a alegação de governança, e uma alegação de governança só é tão forte quanto seu histórico de pegar aquilo que prometeu pegar.

Andrew Kelley, criador do Zig, publicou uma réplica que nomeia a pergunta por baixo da polêmica. Deixe a guerra de linguagens de lado. A questão real é se a evidência substituta algum dia foi forte o bastante para liberar a saída que agora estava sendo encarregada de liberar.

Um fato afia essa alegação. A Bun virou uma empresa da Anthropic em dezembro de 2025, Sumner e boa parte do time de Bun trabalham na Anthropic, e ele conduziu grande parte da reescrita com um modelo Claude pré-lançamento. Quem escreveu o código, o fornecedor que deu o modelo, os agentes que revisaram e a organização que atesta o resultado são a mesma parte. Isso não torna o trabalho errado. Significa que a evidência de correção precisa sustentar mais peso, porque nenhum revisor independente está no circuito.

O que Sumner de fato construiu

O fluxo de trabalho não foi descuidado. Foi engenhado, e a engenharia merece um relato justo.

Sumner rodou até 64 instâncias do Claude em quatro worktrees do git. Cada unidade de trabalho passava por uma esteira fixa: um implementador escrevia o código, dois revisores adversariais recebiam apenas o diff com a instrução de encontrar bugs, e um corretor resolvia o que eles achavam. Cerca de 50 fluxos dinâmicos coordenavam a frota. A execução consumiu 5,9 bilhões de tokens de entrada não cacheados e 690 milhões de tokens de saída, cerca de US$ 165.000 no preço de API. Após o merge, o time encontrou e corrigiu 19 regressões.

A motivação foi dor concreta, em vez de busca por novidade. Bun misturava a coleta de lixo do JavaScriptCore com o gerenciamento manual de memória do Zig, e a costura entre os dois produzia use-after-free recorrentes, double-frees e vazamentos. Em março, um bug no próprio bundler de Bun emitiu source maps quando fora instruído a suprimi-los, vazando código-fonte. O modelo de ownership do Rust fecha uma classe desses erros em tempo de compilação. A reescrita tem uma justificativa técnica coerente.

Dois revisores adversariais por diff é mais escrutínio do que a maioria dos times humanos aplica na maioria dos pull requests. Corrigir o processo que gera o código, em vez de remendar cada saída, é o instinto certo em escala. Nos seus próprios termos, foi uma operação rigorosa.

A alegação por baixo do fluxo

A frase mais afiada de Kelley não é sobre Rust. “A questão principal aqui não teve nada a ver com os recursos de linguagem do Zig contra os do Rust”, escreveu ele, “e teve tudo a ver com os sistemas de valores divergentes.” Então formulou o desafio diretamente: “O argumento para enviar todas as milhões de linhas de código não revisado é que a suíte de testes é boa o bastante para pegar tudo. Ela não é suficiente para pegar bugs em código Zig, mas é suficiente para pegar bugs em um milhão de linhas de slop não revisado?”

Leia isso como pergunta de engenharia, não como provocação. A mesma suíte de testes que governava a base Zig agora é o portão primário sobre dez vezes mais código, quase todo nunca lido por um humano. O trabalho da suíte não mudou; o volume que ela precisa pegar multiplicou. Para ser um portão suficiente agora, ela teria de ser muito mais forte do que a própria história sugere.

Porque conhecemos essa história. A razão da reescrita é que a base Zig continuava enviando bugs de corrupção de memória e, uma vez, vazou o próprio código-fonte. Esses defeitos escaparam do exato sistema de verificação em que agora se confia para certificar um milhão de linhas não lidas. Kelley também relata que o time de Bun disse ao time de Zig que “não estava fazendo fuzzing de nada”, o que remove uma das ferramentas mais fortes que uma suíte poderia usar para achar bugs de memória em volume.

A credibilidade de um sistema de verificação se mede pelos defeitos que historicamente passaram por ele, jamais pela quantidade de asserções que ele contém. O próprio histórico de bugs de Bun é a evidência sobre aquela suíte, e o registro diz que a suíte deixou passar bugs reais e sérios.

Dois revisores adversariais também são uma alegação

O arranjo dos revisores tem a mesma propriedade. Dar a dois agentes apenas o diff e mandá-los achar bugs é um desenho que soa forte. Se é de fato forte, essa é uma pergunta empírica com resposta empírica: sobre um conjunto rotulado de defeitos passados conhecidos, que fração esses dois revisores teriam pego?

Ninguém rodou esse teste antes de confiar nos revisores em volume. Cobrimos por que isso importa em por que agentes burlam os testes que os avaliam: um sinal de verificação que nunca foi medido contra defeitos reais que escaparam é uma alegação vestida de controle. Dois revisores olhando um diff sem contexto do programa inteiro compartilham pontos cegos. Bugs de tempo de vida de memória e use-after-free são exatamente a classe que um revisor limitado ao diff, sem visão do ciclo de vida completo do objeto, está pior posicionado para enxergar. E esses são justamente os bugs que motivaram a reescrita. Os revisores eram mais fortes em pegar erros locais e mais fracos em pegar a categoria de que o projeto mais precisava.

É assim que a dívida de verificação se acumula. Cada portão não medido parece cobertura. Empilhe portões suficientes e o sistema reporta alta confiança construída inteiramente sobre proxies não testados. As 19 regressões achadas após o merge são a porção visível. A porção invisível é tudo aquilo que a suíte e os revisores eram estruturalmente incapazes de pegar, o que por definição não aparece na contagem pós-merge.

O teste a rodar antes de confiar no portão

Nada disso diz que Sumner foi imprudente ou que reescritas por IA são ilegítimas. Diz algo mais estreito e mais útil. Antes de um sistema de verificação virar o único portão sobre código gerado por IA em volume, estabeleça a taxa histórica de escape de defeitos dele naquela base. O rigor do processo importa menos aqui. A força comprovada daquilo em que o processo se apoia é a pergunta.

Faça isto antes da sua próxima mudança grande assistida por IA:

Puxe o histórico de defeitos da suíte em que você está prestes a confiar. Liste os últimos 20 a 50 bugs de produção. Para cada um, faça uma pergunta simples: a suíte de testes atual teria pego isso antes do release? Separe em pegos e escapados. A pilha dos escapados é o seu retrato real de cobertura, e costuma ser pior do que a contagem de asserções sugere.

Caracterize os bugs que escaparam. Se eles se agrupam em uma categoria, tempo de vida de memória, concorrência e estado entre módulos são os agrupamentos usuais, então essa categoria é o ponto cego estrutural do seu portão. Gerar dez vezes mais código não encolhe esse ponto cego. Alimenta ele.

Pontue seus revisores contra defeitos rotulados. Pegue bugs passados conhecidos, entregue aos seus revisores agentes os diffs que os introduziram, e meça a taxa de captura. Um revisor que pega 90% dos problemas de estilo e 30% dos bugs de tempo de vida funciona como portão de estilo com um ponto cego de tempo de vida. Chamá-lo de portão geral seria ilusão. Descubra qual dos dois você tem antes de enviar um milhão de linhas atrás dele.

Então decida o que o portão consegue carregar. Uma suíte com taxa de escape conhecida de 30% em bugs de memória pode liberar código com poucas preocupações de segurança de memória. Não pode, sozinha, liberar um milhão de linhas de gerenciamento manual de memória. A força da evidência tem de corresponder ao risco do código que ela certifica.

O processo de Sumner foi genuinamente mais rigoroso do que a maioria dos times consegue. O ponto de Kelley sobrevive a esse fato: rigor aplicado a uma suíte não comprovada continua não comprovado. A suíte que deixou vazar código em março é a mesma suíte que certificou um milhão de linhas em maio. Antes de deixar um sistema de verificação liberar saída de IA em volume, faça-o mostrar o registro. Um portão que você nunca testou é uma esperança com um sinal de verde.

---

Fontes

• The Register. “Zig creator calls Bun’s Claude Rust rewrite ‘unreviewed slop’.” Julho de 2026.
• Andrew Kelley. “My Thoughts on the Bun Rust Rewrite.” Julho de 2026.
• Bun. “Rewriting Bun in Rust.” Julho de 2026.

A Victorino ajuda empresas a medir se seus sistemas de verificação são fortes o bastante para liberar código gerado por IA: contato@victorino.com.br | www.victorino.com.br