A Anthropic afirma que o Claude Code agora escreve cerca de 90% do próprio código, e a equipe está mudando a forma de revisar esse trabalho. Em uma publicação, Addy Osmani, Morgan Westlee Lunt e Qing Wang descrevem o objetivo: integrar a maioria das solicitações de pull com no máximo uma pessoa envolvida — que pode ser quem escreveu a mudança — sem aumentar as reversões nem os incidentes.
A equipe diz que os revisores não precisam ter uma compreensão completa do Claude Code. Em vez disso, pedem ao Claude que explique a parte da base de código que precisam entender. Essa abordagem recebeu críticas em uma discussão no Hacker News: comentaristas questionaram se depender de explicações da IA deixa alguém em condições de depurar uma falha quando o entendimento do modelo está errado.
Como funcionam as etapas de revisão
Um classificador atribui a cada mudança um nível de risco com base na própria alteração, não em quem a fez. Mudanças de baixo risco incluem documentação, textos e adições protegidas por um sinalizador de recurso; elas podem ser aprovadas sem a aprovação de uma pessoa. Mudanças de risco médio, como trabalhos em cache, no atualizador automático e nos prompts do sistema, exigem uma pessoa. A aprovação de um agente não conta como aprovação humana, mas a pessoa que solicitou a mudança pode ser o revisor exigido.
O processo de revisão tem sua própria possibilidade de falha: os agentes agem com base em comentários que uma pessoa talvez ignorasse. A Anthropic descreve uma solicitação de pull que passou por mais de 50 rodadas de revisão e correções durante a noite, até que o autor a interrompeu. A equipe diz que limitou o número de rodadas depois de constatar que simplesmente fazer mais revisões piorava as coisas. Também descobriu que cerca de 59% do código sinalizado em rodadas posteriores já estava presente na primeira análise do revisor.
O que ainda não está claro
Outro exemplo, desta vez do repositório público do Claude Code, mostra os limites das explicações geradas. Em agosto, uma resposta gerada pelo Claude disse que problemas tinham sido encerrados por inatividade quando faltavam informações necessárias para reproduzir uma falha. No entanto, as regras do repositório permitem encerrar problemas após 14 dias marcados como obsoletos e mais 14 dias, com uma exceção para aqueles que tenham pelo menos 10 votos positivos. Um desenvolvedor contabilizou mais de 6.000 problemas identificados como tendo etapas para reproduzir a falha que ainda assim foram encerrados por inatividade. A sugestão da resposta de comentar para reabrir um problema também esbarrou em um fluxo de trabalho que bloqueia problemas encerrados após sete dias.
A Anthropic diz que ainda não tem mecanismos de segurança que elevem as exigências de aprovação caso suas métricas de revisão piorem. O produto Code Review está disponível para todos nos planos Team e Enterprise. A GitHub Action de revisão de segurança é de código aberto, mas o README alerta que ela não está protegida contra injeção de prompt e deve ser usada apenas para revisar solicitações de pull confiáveis.
Por que importa
Para equipes que consideram adotar a revisão de código conduzida por IA, o processo da Anthropic mostra que mudanças de baixo risco podem ser integradas sem aprovação humana, enquanto as de risco médio ainda exigem a participação de uma pessoa. A empresa afirma que não criou mecanismos de segurança para elevar as exigências de aprovação quando as métricas de revisão pioram; portanto, a publicação não esclarece como o processo reagiria se suas proteções começassem a falhar.
