Revisão do Anthropic Claude Code substitui a leitura humana rotineira enquanto a IA escreve 90% do código

A revisão do Anthropic Claude Code entrou em um território pouco familiar porque, segundo a empresa, o Claude agora escreve cerca de 90% do código do produto. De junho a setembro de 2026, os pull requests mesclados mais que dobraram. Ainda assim, a parcela que exigiu um revert teria caído mais de 40%.

Essa combinação revela a verdadeira história. A Anthropic não respondeu a uma explosão de código escrito por máquinas atribuindo aos humanos mais linhas para inspecionar. Ela transferiu a maior parte da leitura rotineira para outros agentes Claude e reservou a aprovação humana para mudanças de maior risco.

Não se trata simplesmente de uma versão mais rápida da revisão convencional. Isso muda o significado de revisão, quem a realiza e onde começa a responsabilidade. A Anthropic agora trata a atenção humana como um recurso escasso que deve seguir o risco, e não cada linha individual.

A abordagem também vem com uma limitação importante. Os resultados de destaque são medições da própria Anthropic, sem dados brutos publicados ou auditoria independente. Seu processo depende de ampla automação, infraestrutura interna, lançamentos graduais e acesso incomumente intenso aos seus próprios modelos.

A disputa resultante não é Claude contra programadores humanos. É cobertura automatizada contra inspeção humana universal. A Anthropic aposta que verificações em camadas, aprovações direcionadas e reversibilidade barata podem controlar mais riscos do que a leitura linha a linha na velocidade das máquinas.

O que mudou na revisão do Anthropic Claude Code

A Anthropic transformou a revisão de código de um único portão humano em um sistema contínuo de verificações automatizadas, revisores-agentes, aprovações direcionadas e rollback rápido.

A empresa descreveu o sistema em uma publicação de engenharia de 15 de outubro sobre a revisão do Claude Code. Os autores Addy Osmani, Morgan Westlee Lunt e Qing Wang enquadraram o problema em torno do volume de produção. Quando agentes geram mudanças mais rápido do que as pessoas conseguem lê-las, uma fila tradicional se torna um gargalo de entrega.

A Anthropic afirma que todo pull request recebe uma revisão do Claude antes de uma pessoa examiná-lo. O revisor lê a mudança proposta em relação ao repositório mais amplo e à intenção declarada no pull request. Para correções de bugs, ele tenta identificar a causa raiz, em vez de verificar apenas o patch visível.

Vários agentes então procuram possíveis defeitos em paralelo. Outro grupo vota em cada descoberta, e o sistema publica um problema apenas quando revisores suficientes concordam. A Anthropic afirma ter testado filtros que removem comentários limitados a estilo, diagnósticos ou limpeza opcional.

As descobertas restantes recebem rótulos de severidade. Desenvolvedores ou agentes precisam corrigir cada descoberta ou encerrar sua discussão com uma justificativa. Uma revisão de segurança automatizada separada também pode impedir uma mesclagem enquanto um problema permanece sem solução.

Essas revisões coexistem com salvaguardas convencionais. Os pull requests ainda enfrentam linting, verificações de tipo, builds e testes em plataformas compatíveis. Uma fila de mesclagem executa novamente as verificações em relação ao branch principal atual, reduzindo falhas causadas pela interação ruim entre mudanças que são válidas isoladamente.

A revisão começa antes de existir um pull request. O Claude executa testes, builds ou verificações visuais e exibe as evidências resultantes. Um subagente com contexto novo então inspeciona o diff, o que reduz a chance de o agente autor simplesmente repetir suas suposições originais.

As práticas de programação anteriores da Anthropic recomendavam separar os contextos de autoria e verificação. O novo fluxo de trabalho transforma essa recomendação em um sistema operacional para toda a equipe.

A aprovação humana depende do risco classificado da mudança. Trabalhos de baixo risco podem ser mesclados depois que as verificações automatizadas e de segurança forem aprovadas. Entre os exemplos estão documentação, alterações de texto, recursos internos e adições ocultas por feature flags.

O trabalho comum de produto geralmente exige uma pessoa. Áreas sensíveis, como cache, prompts de sistema e mecanismos de atualização, também recebem atenção humana. As mudanças de maior risco exigem duas pessoas, enquanto determinados caminhos protegidos sempre acionam revisão manual.

