Como a Anthropic usa o Claude Code como principal revisor de código
Aprofundamento CEVIU
Aprofundamento
A Anthropic descreve que o Claude escreve cerca de 90% do código do próprio Claude Code. No monorepo da empresa, as mudanças entregues por dia saíram de cerca de 2.500 em maio para mais de 30.000 em setembro. O Claude Code vive em repositório separado, mas sente a mesma pressão. Com esse volume, a revisão manual linha a linha deixa de ser viável.
A resposta foi tratar a pergunta "um humano leu o código?" como um proxy impreciso para "o que pode dar errado e qual verificação, automática ou humana, pega isso?". O fluxo tem camadas. Antes do PR, o Claude roda testes, builds ou comparações de tela, e um subagente revisa o diff com contexto novo. Todo PR recebe revisão de bugs e uma revisão de segurança própria, e o merge fica bloqueado enquanto houver achado aberto de qualquer uma delas. Os achados passam por votação entre agentes antes de serem postados, e cada um vem marcado como Important, Nit ou Pre-existing.
O risco define o nível de revisão humana. Um classificador lê a mudança e escolhe o tier. Um segundo avalia se aquela mudança específica precisa de mais uma pessoa. Caminhos sensíveis e arquivos de workflow de CI sempre exigem humano, e só autores da lista de confiança têm acesso aos caminhos mais leves. A aprovação de um agente nunca conta como a de uma pessoa, e cada aprovação vale para um commit específico. Quem pediu a mudança a um agente conta como um dos revisores exigidos.
Depois do merge, a fila reexecuta todas as checagens contra a main. O comportamento novo costuma sair atrás de feature flag para funcionários antes do canal público, e as flags desligam sem deploy. A empresa admite limites: ainda não há circuit breakers que apertem a aprovação quando as métricas pioram, e os engenheiros querem isso antes de levar mais código para merges sem humano. Um PR de CLI chegou a passar de cinquenta rodadas de revisão e correção numa noite, e cerca de 59% do que o revisor apontava era código presente desde a primeira passada.
O que mudou
Em 10 de março de 2026, o CEVIU noticiou o lançamento do Code Review, em preview de pesquisa, com um sistema multiagente que escaneia pull requests em busca de bugs de lógica ("Code Review, uma nova funcionalidade para o Claude Code"). Agora o post da própria equipe mostra o uso interno em escala. A fonte diz que a parcela de PRs internos com comentários substantivos subiu de 16% para 54% no preview, e que o produto público está disponível geral nos planos Team e Enterprise.
Em 19 de outubro de 2026, o CEVIU publicou "Anthropic Revoluciona Revisão de Código com IA no Claude", e em 27 de outubro de 2026 cobriu os números do mesmo post. De junho a setembro, os PRs mergeados mais que dobraram e a fatia revertida caiu mais de 40%.
Por que isso importa
Para quem cuida de AppSec, o ponto central é que a revisão de segurança entra como bloqueio de merge, não como sugestão. Isso é leitura editorial: o modelo só se sustenta com guardrails (reverts, incidentes, lista de autores confiáveis, caminhos sempre humanos). Quem pensa em copiar o desenho deve começar pelos controles de reversão e pela medição de ruído, não pela automação do veredito.
Linha do tempo
CEVIU noticia o Code Review do Claude Code, com agentes escaneando PRs, em preview de pesquisa.
CEVIU publica sobre a Anthropic automatizar grande parte da revisão de código com o Claude.
Anthropic detalha o Claude Code como principal revisor, com PRs mergeados mais que dobrados e reverts em queda.
Perguntas frequentes
O Claude Code aprova PRs sozinho na Anthropic?
Não no sentido de substituir pessoas em todos os casos. A aprovação de um agente nunca conta como a de um humano. Os donos dos repositórios podem permitir que mudanças de baixo risco sejam mergeadas com base apenas em checagens automáticas. O produto público posta achados, não aprovações.
Como a Anthropic decide quantos revisores humanos um PR precisa?
Um classificador lê a mudança e define o tier de risco. Um segundo classificador avalia se aquela mudança específica pede outra pessoa mesmo que o tier dispense. Caminhos sensíveis e arquivos de workflow de CI sempre exigem humano, e autores fora da lista de confiança precisam de um segundo aprovador.
Como a revisão de segurança entra no fluxo?
Todo PR passa por uma revisão de segurança automatizada além da de bugs. O PR não faz merge enquanto houver achado aberto de qualquer uma. Dá para resolver corrigindo ou fechando a thread com uma justificativa curta, o que serve para falso positivo. Há também a GitHub Action open source e o comando /security-review.
O que acontece se algo ruim passar pela revisão?
A última camada é detectar e reverter rápido. As feature flags desligam sem deploy, há plantão semanal e as revisões de incidente perguntam qual camada deveria ter pego o problema. Incidentes passados viram um conjunto de avaliação rodado diariamente contra o revisor.
Fontes
- claude.devfonte original
- Categoria
- CEVIU Segurança da Informação
- Publicado
- 27 de outubro de 2026
- Editoria
- CEVIU Segurança da Informação

