Como o time do Claude Code faz code review: a IA revisa o tempo todo antes de chamar um humano

Fala aí, beleza? O time do Claude Code abriu como faz code review lá dentro da Anthropic, e a ideia central é simples: a IA revisa o código o tempo todo, e o humano só entra quando o risco pede

O texto How the Claude Code team does code review saiu no blog claude.dev, da Anthropic, na categoria Engineering, e é assinado por Addy Osmani, Morgan Westlee Lunt e Qing Wang (os nomes estão na própria página do post)

A tese deles: perguntar "um humano leu o código?" é um substituto impreciso

A pergunta útil seria outra: o que pode dar errado nesta mudança, e qual checagem, automática ou humana, é a certa para pegar o problema?

Na prática, a revisão virou contínua, como um corretor ortográfico, e a maioria das mudanças passa pelo menos uma vez por revisão e correção do Claude antes de alguém do time ser chamado

Se liga: isso é relato de processo, não lançamento de produto

O texto ganhou alcance quando o Simon Willison destacou um trecho no blog dele em 16 de outubro de 2026

O que mudou: a revisão deixou de ser o portão no fim do PR

A revisão saiu do fim do caminho e passou a acompanhar a escrita do código, enquanto ela acontece

Os autores descrevem o modelo antigo assim: escrever o código, abrir o PR e esperar o colega revisar

Ou seja, um portão no final, e tudo travado até alguém ter tempo de olhar 😛

Hoje, segundo eles, a revisão roda continuamente, "mais como um corretor ortográfico enquanto você escreve"

E o trecho que mais importa, traduzido: "A maioria das mudanças foi revisada e corrigida pelo Claude pelo menos uma vez antes de um humano ser chamado para olhar"

O ganho que eles declaram é duplo: o Claude pega a maior parte dos erros rotineiros, e a atenção do time fica para questões de nível mais alto e um escrutínio mais profundo

Vale frisar: isso é afirmação dos autores sobre o próprio processo, não algo medido por aqui

Como funciona o processo em camadas do time do Claude Code

O processo descrito empilha seis camadas antes do merge, com rollback por baixo de tudo:

1. verificação do próprio trabalho antes de abrir o PR (testes, build, um subagente revisando o diff)
2. revisão por IA em todo PR
3. revisão de segurança, que pode bloquear a mudança
4. checagens automáticas que bloqueiam (lint, type check, testes, build)
5. aprovação humana conforme o risco
6. merge queue, feature flags e release gradual

E por baixo de todas essas camadas, ainda tem uma etapa de detecção e rollback rápidos, pra reverter rápido se algo passar torto

A parte mais interessante é a quinta camada, a aprovação humana baseada em risco

Um classificador lê a mudança e define o nível de risco: baixo não pede aprovação de ninguém (depois que a revisão automática e a checagem de segurança passam), médio pede uma pessoa, e alto pede duas

Tem ainda um segundo classificador, que avalia se a mudança precisa de outra pessoa mesmo quando o primeiro nível diz que não

E é aqui que a pergunta central do texto vira regra operacional, né?

Em vez de "todo PR precisa de um humano", fica "esta mudança, com este risco, precisa desta checagem"

Os exemplos que o post dá ajudam a entender a régua: risco baixo é documentação, textos, recursos só internos e mudanças aditivas atrás de flag; risco médio é mudança comum de produto e áreas sensíveis como cache, auto-updater ou system prompts; risco alto é o código mais sensível e um pequeno conjunto de caminhos que sempre exige duas pessoas

Só quem está na lista de autores de confiança do repositório pega os caminhos mais leves, e a aprovação de um agente nunca conta como aprovação de uma pessoa

Os números que o texto apresenta (e o que eles não provam)

Segundo os autores, entre junho e setembro os PRs mesclados no código do Claude Code mais que dobraram

No mesmo período, a fatia de mudanças que precisou ser revertida caiu mais de 40%

É um resultado bonito, mas tome cuidado com a leitura

São números da própria Anthropic, de um time específico, sobre o próprio produto

Não dá pra isolar quanto disso vem da revisão contínua e quanto vem de outras coisas que mudaram no período

E não há garantia nenhuma de que o mesmo aconteça no seu projeto

O que é o Code Review, o recurso comercial do Claude Code?

Aqui vale separar duas coisas: o relato de processo do time e o recurso comercial Code Review, que a Anthropic vende

E a ligação entre os dois é explícita: o próprio post do time chama o Code Review de "the public version" da revisão por IA que eles usam internamente em todo PR

O Code Review, segundo o anúncio da Anthropic, funciona assim: quando um PR é aberto, ele dispara uma equipe de agentes que procuram bugs em paralelo

Depois, verificam os achados para filtrar falsos positivos e ordenam os bugs por severidade

O resultado aparece no PR como um comentário geral e comentários nas linhas

No anúncio original, a Anthropic disse que antes 16% dos PRs internos recebiam comentários substantivos de revisão, e que depois passaram a ser 54%

Esse mesmo salto de 16% para 54% também aparece citado no post do time, não só no anúncio original do produto

Agora o estado atual: o Code Review saiu do research preview e está em disponibilidade geral (GA) para organizações dos planos Claude Team e Enterprise desde 15 de outubro de 2026

