1.393 Agentes Refatoraram um Milhão de Linhas. Os Testes Perderam 65 Regressões. A Revisão Pegou.

Dois ensaios publicados em setembro de 2026 defendem que a revisão humana de código está de saída. O título de Allen Hutchison resume a posição: The Test Suite Is the New Code Review. Um post sem assinatura no minid.net vai além e chama a revisão humana de “aproximação histórica para um problema que não sabíamos resolver melhor”, negando que ela seja uma propriedade fundamental da engenharia de software.

No mesmo mês, a Nous Research publicou o maior refactor por enxame de agentes que já vi documentado com números: 1.393 subagentes reescrevendo o código do Hermes, com a suíte de testes como uma das travas. Duas rodadas de revisão da comunidade encontraram, em seguida, duas classes de regressão que os testes existentes não tinham pegado. Vale ler o relato como um teste controlado das teses dos ensaios, conduzido por um time que publicou o que a revisão encontrou depois.

A rodada, nos próprios números

Segundo o relato da Nous, a rodada usou 1.393 subagentes ao longo de cerca de 19 horas ativas, com pico de 218 rodando ao mesmo tempo, 36 grupos sem sobreposição e três níveis de subdelegação. A inferência rodou em Claude Fable 5.1. A execução começou em 2 de setembro e o PR foi mergeado em 4 de setembro. O prompt, como citado na página, diz: “Sem desculpas. Sem esperar minhas decisões. Faça tudo e me apresente um PR ou conjunto de PRs quando terminar.”

O resultado é real. As linhas de Python fora dos testes foram de 1.063.826 para 698.363, um corte de 34,4%. Arquivos com mais de 5.000 linhas caíram de 37 para 6. Funções com mais de 300 linhas caíram de 192 para 2. A cadeia mais longa de if/elif foi de 92 ramos para 9. O arquivo gateway/run.py encolheu de 34.847 linhas para 5.512.

Duas ressalvas da mesma página pertencem ao lado desses números. Seis arquivos ainda passam de 5.000 linhas. A contagem de módulos e as dependências de import subiram.

A linha de custo: cerca de US$ 19.300 em modelo para a rodada principal, cerca de US$ 25 mil incluindo as rodadas posteriores. A própria comparação da Nous para um time humano pequeno fazendo o mesmo trabalho vai de US$ 150 mil a US$ 1,8 milhão, ao longo de dois meses a dois anos. E então uma frase que os ensaios precisariam responder: “Isso exclui o tempo de revisão humana.”

Duas classes de regressão que os testes não pegaram

Os testes existentes não as tinham pegado quando o PR subiu. A revisão da comunidade encontrou duas coisas.

Primeira, nomes públicos removidos. Nas palavras da Nous: “Revisores pegaram nomes públicos que os workers removeram porque não tinham chamadores dentro do repositório, embora plugins externos pudessem importá-los.” Na minha leitura do mecanismo: um worker procurou chamadores, não achou nenhum dentro da árvore e apagou o símbolo. Os testes concordaram, porque os testes também moram dentro da árvore. Os consumidores que poderiam quebrar estavam fora do repositório, invisíveis para o agente e para a suíte.

Segunda, tratamento de exceções. “Uma reescrita automatizada de chamadas suppress() também mudou o tratamento de exceções em cerca de 65 pontos. Eram regressões reais que os testes existentes deixaram passar.” Uma reescrita mecânica aplicada de forma uniforme, errada em cerca de 65 pontos, e os testes existentes não pegaram nenhum deles. A página registra que mais correções vieram depois do merge.

As duas classes têm a mesma forma. A suíte de testes codifica o comportamento que alguém já pensou em afirmar. Uma interface pública sem chamador interno e um caminho de exceção sem teste são exatamente os lugares onde ninguém afirmou nada. Um enxame que otimiza contra a suíte vai encontrar esses lugares, porque é onde a suíte não oferece resistência.

Hutchison e o minid.net têm razão em dizer que outras práticas conseguem absorver boa parte do que a revisão faz hoje. Já argumentamos o mesmo em Seu Code Review É Um Controle Fazendo Cinco Trabalhos, e a lista fica lá. Os dados da Nous acrescentam o que aquele ensaio só podia afirmar: depois que quatro desses trabalhos migram para pareamento, sessões de design e checagens automáticas, o que sobra é a leitura de fronteira e de raio de impacto que pegou essas duas classes.

Os três controles que os ensaios deixam de fora

O conteúdo mais útil do relato da Nous é o conjunto de controles que a rodada usou e que nenhum dos dois ensaios, na leitura que fizemos, descreve.

Uma baseline congelada. Quando um worker encontrava uma falha, a instrução era reproduzir em origin/main HEAD num ambiente limpo, para verificar se a falha já existia. Sem isso, um enxame atribui cada teste vermelho que encontra à própria mudança e começa a consertar o que não quebrou, ou o contrário, marca a própria quebra como herdada. A baseline é o que faz de uma rodada aprovada uma afirmação sobre o diff em vez de sobre o repositório inteiro.

