Code review com IA: como o time do Claude Code revisa PRs
O code review com IA deixou de ser um experimento e virou a base do processo de revisão do time que constrói o Claude Code, a ferramenta de programação agêntica da Anthropic. Neste artigo, você vai entender como esse time revisa milhares de mudanças sem ler cada linha manualmente e sem aumentar a taxa de reverts.
Segundo o próprio time, o Claude escreve cerca de 90% do código do Claude Code. Por isso, a pergunta deixou de ser "alguém leu o código?" e passou a ser "qual verificação é a certa para pegar o problema desta mudança?".
Por que o volume de código mudou o code review com IA
Quando agentes escrevem código, a quantidade de mudanças cresce muito rápido. No monorepo da Anthropic, as mudanças diárias saltaram de cerca de 2.500 em maio para mais de 30.000 em setembro de 2026.
O Claude Code vive em um repositório separado, mas sente a mesma pressão. Nesse ritmo, revisar linha por linha de forma manual se torna praticamente inviável.
Mesmo assim, o code review com IA trouxe resultado positivo. Entre junho e setembro, os pull requests aceitos mais que dobraram, enquanto a parcela que precisou de revert caiu mais de 40%.
Em outras palavras, o code review com IA não eliminou a revisão. Na prática, ele moveu a maior parte da leitura para máquinas, preservou a atenção humana e tornou muito mais fácil desfazer erros.
Outra mudança importante foi o momento da revisão. Antes, ela funcionava como um portão no fim do caminho: você escrevia o código, abria o PR e esperava um colega.
Agora, a revisão acontece de forma contínua, parecida com um corretor ortográfico enquanto você digita. Assim, quando uma pessoa olha a mudança, o Claude já revisou e corrigiu o código pelo menos uma vez.
As duas funções de uma revisão de código
Toda revisão de código cumpre dois papéis. O primeiro é encontrar e corrigir problemas antes que cheguem aos usuários.
O segundo é construir contexto compartilhado, ou seja, espalhar o entendimento da base de código pelo time. Quem lê o diff de um colega aprende o que mudou e como as peças se encaixam.
No time do Claude Code, o code review com IA ataca principalmente o primeiro papel. Contudo, o time também propõe uma resposta nova para o segundo.
O recurso escasso é a atenção humana
O objetivo declarado do time é reservar o tempo das pessoas para problemas que só pessoas resolvem. Todo o resto fica com verificações automatizadas.
Esse tempo humano tem dois lados. De um lado está o tempo gasto revisando, e do outro está o tempo gasto consertando o que um código ruim quebrou.
Reduzir o primeiro não ajuda se o custo simplesmente reaparece no segundo. Por isso, a meta é que a maioria dos PRs avance com no máximo uma pessoa envolvida, que pode ser o próprio autor, sem aumento de reverts ou incidentes.
Para medir isso, o time acompanha aprovações humanas por PR (mediana e percentil 95), comentários humanos e quanto tempo um PR espera por alguém. Além disso, as taxas de revert e de incidentes funcionam como guarda-corpo do processo.
Se essas taxas sobem, o time não economizou tempo humano, apenas o empurrou para depois.
As camadas do code review com IA no Claude Code
Uma mudança típica sai do notebook de um engenheiro, ou de uma sessão do Claude no Slack, e passa por várias camadas de verificação. Cada camada pega alguns problemas e deixa outros passarem.
Poucos defeitos atravessam todas as camadas do code review com IA. Então, para o que escapa, existe uma última rede de proteção, o rollback rápido.
Verificação antes do pull request
Hoje, a maior parte da revisão acontece antes mesmo de o PR existir. O time dá ao Claude algo que ele consegue executar, como testes, um build ou uma captura de tela para comparar com o design.
O agente mostra a saída em vez de apenas dizer que terminou, e depois um subagente revisa o diff com um contexto limpo.
Boris Cherny, criador do Claude Code, considera a capacidade de verificar o próprio trabalho o fator mais importante para bons resultados. Segundo ele, essa prática deixa o resultado final de duas a três vezes melhor.
Quando o code review com IA aponta o mesmo problema repetidas vezes, o time corrige na origem, com uma skill, uma regra de lint ou um arquivo de instrução.
O arquivo CLAUDE.md descreve o projeto: stack, convenções, objetivos e o que está fora do escopo. Já o REVIEW.md, mantido pelos donos do código, diz ao revisor o que realmente importa em cada parte do repositório.
Os bons arquivos REVIEW.md são curtos, limitam observações de estilo e exigem arquivo e linha como evidência.
# REVIEW.md
## What failure looks like here
- Docs: the text lies about current behavior
- Config: a value misroutes traffic or users
## Rules
- Report at most 3 nits per pull request
- Skip generated files under /dist and /vendor
- Every finding must cite a file and a line number
- Start the summary with the number of findings
- Say "Nothing to fix" when there are no findings
Code review com IA em todo pull request
Todo pull request recebe uma revisão do Claude antes de qualquer pessoa olhar. Esse code review com IA lê o diff contra o repositório inteiro e contra a intenção declarada do PR.
A pergunta central é simples: a mudança resolve o problema, se encaixa no sistema ou quebra outra coisa? Em correções de bug, o revisor também procura a causa raiz.
Quando o time lançou a versão de pré-visualização, a fatia de PRs internos com comentários relevantes saltou de 16% para 54%. Além disso, a maioria dos PRs com mais de 1.000 linhas recebe apontamentos, enquanto os pequenos costumam voltar limpos.
O code review com IA também tem filtros contra falsos positivos: vários agentes procuram bugs em paralelo e outro grupo vota em cada achado.
O comentário só aparece no PR se a maioria concordar que o problema é real. Assim, achados que tratam apenas de estilo ou limpeza ficam de fora.
O que sobra aparece como comentário inline, ordenado por severidade e marcado como Important, Nit ou Pre-existing. Dessa forma, um bug antigo não parece culpa do autor da mudança.
Cada apontamento precisa de resposta: você corrige ou fecha a thread com uma justificativa. Muitas vezes, um agente já aplica a correção durante a noite.
Revisão de segurança e checagens que bloqueiam
Além do code review com IA focado em bugs, a segurança tem uma revisão automatizada própria. Um PR não avança enquanto qualquer achado da revisão de bugs ou da revisão de segurança continuar aberto.
Se um commit posterior resolve o problema, o achado desaparece sozinho. Por outro lado, um falso positivo exige que alguém feche a thread com um motivo curto.
Além disso, o CI tradicional continua obrigatório: lint, checagem de tipos, testes em todas as plataformas e build. Um PR típico da CLI pode rodar dezenas de verificações antes de alguém olhar.
O template de PR também pergunta como a mudança foi testada e como desfazê-la. O Claude pode preencher essas respostas, mas quem pediu a mudança assina embaixo.
## Testing
<!-- Comandos executados e a saída obtida -->
## Risk
<!-- low | medium | high, com uma linha de justificativa -->
## How to revert
<!-- Flag para desligar ou commit para reverter -->
Aprovação humana proporcional ao risco
Uma correção na documentação e uma mudança no auto-updater carregam riscos diferentes. Portanto, recebem níveis diferentes de aprovação humana.
| Risco | Exemplos | Aprovações humanas |
|---|---|---|
| Baixo | Docs, textos, recursos internos, mudanças aditivas atrás de flag | Nenhuma, com revisão automática e segurança verdes |
| Médio | Mudanças comuns de produto e áreas sensíveis como cache e prompts de sistema | Uma pessoa |
| Alto | O código de maior risco e caminhos que sempre exigem duas pessoas | Duas pessoas |
Quem define o nível é a mudança, não o autor. Um classificador lê o diff e escolhe o nível de risco, enquanto um segundo classificador verifica se aquela mudança específica precisa de outra pessoa.
Só autores da lista de confiança do repositório têm acesso aos caminhos mais leves do code review com IA.
A aprovação de um agente nunca substitui a de uma pessoa. Em um PR escrito por agente, quem orientou o agente conta como um dos revisores obrigatórios.
Por fim, cada aprovação cobre um commit específico. Se chegam commits que o sistema não consegue validar, a aprovação precisa acontecer de novo.
Merge queue, feature flags e rollback rápido
A merge queue roda todas as verificações de novo contra a main com a mudança aplicada. Com isso, dois PRs que passam separadamente não conseguem quebrar a main quando se combinam.
Comportamentos novos costumam sair atrás de uma flag, primeiro para funcionários da Anthropic. Depois, as versões públicas vão para o canal latest, e o canal stable vem em seguida.
Mesmo assim, alguns erros escapam. Por isso, a última camada aposta em detecção e correção rápidas: flags desligam sem deploy e existe um plantão semanal.
As revisões de incidente perguntam qual camada do code review com IA deveria ter pegado o problema.
Como medir e melhorar o code review com IA
O próprio code review com IA passa por melhoria contínua. Cada incidente agora vira um caso de avaliação, ou seja, um eval.
O time reuniu PRs antigos que causaram incidentes, junto com seus reverts e correções. Em seguida, engenheiros que conhecem aquele código confirmaram cada bug e onde ele estava.
Esse conjunto roda diariamente contra o revisor. Assim, qualquer mudança no code review com IA, seja no prompt, nas ferramentas ou no modelo, recebe uma nota comparável.
Ruído e convergência no code review com IA
Um code review com IA acha mais bugs facilmente se aceitar muitos falsos alarmes. Por isso, o time mede o ruído observando o que as pessoas fazem com cada comentário.
Cada resposta entra em uma categoria: a pessoa corrigiu, disse que estava errado, disse que era intencional ou decidiu que não importava. Além disso, o time roda o revisor em PRs sabidamente limpos para contar alertas que levariam a mudanças prejudiciais.
O ruído custa ainda mais quando o autor é um agente. Uma pessoa ignora uma observação de estilo em segundos, mas um agente corrige, gera outro commit e dispara outra rodada de revisão.
Em um caso extremo, um PR da CLI passou por mais de cinquenta rodadas de revisão e correção durante a noite. Quando o time investigou com git blame, cerca de 59% dos apontamentos eram de código que já existia desde a primeira passada.
Para garantir que o code review com IA convirja, o time adotou quatro regras:
- Um limite de rodadas: depois de três, o revisor pede ao autor que reconsidere a abordagem.
- Revisão apenas do diff novo depois das primeiras passadas.
- Apontamento da classe do bug, para que o autor corrija todas as ocorrências.
- Nenhuma repetição de achados já publicados.
Os números mostram o efeito. Os PRs aprovados após uma rodada subiram de 65% para 78%, e os que precisavam de cinco ou mais rodadas caíram de 8,9% para 1,5%.
Onde as pessoas continuam decidindo
Tirar um engenheiro sênior de um trabalho profundo para pegar um erro rotineiro custa muito mais do que um code review com IA. Por isso, o papel humano mudou de ler cada diff para tomar as decisões em que máquinas vão mal.
A primeira delas é decidir se a mudança deveria existir. Direção, gosto e escopo continuam com pessoas, mesmo em times que consideram o gargalo de revisão resolvido.
Em seguida vêm o código de alto risco, como cobrança e workflows de CI, e a arquitetura que outras pessoas vão copiar.
Outra responsabilidade humana é ler as evidências: saída de testes, comandos executados, capturas de tela e achados do revisor. Se você não consegue dizer o que as verificações deixariam passar, peça uma revisão de verdade em vez de uma aprovação rápida.
Por fim, uma pessoa sempre responde pelo resultado. Não importa quem digitou o código, alguém é dono de cada mudança que chega ao usuário.
Contexto compartilhado sem ler cada diff
Se as máquinas fazem a maior parte da leitura, como alguém aprende o código? O time admite que não tem um processo formal para isso.
Ninguém mantém um modelo mental completo do Claude Code na cabeça, e o time acredita que ninguém precisa. Quando alguém quer entender uma parte do sistema, pede ao Claude um material explicativo exatamente sobre aquele trecho.
Esse material leva minutos para ficar pronto e reflete o código atual. Assim, o code review com IA libera tempo para aprender o que realmente importa.
O time resume a responsabilidade com a ideia de que quem faz o merge é dono da mudança. Isso funciona porque as mudanças são pequenas, tudo é reversível e regressões aparecem rápido.
Além disso, ser dono não significa levar a culpa. Quem fez a mudança tem mais contexto para corrigir, e as revisões de incidente olham para o sistema.
Como adotar code review com IA no seu time
A boa notícia é que a maioria das peças já existe hoje. Você pode começar pequeno e expandir conforme ganhar confiança, inclusive revisando seu fluxo de branches e pull requests com o curso de Fundamentos do Git e Azure DevOps.
Antes do pull request, dê ao agente verificações que ele consiga executar e liste essas verificações em um CLAUDE.md curto. Em seguida, rode /code-review e /security-review localmente e crie um REVIEW.md com os comentários que se repetem.
Em cada pull request, exija CI e inclua as seções Testing, Risk e How to revert no template. Depois, ative o code review com IA em um único repositório, ajuste o REVIEW.md por algumas semanas e só então amplie o uso.
Também vale exigir que toda thread do code review com IA esteja resolvida antes do merge, além de limitar o número de rodadas.
Na etapa de aprovação, documente os níveis de risco e defina cada nível pela mudança, não pelo autor. Comece rígido e afrouxe apenas com evidências.
Use CODEOWNERS e proteção de branch para que autenticação, cobrança, CI e instaladores sempre exijam uma pessoa. Nunca deixe a aprovação de um bot substituir a de um humano obrigatório.
Depois do merge, use merge queue, feature flags, uso interno primeiro, releases graduais e rollback em um passo. Por fim, transforme incidentes em um conjunto de evals e meça o tempo humano com reverts e incidentes como guarda-corpo.
Conclusão sobre o futuro do code review com IA
O caso do time do Claude Code mostra que o code review com IA não serve para eliminar pessoas do processo. Na verdade, ele serve para colocar a atenção humana exatamente onde ela faz diferença.
O produto público ainda trata a aprovação de um PR como decisão humana, já que ele publica achados e não aprovações. Contudo, os repositórios internos já permitem que donos decidam quais mudanças de baixo risco avançam apenas com verificações automáticas.
Quando uma revisão deixa algo passar, o time pergunta o que faltava na frente do modelo. Então, a correção vai para um CLAUDE.md, uma skill ou uma nova verificação.
Para quem trabalha com .NET, C# ou qualquer outra stack, a lição é a mesma. O code review com IA rende mais quando vem acompanhado de verificações executáveis, níveis de risco claros e rollback simples.
Para se aprofundar, leia o post original do time do Claude Code e teste as ideias em um repositório pequeno antes de mudar o processo inteiro.
FAQ
O code review com IA substitui a revisão humana?
Não. Ele assume a leitura rotineira, mas decisões de direção, arquitetura e código de alto risco continuam com pessoas.
A aprovação de um agente conta como aprovação humana?
Não no processo do time do Claude Code. O agente pode liberar mudanças de baixo risco, mas nunca ocupa uma vaga que exige uma pessoa.
Para que serve o arquivo REVIEW.md?
Ele diz ao revisor automático o que importa em cada parte do código. Os melhores são curtos, limitam observações de estilo e exigem arquivo e linha como evidência.
Como evitar que agente autor e agente revisor entrem em loop?
Limite o número de rodadas, revise apenas o diff novo depois das primeiras passadas e não repita achados já publicados.
Por onde começar a adotar esse modelo?
Comece com CI obrigatório, um CLAUDE.md curto e um revisor automático em um único repositório. Depois, amplie o uso conforme os dados de revert e incidentes.