Como a equipe do Claude Code faz revisão de código: sete etapas e nenhum circuit breaker

Em 15 de outubro de 2026, a equipe do Claude Code publicou seu próprio relato sobre como revisa código, um artigo de engenharia de quatorze minutos atribuído a Addy Osmani, Morgan Westlee Lunt e Qing Wang. A frase que explica por que alguém está procurando isso aparece logo no início: Claude escreve cerca de 90 por cento do próprio código do Claude Code. O artigo não é uma defesa desse número, mas uma descrição do maquinário que precisou existir por baixo dele antes que fosse algo sustentável, e as partes que merecem uma leitura atenta são as que ainda estão faltando.

A maioria dos resumos para nos dois números de destaque: os pull requests mesclados no código-base do Claude Code mais que dobraram entre junho e setembro de 2026, enquanto a parcela que precisou ser revertida caiu mais de 40 por cento. Ambos vêm da própria equipe, e ambos podem ser produzidos por vários arranjos diferentes, incluindo o que as pessoas presumem, que é que a revisão foi silenciosamente removida. O post diz que não foi. Eles transferiram a maior parte da leitura para máquinas, otimizaram para o tempo e a atenção humanos e investiram em tornar os erros rápidos e fáceis de desfazer. Todo o resto é o detalhe de como.

Por que a revisão se tornou o gargalo em primeiro lugar

A pressão não veio de uma decisão de política. Veio do volume. No monorepo da Anthropic, relata o post, as mudanças integradas por dia passaram de cerca de 2.500 em maio para mais de 30.000 em setembro de 2026. O Claude Code fica em seu próprio repositório, separado desse monorepo, mas está sob a mesma pressão em menor escala.

Nesse ritmo, o post admite, a revisão manual linha por linha é incrivelmente difícil, se não impossível. Ninguém ali está afirmando que um humano ler cada diff é desnecessário. Eles estão afirmando que ler cada diff não escala mais e que "um humano leu o código" sempre foi um proxy impreciso para a questão que importa: o que poderia dar errado com essa mudança e qual verificação, automatizada ou humana, é a certa para detectá-lo.

Quando dito dessa forma, o portão se desloca. A revisão deixa de ser uma porta no fim do caminho e passa a ser contínua, mais próxima da verificação ortográfica enquanto você escreve. A maioria das alterações já foi lida e corrigida pelo Claude antes de uma pessoa olhar.

Para o que eles otimizaram e o que conta como falha

O objetivo declarado é que a maioria dos pull requests nos repositórios do Claude Code, que o post descreve como a CLI, os aplicativos desktop e web e os aplicativos móveis, seja mesclada com no máximo uma pessoa no circuito, que pode ser o autor, sem aumento de reversões ou incidentes. A terceira cláusula é o que faz disso uma meta real, e não um exercício de redução de custos.

Eles medem o tempo humano nos dois lados do balanço: o tempo que as pessoas passam revisando e o tempo que passam corrigindo o que o código ruim quebra. Reduzir o primeiro não ajuda se o custo reaparece no segundo, e a equipe diz isso diretamente. Assim, os números acompanhados são aprovações humanas por pull request, relatadas como mediana e percentil 95, comentários humanos e quanto tempo um pull request espera por uma pessoa. As taxas de reversão e de incidentes ficam por baixo de tudo isso como a salvaguarda: se aumentarem, o tempo humano não foi economizado, apenas deslocado.

Métricas de custo de revisão são fáceis de manipular em isolamento; um revisor que aprova tudo produz gráficos bonitos de tempo de aprovação. A salvaguarda é o que impede o gráfico de mentir.

Sete etapas, não um único portão

O artigo descreve o percurso de uma alteração típica em sete passos numerados. Cada camada deteta alguns problemas e deixa outros passar, e as verificações mais baratas são executadas antes das mais caras.

• Verificação antes de o pull request existir.Claude executa os testes, o build e o linter, e um segundo agente revisa o diff em um contexto novo. Muitos engenheiros também usam skills internas: uma procura bugs, outra simplifica o diff e outra verifica o comportamento de ponta a ponta. Boris Cherny, que criou o Claude Code, disse que dar ao Claude uma forma de verificar o próprio trabalho é provavelmente a coisa mais importante para bons resultados, e estima que isso deixa o resultado final duas a três vezes melhor.

• Revisão por IA em cada pull request. Uma revisão do Claude lê o diff em relação ao repositório inteiro e à intenção declarada do pull request. Vários agentes procuram bugs em paralelo; em seguida, um grupo separado vota em cada descoberta, e ela só é publicada se houver concordância suficiente de que é real. Descobertas sobre estilo, diagnósticos ou limpeza são descartadas. O que sobrevive aparece como comentários inline marcados como Importante, Nit ou Pré-existente. Quando a prévia de pesquisa foi lançada, a proporção de pull requests internos que recebiam comentários substantivos de revisão passou de 16% para 54%. Os administradores definem cada repositório como Rápido, Padrão ou Profundo.