O classificador avalia a mudança, não se uma pessoa ou um agente a escreveu. Um segundo classificador ainda pode exigir envolvimento humano quando o nível original parecer permissivo demais. A aprovação de um agente nunca ocupa uma vaga reservada a uma pessoa.

Essa distinção importa. A Anthropic não eliminou a responsabilidade humana nem afirmou que a revisão por IA torna o software livre de erros. Ela separou a detecção rotineira de defeitos das decisões que envolvem arquitetura, direção de produto, sistemas sensíveis e risco aceitável.

A pessoa que instruiu o Claude continua responsável pelo resultado. Cada aprovação se aplica a um commit específico, portanto mudanças posteriores podem invalidá-la. No modelo da Anthropic, a delegação muda quem digita e lê o código, mas não quem é responsável pelo resultado.

Os números tornam a revisão exclusivamente humana insustentável

As métricas relatadas pela Anthropic sugerem que a produção de código já superou qualquer processo de revisão baseado na leitura humana universal.

A empresa afirma que os pull requests mesclados no repositório do Claude Code mais que dobraram entre junho e setembro de 2026. No mesmo período, a parcela que precisou de reverts caiu mais de 40%.

Esses números descrevem uma direção, não um desempenho completo. A Anthropic não divulgou a contagem absoluta de pull requests, a taxa original de reverts, a taxa final de reverts nem a variação estatística. Uma queda relativa de 40% pode partir de uma base alta ou baixa.

O número de 90% também exige uma formulação cuidadosa. A Anthropic afirma que o Claude escreve cerca de 90% do código do Claude Code. Isso não significa que o modelo escolha de forma independente as prioridades de produto, defina todos os requisitos ou assuma responsabilidade pela implantação.

Os engenheiros ainda direcionam as tarefas, avaliam as evidências, resolvem trade-offs de design e decidem se o trabalho deveria existir. A autoria por máquina mede a geração de código, enquanto a engenharia de software inclui muito mais do que produzir linhas.

Mesmo com essas ressalvas, a Anthropic enfrenta um problema real de escala. Seu monorepo separado teria crescido de cerca de 2.500 mudanças mescladas por dia em maio para mais de 30.000 em setembro. A empresa criou um sistema interno de controle de código-fonte chamado Scion para lidar com essa carga de trabalho.

O Claude Code usa um repositório separado, portanto o número de 30.000 mudanças não mede diretamente a equipe do produto. Ainda assim, o relato da Anthropic sobre seu redesenho do controle de código-fonte mostra a pressão mais ampla em torno de sua infraestrutura de desenvolvimento.

As histórias do Scion e do Claude Code apontam para o mesmo gargalo. Quando agentes de programação conseguem criar, testar e revisar mudanças continuamente, escrever código deixa de controlar a capacidade de produção. Filas de revisão, builds, permissões, sistemas de integração e controles de lançamento tornam-se os fatores limitantes.

A revisão de código tradicional pressupõe que um número administrável de mudanças venha de pessoas. Outra pessoa lê cada diff, solicita revisões e aprova a versão final. Esse modelo começa a falhar quando a produção cresce mais rápido que a capacidade dos revisores.

Adicionar revisores não resolve totalmente a incompatibilidade. Engenheiros experientes são escassos, e a revisão constante interrompe o trabalho de design, a depuração e as decisões de produto. Uma organização pode aumentar a equipe de revisão e ainda assim perder atenção compartilhada diante de um fluxo crescente de mudanças.

Por isso, a Anthropic mede mais do que o número de comentários produzidos. Ela acompanha aprovações humanas por pull request, comentários humanos, tempo de espera, reverts e incidentes. O objetivo declarado é reduzir o tempo de revisão humana sem transferir esse tempo para a recuperação em produção.

A empresa também relata que seu revisor comercial de IA elevou de 16% para 54% a parcela de pull requests internos que recebem comentários substanciais. A maioria das mudanças com mais de 1.000 linhas aparentemente atrai descobertas, enquanto a maioria das mudanças menores retorna limpa.

