Anthropic revela como faz a revisão de código que o Claude escreve em 90% dos casos

A Anthropic mostrou como é o code review quando quase todo o código é escrito por um modelo. Cerca de 90% do código do Claude Code é criado pelo próprio Claude, e a atenção humana virou o recurso mais escasso. A equipe definiu a meta assim: o mínimo de tempo humano em revisão, com o mesmo nível de rollbacks e incidentes. Entre junho e setembro, o número de merges mais que dobrou, e a taxa de rollbacks caiu mais de 40%.

As métricas foram escolhidas com certa astúcia de engenharia. A equipe otimiza o número de aprovações por PR, o número de comentários e o tempo de espera da pessoa. Rollbacks e incidentes funcionam como um limitador: se eles sobem, o ganho de velocidade não conta.

Um pipeline de sete camadas em que o humano entra tarde

O sistema é formado por filtros sequenciais. Cada um tira parte da carga do revisor humano:

• Antes do PR. O próprio Claude roda testes, build e linter. Em seguida, um subagente com contexto limpo examina o diff. Há skills internas para busca de bugs, simplificação do diff e verificação e2e.
• Revisão por IA em cada PR. Vários agentes procuram bugs em paralelo, e um grupo separado vota em cada achado. Comentários puramente de estilo são descartados. Os achados são classificados como Important, Nit e Pre-existing, para que um bug antigo não seja atribuído ao autor. Cada achado exige uma resposta. Depois do lançamento do preview, a parcela de PRs com comentários relevantes subiu de 16% para 54%.
• Revisão de segurança. Ela bloqueia o merge.
• CI convencional. Lint, checagem de tipos e testes em todas as plataformas.
• Aprovação por risco. Um classificador define quantas pessoas são necessárias. Documentação, textos e features atrás de flag exigem zero pessoas, mudanças comuns exigem uma, e as mais críticas exigem duas. Billing, autoupdater e workflows de CI sempre exigem um humano.
• Rollout. Merge queue e flags. Primeiro a mudança chega aos usuários internos, depois ao canal latest e, por fim, ao stable.
• Rollback rápido.

A lógica é a seguinte: verificações automáticas baratas eliminam o que é óbvio, e o caro tempo humano é gasto onde o custo de um erro é alto.

Quando o agente autor e o agente revisor passam a noite se corrigindo

O trecho mais revelador da análise trata de loops infinitos. O agente autor e o agente revisor podem trocar correções sem parar. Um PR passou por mais de 50 rodadas durante a noite, até que o autor interrompeu o processo. A análise mostrou que cerca de 59% dos comentários diziam respeito a código antigo. A cada rodada, o revisor encontrava mais alguns bugs herdados, e não novos erros na mudança.

Em termos de tokens, isso é puro desperdício: cada rodada é paga com o contexto do diff, a execução de vários agentes e a votação. A equipe criou um limite de três rodadas, e agora a revisão repetida examina apenas o diff novo. A marcação Pre-existing resolve a outra metade do problema: a dívida antiga fica visível, mas não bloqueia o PR de outra pessoa.

Há ainda um mecanismo de controle de qualidade do próprio revisor. Cada incidente passado vira um eval, e o revisor é testado nesses casos todos os dias. Qualquer mudança de prompt ou de modelo que piore a pontuação sofre rollback. O agente revisor é testado como qualquer componente de produção.

Quatro regras que valem para qualquer equipe

A análise traz um conjunto de princípios que não dependem da infraestrutura da Anthropic:

• O nível de risco é definido pela mudança, e não pelo autor.
• O caminho simplificado só está disponível para autores confiáveis.
• A aprovação de um agente nunca conta como aprovação humana.
• Quem delegou a tarefa ao agente responde pelo código como se o tivesse escrito.

Para equipes em que os agentes já escrevem uma fatia relevante do código, isso se traduz em um plano concreto. O ponto de partida é classificar os caminhos do repositório por risco: o que pode entrar por merge sem humano e o que sempre exige revisão, como billing e CI na Anthropic. Depois, é preciso montar uma revisão multiagente com votação e marcação dos achados, limitar o número de rodadas e criar evals próprios a partir de incidentes reais. Para quem não quer montar tudo por conta própria, o Code Review para o Claude Code está em GA nos planos Team e Enterprise. O artigo original foi publicado em claude.dev.