• Revisão de segurança. Uma passagem automatizada separada. Um pull request não pode ser mesclado enquanto houver uma constatação de qualquer uma das revisões em aberto; você a corrige ou encerra a conversa com um breve motivo. A mesma verificação é pública como a GitHub Action de revisão de segurança de código aberto ou o comando /security-review.

• Verificações automatizadas que bloqueiam. Lint, verificações de tipo, testes em todas as plataformas e um build.

• Aprovação humana, proporcional ao risco. Um classificador lê a alteração e define o nível, em vez de o autor defini-lo. Esta etapa ganha sua própria seção abaixo, porque é onde está a maior parte do design interessante.

• Fila de merge, flags e liberação gradual. A fila executa novamente cada verificação contra a main com a alteração aplicada, então dois pull requests que passam individualmente não podem se combinar em uma main quebrada. O novo comportamento é disponibilizado primeiro para funcionários da Anthropic por trás de uma flag, depois para o canal mais recente, com o stable vindo por último.

• Detecção e reversão rápidas. As flags são desativadas sem um deploy, há uma rotação semanal de plantão e as revisões de incidentes perguntam qual camada deveria ter capturado o problema. Alguns erros ainda passarão, então a última camada serve para notá-los rapidamente, em vez de preveni-los.

A alteração define o nível, não o autor.

{{1}}Uma correção na documentação e uma alteração no atualizador automático não têm o mesmo risco, então não recebem a mesma revisão.{{/1}} A tabela do post tem {{2}}três níveis{{/2}} e cada um responde a uma única pergunta: {{3}}quantas pessoas, se houver alguma, precisam aprovar isso antes que seja mesclado.{{/3}}

Baixo abrange documentação, textos de comunicação, recursos apenas internos e mudanças aditivas por trás de uma flag; depois que a revisão automatizada e a segurança estiverem aprovadas, nenhuma pessoa é necessária. Médio abrange mudanças comuns de produto, além de áreas sensíveis como cache, o atualizador automático e prompts de sistema, e exige uma pessoa. Alto abrange o código de maior risco e um pequeno conjunto de caminhos que sempre exigem duas pessoas.

O classificador é apenas metade do design. Um segundo classificador pergunta se esta alteração específica precisa de outra pessoa mesmo quando seu nível diz que não. Alguns caminhos sempre precisam de uma pessoa, independentemente do nível: qualquer coisa que os proprietários tenham listado como sensível e qualquer arquivo de workflow de CI. Apenas autores na lista de confiança do repositório, majoritariamente a equipe proprietária, recebem os caminhos mais leves; todos os demais precisam de uma segunda pessoa. A aprovação de um agente nunca conta como a de uma pessoa, então a revisão automatizada pode liberar uma alteração de baixo risco, mas não pode preencher uma vaga que exige um humano. Quem deu origem à alteração é responsável por ela. E uma aprovação cobre um commit específico, então um novo commit, incluindo um push de um agente ou um merge resolvido manualmente, precisa da aprovação novamente.

Dois detalhes valem a pena ser copiados mesmo que você nunca construa um classificador. O nível vem da mudança, não do autor, e a confiança é uma barreira separada e mais restrita aplicada sobre isso. E uma aprovação fica vinculada a um commit, e não a um pull request, o que fecha a brecha mais comum nos sistemas de revisão: um visto verde conquistado cedo em um branch sendo usado para código que ninguém examinou.

O revisor é treinado contra os seus próprios incidentes

Esta é a parte que a maioria dos textos pula, e explica por que o arranjo continua funcionando em vez de se desviar.

A equipe coletou pull requests antigos que causaram incidentes, junto com seus fix-forwards e reversões, e pediu que engenheiros que conhecem aquele código confirmassem cada bug e onde ele estava. Essa coleção agora é uma avaliação. O revisor é executado contra ela diariamente. Quando seus prompts, ferramentas ou modelo mudam, a mudança precisa sobreviver ao conjunto inteiro: mantenha-a se a pontuação subir, descarte-a se não. As falhas deles se tornaram a suíte de testes para a coisa que deveria detectar suas falhas.

Essa é uma postura diferente de ajustar um linter, que é avaliado com base em um conjunto fixo de regras. Esse revisor é avaliado com base nas formas específicas pelas quais este código já quebrou, então a avaliação cresce toda vez que algo dá errado. Nenhuma pontuação para ele aparece em nada que a Anthropic tenha publicado e que tenhamos lido, e o post não afirma que o revisor está concluído.

A camada que ainda não foi construída

Aqui está a admissão que torna o post crível. Tudo acima descreve um sistema que detecta e reverte erros, não um que percebe quando sua própria taxa de erro muda. A equipe ainda não tem circuit breakers que restrinjam a aprovação automaticamente quando os números de reversões ou incidentes mudam, e os engenheiros de lá querem tê-los antes que mais código passe para merges sem intervenção humana.