Esse resultado não estabelece precisão por si só. Mais comentários podem representar melhor detecção, mais ruído ou ambos. A Anthropic afirma avaliar a qualidade dos comentários observando se os desenvolvedores corrigem as descobertas, rejeitam-nas ou identificam o comportamento relatado como intencional.

O sinal maior é organizacional. A Anthropic não trata mais a leitura humana de cada linha alterada como a prova definidora de uma revisão. Ela mede se o sistema combinado detecta problemas, direciona bem a atenção e limita danos em produção.

Essa mudança pressiona todas as organizações de engenharia que implantam agentes de programação. Se a produção dos agentes cresce enquanto a política de revisão permanece fixa, as filas se expandem e os ganhos esperados de produtividade desaparecem. As equipes precisam restringir a geração ou redesenhar a forma como a validam.

A cobertura automatizada desafia a inspeção humana universal

A disputa central ocorre entre ampla cobertura por máquinas e a crença de que toda mudança significativa merece leitura humana direta.

A inspeção humana universal oferece uma promessa intuitiva. Um engenheiro qualificado entende o código, vê a mudança e aceita responsabilidade antes que ela seja lançada. Essa prática pode disseminar conhecimento enquanto detecta suposições que os testes automatizados não percebem.

No entanto, a promessa enfraquece quando a revisão se torna apressada. Uma pessoa diante de uma grande fila pode apenas examinar superficialmente em vez de raciocinar, aprovar código de aparência familiar ou concentrar-se no estilo em vez do comportamento. Uma assinatura humana não garante compreensão.

A alternativa da Anthropic usa várias camadas especializadas. Um agente cria a mudança, outro revisa com contexto novo, vários agentes procuram bugs e agentes separados avaliam cada descoberta. Revisão de segurança, integração contínua, verificações de mesclagem, lançamento gradual e rollback cobrem diferentes modos de falha.

Isso se assemelha à defesa em profundidade. Nenhuma camada individual precisa ter cobertura perfeita, porque camadas posteriores podem detectar o que as anteriores deixam passar. A classificação de risco então direciona o julgamento humano escasso para mudanças com maior impacto potencial.

O mecanismo também oferece à Anthropic uma cobertura de revisão mais ampla. Máquinas podem inspecionar todo pull request sem esperar pela agenda de um colega. Elas podem examinar o contexto do repositório, aplicar convenções documentadas e repetir as mesmas verificações em milhares de mudanças.

As instruções armazenadas em CLAUDE.md descrevem o projeto, suas convenções e seus limites. Um REVIEW.md separado informa ao revisor como é uma falha em determinado repositório. Os responsáveis pelo código podem identificar caminhos sensíveis e excluir os irrelevantes.

Quando o revisor sinaliza repetidamente um erro, a equipe pode levar a lição para etapas anteriores. Ela pode adicionar uma regra de lint, melhorar um arquivo de instruções, modificar uma skill ou criar uma nova verificação automatizada. O feedback da revisão então se torna infraestrutura reutilizável.

Falhas passadas tornam-se casos de avaliação. A Anthropic afirma ter reunido pull requests associados a incidentes, reverts e correções posteriores. Os engenheiros verificaram os bugs subjacentes, e o revisor agora é executado diariamente sobre esse conjunto.

Isso representa um afastamento significativo da revisão como uma reunião entre duas pessoas. O sistema tenta preservar lições em verificações executáveis, em vez de depender da memória individual. Cada incidente pode ampliar a cobertura futura de detecção da organização.

Ainda assim, a revisão humana continua a lidar com questões que não podem ser reduzidas à correção local. Os engenheiros decidem se um recurso deveria existir, se uma abstração estabelece um precedente prejudicial e se as evidências justificam a implantação.

Eles também inspecionam áreas sensíveis, incluindo faturamento, mecanismos de atualização, integração contínua e fluxos de lançamento. Essas alterações podem ter um amplo raio de impacto mesmo quando seu código parece estar localmente correto.

Portanto, o processo não declara que as máquinas são melhores revisoras em todas as dimensões. Ele atribui às máquinas o trabalho de leitura que podem realizar repetidamente, enquanto atribui às pessoas as decisões que envolvem propósito, arquitetura, incerteza e responsabilidade.