No anúncio de GA, a Anthropic diz que a maioria das revisões ficou cerca de 3x mais rápida em relação ao preview, de uns 20 minutos para 6 a 10 minutos

Pra habilitar, um Owner da organização Claude ativa o Code Review nas configurações do Claude Code, instala o GitHub App e escolhe os repositórios

A partir daí, cada repositório tem sua própria configuração de quando a revisão dispara: uma vez ao abrir o PR, a cada push, ou só sob pedido, quando alguém com permissão de escrita comenta "@claude review"

Segundo a documentação, a revisão nunca aprova nem bloqueia o PR, o merge continua sendo decisão do time: os achados chegam como comentários nas linhas, ordenados por severidade, com um resumo geral e um check run chamado "Claude Code Review"

Tem também o comando /code-review, que roda uma versão mais leve localmente, numa sessão do Claude Code, e esse funciona em qualquer plano

Os detalhes estão na documentação oficial do Code Review

O que muda para quem desenvolve com agentes de IA

A mudança principal é de pergunta: sai "alguém leu?" e entra "o que pode quebrar aqui, e qual checagem pega isso?"

Se tu usa agente pra programar, já sabe que o volume de código sobe rápido, e revisar tudo linha a linha vira gargalo

Se ainda está entendendo o papel da ferramenta, vale ver o que o Claude Code faz e o que continua sendo trabalho seu

Uma ação bem prática:

1. Liste os tipos de mudança que aparecem no seu repositório (ajuste de texto, refatoração, nova rota, migração de banco, autenticação e por aí vai)
2. Pra cada tipo, anote qual checagem pega o erro mais provável: teste no CI, revisão automática, revisão de segurança ou uma pessoa
3. Marque quais tipos são de risco alto o bastante pra pedir um ou dois humanos

O erro comum aqui é tratar regra escrita como checagem

Instrução no CLAUDE.md ajuda, mas não garante nada sozinha, e se tu já viu o Claude Code ignorando o CLAUDE.md, sabe do que estou falando haha

Se a sua organização está em Team ou Enterprise e usa GitHub, dá pra avaliar o Code Review como a camada de revisão por IA

Se não está, a lógica do processo continua valendo com as ferramentas que você já tem: CI, testes e o próprio agente revisando antes de abrir o PR

Limitações e cuidados ao copiar o modelo

Primeiro: é o relato de um time da Anthropic que usa agentes intensamente sobre o próprio produto

O contexto deles não é o da maioria dos times

Segundo: os números são autodeclarados

Terceiro, e esse é o ponto que mais gente vai ler errado: o texto não elimina o humano

Ele reposiciona a atenção da pessoa conforme o risco, e ainda existem mudanças que pedem dois revisores

Por fim, o Code Review como produto está restrito a Team e Enterprise, exige repositórios no GitHub, e não está disponível para organizações com Zero Data Retention, configuração HIPAA ou chaves de criptografia gerenciadas pelo cliente (CMEK)

Revisão por agentes na prática: o que aparece no vídeo do GStack

Antes de tudo: o GStack é outra ferramenta, não tem relação com o Code Review da Anthropic

E o que eu vi nele não comprova o estado atual de nenhum produto, beleza?

No meu vídeo sobre o GStack, eu instalei o framework dentro do Claude Code e testei o fluxo completo criando um projeto fictício, uma rede social chamada Pensaí

O que me chamou atenção é que, antes de qualquer linha de código, ele passa por fases de pensamento e planejamento, pedindo aprovação a cada etapa (produto, público, abordagem)

Tem até um wireframe em HTML pra aprovar antes de programar, o que achei um ponto MUITO positivo

Segundo o que o autor comentou no vídeo, a ferramenta deu algo como nota 7 ao escopo do produto, numa escala até 10, mas ele mesmo disse "se não me engano" na hora, então não é uma leitura 100% confirmada na tela

No fim do planejamento, ele oferece revisões opcionais: de arquitetura, uma "revisão de CEO" pra desafiar o escopo, ou de design

Dá até pra pular direto pra execução, se achar que não precisa

Escolhi mostrar a revisão de arquitetura só pra ilustrar como funciona

Outra coisa massa: ele separa "review" (revisão de código pra achar bugs) de "teste", mesmo com o objetivo parecido de encontrar problemas

Tem também um comando que chama outra IA, como o Codex, pra dar uma segunda opinião, mas não usei porque não tinha essa ferramenta instalada na máquina

E uma confissão: aprovei as etapas do planejamento rápido demais, sem ler tudo com atenção xD

Se for usar de verdade, leia o documento gerado antes de aprovar

A ideia do GStack, pra mim, é dar começo, meio e fim ao desenvolvimento com IA, evitando aquele vibe coding sem revisão em que o bug só aparece depois do deploy

Se quiser conhecer mais do canal, aqui vai um conteúdo complementar sobre a mega atualização v4 do Impeccable, focada em design (não é sobre code review nem sobre o post da Anthropic):

Próximo passo: comece pelas mudanças que mais quebram

Leia o post original no claude.dev com calma, é curto e vale o tempo 🙂

Depois, pega o repositório onde você mais sofre com bug e mapeia qual checagem pega qual tipo de erro, começando pelas mudanças que mais quebram

Se a sua organização está em Team ou Enterprise e usa GitHub, passe pela documentação do Code Review antes de pedir pro admin habilitar

Até o próximo post!

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.