O que existe, em vez disso, é a percepção humana. As flags são desligadas sem um deploy, a escala semanal de on-call fica de olho, e as revisões de incidentes perguntam qual camada deveria ter detectado o problema. A frase de um colega é a sentença mais útil para qualquer pessoa planejando um rollout semelhante: desacelerar de fato reduz sua taxa de erro, mas principalmente porque você está fazendo menos de tudo. A equipe prefere ficar mais rápida em perceber e corrigir problemas do que mais lenta em produzi-los.

Leia os sete passos novamente com isso em mente. Seis decidem se uma mudança prossegue. O sétimo é um conjunto de hábitos para notar depois. Não há um ciclo de feedback ligado do resultado de volta ao portão de decisão, e as pessoas que construíram o sistema dizem isso.

O segundo trabalho da revisão, que a postagem em grande parte deixa de lado

O post deixa explícito que a revisão de código faz dois trabalhos: encontrar e corrigir problemas antes do lançamento e construir contexto compartilhado entre a equipe. Ele se concentra no primeiro e depois volta ao segundo com uma resposta incomumente honesta: não há um processo formal para isso, ninguém mantém um modelo mental completo do Claude Code na cabeça, e eles não acham que alguém precise. Quer entender parte da base de código? Peça ao Claude uma explicação exatamente daquele trecho.

Dois arquivos de instruções carregam o contexto que antes vivia na cabeça dos revisores. O CLAUDE.md diz ao Claude o que é o projeto, a stack, as convenções, os objetivos e os não objetivos, mantido curto de propósito. O REVIEW.md é escrito pelos code owners e diz como é uma falha na parte do código deles, quais caminhos ignorar e pede um arquivo e uma linha em vez de um palpite.

A responsabilização tem uma linha própria: você integra, você assume. Faça merge de uma mudança pequena ou média e algo dê errado, e a norma é que você mesmo corrija. Isso funciona porque as mudanças são pequenas, porque flags e reversões desfazem a maioria dos erros em minutos, e porque o raio de impacto define o padrão para quantas verificações uma mudança recebe. É uma norma sobreposta à regra de aprovação, não um substituto para ela.

Onde um router se encaixa e onde não

O pipeline acima é um pipeline de chamadas de modelo: um agente de revisão lendo um diff contra um repositório inteiro, vários agentes caçadores de bugs em paralelo, um grupo votando em cada achado, uma verificação de segurança, e o revisor executado novamente diariamente contra um eval crescente. Isso é um problema de roteamento antes de ser um problema de revisão, porque um provedor ter uma tarde ruim não deveria parar uma fila de merge.

O OrcaRouter é um endpoint compatível com OpenAI para mais de 200 modelos em uma única chave, com failover automático entre provedores e sem markup, ou seja, o preço de tabela do provedor é repassado. Equipes que executam sua própria versão deste pipeline obtêm uma única relação de cobrança e um único lugar para trocar um modelo quando a qualidade de um revisor muda, que é exatamente o que a avaliação diária foi projetada para detectar.

A fronteira importa. Hospedamos modelos. Não hospedamos o Claude Code, não executamos o Code Review for Claude Code e não temos acesso ao pipeline sobre o qual este artigo trata. O Code Review for Claude Code é um produto da Anthropic, disponível de forma geral nos planos Team e Enterprise, com uma versão mais leve disponível localmente como /code-review. Se o que você quer é esse pipeline, é ali que ele fica; na versão dele do seu próprio time, um roteador é uma decisão de infraestrutura, não de revisão.

O que uma equipe menor consegue de fato copiar

Escreva as regras de revisão onde o revisor possa lê-las: um CLAUDE.md curto para o projeto e um REVIEW.md por área que descreva como é a falha e exija um arquivo e uma linha em vez de um palpite. Coloque os níveis de risco por escrito, torne-os uma propriedade da mudança e não do autor, comece rigoroso e relaxe apenas com evidências. Limite o que a revisão automatizada pode aprovar e nunca deixe a aprovação de um agente contar como a de uma pessoa. Vincule aprovações a commits. Execute a fila de merge. Transforme incidentes e reversões em casos de teste e reavalie o revisor sempre que alterá-lo, porque um revisor não medido é um linter com marketing melhor.

Então observe a salvaguarda, não o tempo de aprovação. A própria forma como a equipe enquadra o assunto oferece o teste para qualquer mudança no processo de revisão que você esteja considerando: as taxas de reversão e de incidentes se mantiveram, ou o tempo simplesmente passou do revisor para a pessoa que faz a limpeza depois? Essa pergunta pode ser respondida com dados que a maioria das equipes já tem, e separa um processo que ficou mais rápido de um que só parece mais rápido por um trimestre.