Essa divisão também muda a habilidade de engenharia. Engenheiros precisam especificar a intenção, identificar restrições, projetar verificações, interpretar evidências e reconhecer quando um agente otimizou o objetivo errado. Ler código continua sendo útil, mas já não é o único caminho para a compreensão.

A equipe Scion da Anthropic ofereceu um exemplo relacionado. Engenheiros relataram que Claude às vezes buscava projetos ineficientes ou excessivamente defensivos que se adequavam a padrões locais. Humanos precisavam rejeitar essas direções porque compreendiam as compensações no nível do sistema.

A expressão “human in the loop” pode obscurecer esse papel. Uma pessoa que apenas aprova a saída da máquina é uma salvaguarda fraca. Uma pessoa que define limites, escolhe evidências e sabe quando interromper a automação oferece controle significativo.

Para outras organizações, a lição não é remover revisores. É distinguir a inspeção mecânica do julgamento. A cobertura automatizada se torna valiosa quando as pessoas mantêm autoridade sobre decisões de alta consequência e evidências pouco claras.

Como as Revisões do Claude Code Evitam Loops Infinitos de Agentes

A Anthropic descobriu que autores de IA e revisores de IA podem criar trabalho ilimitado, a menos que o processo de revisão seja explicitamente projetado para convergir.

Mais revisão não é automaticamente melhor. A Anthropic descreve um pull request do Claude Code que passou por mais de 50 rodadas de revisão e correção durante a noite. O autor acabou interrompendo o loop.

O revisor não estava descobrindo um novo defeito crítico a cada passagem. A Anthropic usou o histórico de versões para examinar as descobertas repetidas e constatou que cerca de 59% diziam respeito a código presente na primeira revisão.

O agente continuava localizando problemas antigos adicionais em vez de avaliar apenas a nova correção. Cada comentário desencadeava outra correção, commit e revisão. O sistema permanecia ativo sem avançar de forma eficiente rumo a um estado final aceitável.

Essa falha ilustra um risco específico da revisão de código por IA. Uma pessoa pode descartar uma sugestão de baixo valor em segundos. Um agente de autoria tende a agir sobre ela, produzindo outro diff que dá ao agente revisor mais material.

A Anthropic respondeu com controles de convergência. Após três rodadas, o revisor pede ao autor que reconsidere a abordagem. As passagens posteriores se concentram no novo diff, em vez de pesquisar repetidamente toda a alteração.

O revisor também relata de uma vez toda uma classe de defeitos relacionados. Isso permite que o autor corrija cada ocorrência em vez de receber comentários semelhantes em rodadas consecutivas. Descobertas já publicadas não devem aparecer novamente.

A Anthropic afirma que essas mudanças melhoraram seu ciclo interno de revisão. A parcela de pull requests aprovados após uma rodada de revisão e correção teria subido de 65% para 78%.

Os pull requests que exigiam cinco ou mais rodadas teriam caído de 8,9% para 1,5%. A média de revisões antes da aprovação caiu de 2,08 para 1,32. Essas métricas continuam sendo relatadas pela própria empresa, mas abordam um problema operacional que muitos fluxos de trabalho com agentes ignoram.

A convergência importa porque o trabalho automatizado não é gratuito apenas por não envolver salário. Cada rodada adicional consome capacidade de modelo, atrasa a alteração, cria mais código e aumenta o material que verificações posteriores precisam inspecionar.

O mesmo problema surge quando revisores reagem de forma excessiva a ameaças hipotéticas. A Anthropic afirma que a revisão adversarial pode se tornar míope, incentivando validação ou complexidade excessivas. Um sistema otimizado para descobrir falhas possíveis pode criar novos custos de manutenção.

Profundidade baseada em risco oferece um controle. O serviço Code Review da Anthropic, disponível de forma geral, oferece diferentes níveis de revisão para repositórios rotineiros e críticos. A empresa afirma que a maioria das revisões agora termina em seis a dez minutos.

No entanto, um revisor mais rápido não resolve a questão subjacente de governança. As equipes ainda precisam decidir quais descobertas importam, quais caminhos merecem inspeção mais profunda e quantos ciclos são aceitáveis.

As instruções de revisão também podem se tornar uma camada de política oculta. Se CLAUDE.md, REVIEW.md ou prompts de classificação contiverem pressupostos fracos, os agentes podem aplicar esses pressupostos de forma consistente em todo o repositório.

