Revisão por Camadas de Risco: Como a Anthropic Governa 30.000 Mudanças por Dia

Claude escreve aproximadamente 90% do código do próprio Claude Code. O monorepo da Anthropic saiu de 2.500 mudanças por dia em maio para mais de 30.000 em setembro. Os pull requests mergeados no repositório do Claude Code mais que dobraram de junho a setembro, no mesmo período.

Esses números são o pano de fundo para uma pergunta que toda organização de engenharia operando agentes vai enfrentar: quando o volume de código ultrapassa a capacidade de leitura humana, o que substitui a revisão linha por linha?

A Anthropic publicou sua resposta em 15 de outubro. O ensaio, escrito por Addy Osmani, Morgan Westlee Lunt e Qing Wang, descreve um sistema construído em torno de um princípio operacional: otimizar para o mínimo de tempo humano de revisão que não aumente reverts ou incidentes.

A Mudança: De Portão a Verificação Contínua

Revisão de código tradicional é um portão no final do caminho. Escreva o código, abra um pull request, espere pelo colega. A 30.000 mudanças por dia, o portão quebra. A fila cresce. Revisores leem por cima. A qualidade cai exatamente quando o volume mais exige.

A Anthropic reformulou a pergunta. Em vez de “um humano leu este código?”, o time pergunta: “o que pode dar errado com esta mudança, e qual verificação (automatizada ou humana) é a certa para capturar isso?”

A revisão agora roda de forma contínua. A maioria das mudanças passa por verificações automatizadas, uma revisão pelo Claude e uma revisão de segurança antes que um humano precise olhar. O revisor de IA lê o diff contra o repositório completo e a intenção declarada do PR. Achados são verificados por agentes separados antes de chegar aos humanos. Cada achado recebe a tag Important, Nit ou Pre-existing, para que um bug que o PR não introduziu não pareça culpa do autor.

A proporção de PRs internos recebendo comentários substanciais de revisão saltou de 16% para 54% após o lançamento do revisor de IA.

Três Camadas de Risco, Não Um Processo Único

O desenho central de governança é um classificador de risco que atribui cada mudança a uma de três camadas:

Risco baixo (docs, copy, features internas, mudanças aditivas atrás de flag): zero aprovações humanas após revisão automatizada e verificações de segurança passarem.

Risco médio (mudanças de produto comuns, caching, auto-updater, system prompts): uma pessoa.

Risco alto (o código mais sensível, mais um conjunto de caminhos que sempre exigem duas pessoas): duas pessoas.

A mudança define a camada, não o autor. Um classificador lê o diff e escolhe o nível de risco. Um segundo classificador pergunta se aquela mudança específica precisa de uma pessoa mesmo quando a camada diz que não. Alguns caminhos sempre exigem um humano: qualquer coisa que code owners tenham listado como sensível e qualquer arquivo de workflow de CI.

Uma regra é absoluta: aprovação de agente nunca conta como aprovação de humano. Revisão automatizada pode liberar uma mudança de baixo risco, mas não pode preencher um slot que exige uma pessoa.

Convergência: Parando o Loop Infinito

Autores-agente e revisores-agente podem manter um ao outro ocupados indefinidamente. Um pull request de CLI passou por mais de cinquenta rounds de revisão e correção durante a noite antes que o autor o parasse.

Quando o time rodou git blame no que o revisor continuava flagging, cerca de 59% era código presente desde o primeiro passe do revisor. O revisor não estava encontrando bugs novos. Estava encontrando mais bugs antigos a cada rodada.

A correção foi estrutural:

Um teto de rodadas. Após três rounds, o revisor pede ao autor que reconsidere a abordagem.
Re-revisão apenas do diff após os passos iniciais.
Classificar o tipo de bug para que o autor corrija toda instância, não uma linha.
Sem repetição de achados já postados.

Os resultados: 65% dos PRs passavam após um round de revisão antes das mudanças. Depois: 78%.

Incidentes como Evals

O time coletou PRs passados que causaram incidentes, junto com seus fix-forwards e reverts. Engenheiros que conhecem cada área do código confirmaram cada bug e onde ele vivia. O revisor roda contra esse conjunto diariamente. Toda mudança nos prompts, ferramentas ou modelo do revisor é pontuada contra todos os casos. Pontuação subiu? Mantém. Caiu? Descarta.

Isso fecha o loop entre falhas de produção e qualidade de revisão. O conjunto de eval cresce com cada incidente, e cada mudança no revisor é medida contra todos eles.

”Você Mergeia, Você Responde”

Quem comandou a mudança é responsável por ela. Em um PR escrito por agente, a pessoa que dirigiu o agente conta como um dos revisores obrigatórios, da mesma forma que se tivesse digitado o código. Uma aprovação cobre um commit específico. Se commits novos chegam sem que o sistema consiga atestar (push de agente, merge resolvido manualmente), a aprovação é invalidada.

Essa é a fronteira de accountability que torna as camadas de risco viáveis. Sem propriedade clara, caminhos de revisão mais leves viram passivo. Com ela, cada camada carrega um nome.

Várias práticas de suporte impedem que o modelo de propriedade colapse. Mudanças são pequenas e fáceis de reverter. Feature flags desligam sem deploy. Releases graduais enviam o comportamento novo para funcionários da Anthropic primeiro, depois para o canal latest, depois para stable. O raio de impacto define a barra de revisão. Regressões aparecem rápido via telemetria e uso interno.

O Que Isso Significa para Outros Times

O sistema da Anthropic foi construído para a escala da Anthropic. Poucos times operam a 30.000 mudanças por dia. As partes transferíveis são os princípios, não a infraestrutura.

Classificação de risco substitui revisão uniforme. Nem toda mudança carrega a mesma consequência. Tratar todas igualmente desperdiça atenção humana em diffs de baixo risco e sub-investe nos de alto risco.

Aprovação de agente é estruturalmente separada de aprovação humana. Um revisor de IA pode sinalizar, filtrar e priorizar. Não pode carregar accountability. Os slots são diferentes.

Incidentes alimentam o revisor. A qualidade da revisão é medida contra falhas reais de produção. O conjunto de eval cresce com cada incidente.

Convergência é um objetivo explícito de design. Sem controle, loops de revisão automatizada rodam para sempre. Tetos de rodada, re-revisão apenas do diff e regras de não-repetição existem como governança, não como otimização de performance.

Escrevemos sobre a lacuna de governança na revisão de código assistida por IA e sobre camadas de intenção como governança invisível. O sistema da Anthropic é a primeira implementação publicada que preenche essas lacunas em escala, com resultados medidos.

Fontes

Osmani, Addy; Lunt, Morgan Westlee; Wang, Qing. “Solving Code Review at Anthropic.” Outubro de 2026.

A Victorino ajuda equipes a construir revisão de código com camadas de risco para código escrito por agentes. contato@victorino.com.br | www.victorino.com.br