Diffs de preservação de interface. O JSON schema de uma ferramenta tinha de ser idêntico antes e depois. A saída de ajuda de um CLI era comparada byte a byte. É uma trava separada da suíte, voltada a outra pergunta: a forma do que expomos mudou? O relato descreve esse controle para schemas de ferramentas e superfícies de CLI. Os nomes Python removidos foram encontrados por revisores, o que sugere que a mesma checagem, estendida a símbolos públicos, os teria pegado antes.

Isolamento e checkpoints. Cada worker rodou no próprio git worktree e fez commit depois de cada passo verificado. Isso limita o raio de impacto de um passo ruim a um worktree e um commit.

Nenhuma dessas ideias é nova. Juntas, são a diferença entre “deixamos os agentes rodarem contra a suíte” e uma rodada cujas falhas eram localizáveis depois. Hutchison defende a suíte como trava. O minid.net defende que a revisão nunca foi fundamental. A rodada que de fato foi mergeada usou a suíte, mais uma baseline, mais um diff de interface, mais isolamento por worker, mais revisão humana, e ainda assim entrou com regressões.

A linha de custo que exclui a revisão

A evidência do próprio Hutchison é uma divisão de repositório. Um pull request no repositório extraído groups passa no CI em cerca de dois minutos, contra treze no monorepo, o antes e depois de um único repositório dele. A heurística dele para o que merece repositório próprio: “um trabalho claro, um dono e uma API estreita o bastante para caber numa frase.” É uma regra sensata e uma amostra de um. O post do minid.net não traz dado algum, então vale apenas como posição declarada.

A página da Nous tem um benchmark próprio, e ele merece o mesmo escrutínio. As buscas de símbolos melhoraram: a média de tokens por busca caiu de 2.218 para 993, e as buscas que precisavam de uma segunda janela de leitura caíram de 628 para 184 em 4.000. A busca mediana, na verdade, passou a retornar mais tokens. A média caiu porque as maiores definições encolheram. A Nous é explícita sobre o escopo: “não medimos agentes completando tarefas de engenharia.” O refactor tornou o código mais barato de consultar. Se tornou os agentes melhores em terminar trabalho, ninguém mediu.

Então os números que importam para um time decidindo como travar a saída de agentes são estes. Custo de modelo de cerca de US$ 19.300. Tempo de revisão humana fora dessa conta. Cerca de 65 regressões, mais um número não declarado de nomes públicos removidos, que os testes existentes não pegaram e a revisão humana encontrou, com mais correções após o merge. Quem cita a linha de custo como o preço do refactor está citando a parte que foi medida.

Faça isso agora

Se agentes vão escrever nos seus repositórios neste trimestre, tome três ações antes de adotar como política a posição de Hutchison de que a suíte é a trava.

Adicione um diff de interface ao CI, separado da suíte. Exporte todo símbolo público, schema de ferramenta, texto de ajuda de CLI e rota de API antes e depois da mudança, e compare. Qualquer remoção bloqueia até um humano confirmar que não há consumidores externos. É o controle que pega a primeira classe de regressão da Nous.
Congele a baseline em toda rodada de enxame. Antes da rodada, registre o resultado da suíte num checkout limpo da main. Durante a rodada, toda falha é reproduzida contra essa baseline primeiro. Um worker não conserta uma falha que não consegue atribuir ao próprio diff.
Orce a revisão humana como item de custo e roteie por risco. A Nous excluiu o tempo de revisão dos US$ 19.300. Faça o inverso: registre. Depois, estreite. Reescritas mecânicas aplicadas em escala (o caso do suppress()) e qualquer coisa que remova um nome público vão para um humano. O que o diff de interface e a suíte cobrem com folga fica sem revisão. Onde essa trava se posiciona no caminho de escrita é a pergunta que mapeamos em Quatro Relatos de Escrita por Agente, e a barra do que conta como aprovado deve vir dos seus próprios PRs mergeados.

Hutchison prevê um futuro em que a suíte substitui a revisão. A maior rodada que li este mês usou a suíte, outros quatro controles e duas rodadas de revisão, e ainda precisou de correções depois do merge. Planeje para essa rodada, e deixe a previsão para depois.

Fontes

Nous Research. “Refactoring Hermes with 1,393 agents.” Setembro de 2026.
Allen Hutchison (Vycari). “The Test Suite Is the New Code Review.” Setembro de 2026.
minid.net. “Three +1s and a prayer.” Setembro de 2026.

A Victorino ajuda times de engenharia a desenhar as travas entre a saída dos agentes e a branch principal (diffs de interface, baseline congelada e revisão roteada por risco): contato@victorino.com.br | www.victorino.com.br