A consistência só ajuda quando a regra está correta. As equipes precisam de responsabilidade definida, controle de versão, casos de avaliação e revisão das instruções que orientam seus revisores. Caso contrário, a automação pode escalar uma política equivocada mais rápido do que os humanos percebem.

É nesse ponto que o contexto compartilhado de engenharia se torna importante. Organizações que adotam agentes precisam de registros duradouros de decisões de arquitetura, lições de incidentes e abordagens rejeitadas. Uma base de conhecimento de engenharia pesquisável pode ajudar a preservar esse contexto além de uma única discussão de revisão.

O processo da Anthropic funciona porque trata o revisor como um sistema que precisa de medição. Ele acompanha precisão, ruído, rodadas, incidentes e respostas dos desenvolvedores. Instalar um revisor de IA sem esses ciclos de feedback copiaria a ferramenta visível, mas deixaria de fora o modelo operacional.

O Que os Resultados da Anthropic Ainda Não Comprovam

As alegações mais fortes continuam sendo autorrelatadas, e a Anthropic não demonstrou que seus resultados se transfiram para equipes com infraestrutura, orçamentos ou tolerância a falhas diferentes.

A primeira incerteza diz respeito à medição. A Anthropic relatou que os pull requests mesclados mais que dobraram e que a proporção de reversões caiu mais de 40%. Ela não divulgou o conjunto de dados subjacente, taxas absolutas nem a distribuição da gravidade dos incidentes.

Uma queda na proporção de reversões pode ser encorajadora e ainda assim ocultar resultados importantes. Equipes podem corrigir adiante em vez de reverter, desativar uma feature flag ou tolerar uma regressão que nunca recebe esse rótulo. Reversões são úteis, mas incompletas.

As taxas de incidentes oferecem outra proteção, mas a publicação pública não fornece uma série detalhada de incidentes. Sem dados de gravidade e exposição, observadores externos não conseguem determinar se o processo reduziu o risco ou mudou a forma como as falhas foram tratadas.

O número de 90% de autoria carrega ambiguidade semelhante. Ele não especifica se a medição conta linhas geradas, linhas aceitas, commits ou outra unidade. Também não revela quanto prompting, edição e iteração humanos precederam o código final.

O ambiente da Anthropic é incomumente favorável a esse método. A empresa controla os modelos, pode gastar recursos computacionais substanciais em revisores paralelos e desenvolve infraestrutura interna em torno de cargas de trabalho geradas por agentes.

Seus funcionários também usam Claude Code internamente antes dos lançamentos públicos. Novos recursos podem passar pela implantação interna, por um canal mais recente e depois por um canal estável. Feature flags permitem que a equipe desative comportamentos sem uma implantação completa.

Equipes que operam sistemas médicos, financeiros, industriais ou críticos para a segurança podem enfrentar requisitos diferentes. Uma reversão rápida não pode desfazer todas as consequências. Uma migração de dados defeituosa, alteração de autorização ou ação externa pode produzir danos irreversíveis.

A Anthropic reconhece que mesclagens ruins ainda dependem de autores, engenheiros de plantão, telemetria e painéis para detecção. Ela ainda não possui disjuntores automáticos que aumentem os requisitos de aprovação quando reversões ou incidentes aumentam.

Essa lacuna importa porque a classificação de risco pode se tornar desatualizada. Uma alteração classificada como de baixo risco pode interagir com dependências ocultas. Uma série de alterações individualmente seguras também pode produzir um estado combinado perigoso.

A segurança introduz outra preocupação. A Anthropic usa revisão de segurança automatizada, mas seus próprios materiais de risco mostram por que a supervisão humana continua necessária. Sua avaliação de sabotagem descreve o monitoramento de modelos como um controle em evolução, e não como uma garantia completa.

A reação da comunidade levantou questões mais amplas sobre custo e compreensão. Alguns desenvolvedores argumentam que a Anthropic pode sustentar padrões de revisão que seriam antieconômicos em outros contextos. Outros temem que menos pessoas lendo diffs enfraqueça o conhecimento coletivo da base de código.

A Anthropic declara abertamente que ninguém na equipe do Claude Code mantém um modelo mental completo do produto. Em vez disso, os engenheiros pedem ao Claude que explique o subsistema relevante quando precisam dele.

Essa abordagem pode manter as explicações atualizadas, mas cria uma dependência. Se a explicação gerada deixar de fora uma interação, o engenheiro poderá tomar uma decisão com base em um mapa incompleto. A mesma família de modelos também pode repetir pressupostos incorporados ao código que revisa.

A revisão entre modelos poderia fornecer diversidade adicional, mas não melhora automaticamente a precisão. Sistemas diferentes podem compartilhar padrões de treinamento ou falhar por motivos não relacionados. A propriedade importante é a evidência independente, e não apenas um nome de modelo diferente.

Nenhuma dessas questões invalida os resultados relatados pela Anthropic. Elas limitam o que esses resultados estabelecem. A empresa mostrou um processo interno detalhado com métricas direcionais encorajadoras, não uma substituição universal para a revisão humana de código.

Três Sinais Testarão se o Modelo se Sustenta

O próximo teste é se a Anthropic conseguirá preservar a qualidade à medida que mesclagens sem humanos se expandem, produtos de revisão chegam a outras empresas e concorrentes adotam controles diferentes.

O primeiro sinal é a própria política de aprovação da Anthropic. Seu processo atual permite que alterações selecionadas de baixo risco sejam mescladas sem um revisor humano separado após a aprovação das verificações automatizadas.

Observe se esse limite se expande para mais código de produto. Se a Anthropic adicionar os disjuntores que seus engenheiros desejam, a escalada automática poderá tornar uma implantação mais ampla mais crível. O aumento de incidentes ou um retorno a aprovações mais rigorosas enfraqueceria o argumento.

O segundo sinal é a evidência de organizações externas que usam revisão automatizada. A Anthropic lançou o Code Review para clientes Team e Enterprise, criando um teste mais amplo em repositórios e culturas de engenharia desconhecidos.

As métricas úteis não serão o número de comentários ou pull requests revisados. As equipes devem relatar descobertas aceitas, defeitos que escaparam, falsos positivos, latência de revisão, esforço humano e incidentes de produção.

Resultados comparáveis fora da Anthropic fortaleceriam a alegação de que a revisão de IA em camadas pode escalar. Ruído elevado, uso crescente de modelos ou taxas de incidentes inalteradas sugeririam que o sucesso da Anthropic depende de seu ambiente interno.

O terceiro sinal é a resposta competitiva. OpenAI, GitHub, Google, Cursor e outros provedores de agentes de programação enfrentam o mesmo desequilíbrio entre código gerado e capacidade de revisão.

Suas escolhas revelarão se a revisão baseada em risco se torna um padrão compartilhado. Sistemas concorrentes podem favorecer revisão entre modelos, sandboxing mais forte, verificação formal, avaliação específica por repositório ou aprovação humana mais persistente.

Os desenvolvedores devem resistir a reduzir esse debate à questão de saber se a IA consegue encontrar bugs. A pergunta prática é se um sistema completo de revisão consegue alocar atenção, preservar a responsabilidade e se recuperar com segurança quando todas as camadas deixam algo passar.

Para líderes de engenharia, a ação imediata é medir. Estabeleça uma linha de base para tempo de revisão, defeitos que escaparam, falsos positivos, taxas de reversão e gravidade de incidentes antes de alterar a política de aprovação. Sem essa linha de base, mesclagens mais rápidas podem parecer uma melhoria enquanto deslocam custos para outro lugar.

As equipes também devem separar mudanças reversíveis das irreversíveis. Documentação, ajustes sinalizados de interface e ferramentas internas não merecem o mesmo processo que autenticação, cobrança, migrações ou infraestrutura de lançamento.

A revisão do Claude Code da Anthropic oferece uma resposta concreta para um problema que muitas equipes enfrentarão em breve. Ela trata a revisão como um sistema de controle em camadas, e não como prova de que uma pessoa leu cada linha.

Os números divulgados pela empresa fazem essa resposta valer o teste, não uma cópia cega. Se seus agentes dobrarem a produção de código amanhã, quais evidências permitiriam que seus revisores deixassem de ler tudo com segurança hoje?