O Claude Code ganhou um serviço de revisão de pull requests baseado em múltiplos agentes. Cada agente procura uma classe diferente de problema, como falhas de lógica, vulnerabilidades, edge cases e regressões. Depois, uma etapa de verificação confronta os candidatos com o comportamento do código para filtrar falsos positivos. Os achados aparecem como comentários inline, classificados por severidade, sem aprovar nem bloquear o PR.
O desenho responde a um gargalo previsível. Agentes de código aumentam o volume de alterações mais rápido do que uma equipe aumenta sua capacidade de revisão. Colocar outra automação na fila parece inevitável. O risco é confundir mais análise com melhor decisão.
Revisores paralelos produzem valor quando observam o mesmo contrato. Sem regras locais, eles apenas multiplicam interpretações plausíveis.
Perspectivas diferentes precisam de uma base compartilhada
Separar segurança, lógica e regressão reduz a chance de um único revisor fixar atenção no primeiro problema encontrado. Essa diversidade ajuda em diffs extensos, onde uma mudança de autenticação pode afetar autorização, cache e eventos ao mesmo tempo.
Mas especialização cria sobreposição. Dois agentes podem descrever a mesma causa em níveis diferentes, ou apontar sintomas separados do mesmo defeito. A etapa de verificação e deduplicação é parte central do produto. Sem ela, o autor recebe uma lista longa que desloca o gargalo da descoberta para a triagem.
O repositório precisa oferecer contexto suficiente para decidir. O Code Review lê CLAUDE.md como instrução geral e aceita um REVIEW.md de alta prioridade para regras específicas da revisão. Esse arquivo pode definir o que merece comentário, qual severidade aplicar e quais convenções pertencem ao projeto.
O custo deve ser comparado com resultado aceito
O serviço cobra conforme o uso, e revisões em cada push custam mais do que execuções manuais. Comparar esse valor apenas com minutos de leitura humana cria uma conta incompleta. A pergunta operacional é quanto custa levar um PR a um estado aceito.
Uma revisão automática pode encontrar um defeito cedo e economizar investigação, rollback ou incidente. Também pode gerar comentários irrelevantes que consomem atenção de alguém experiente. O indicador útil combina custo, achados aceitos, tempo até merge e problemas que escaparam.
Repositórios com alto volume podem começar em modo manual. @claude review once executa uma análise sem assinar todos os pushes seguintes. Isso permite selecionar PRs com superfície de risco maior, medir utilidade e ajustar regras antes de automatizar a fila inteira.
O revisor não deve reabrir decisões já automatizadas
Lint, formatação, tipos e testes determinísticos pertencem ao CI. Gastar inferência para reencontrar o que uma ferramenta local identifica com precisão aumenta custo e ruído. A revisão por agente deve concentrar-se em relações que exigem contexto: uma permissão aplicada numa rota e esquecida em outra, um estado que viola uma regra de domínio, uma mudança correta isoladamente que quebra o fluxo completo.
O REVIEW.md pode retirar tópicos já cobertos e registrar falsos positivos recorrentes. Também deve apontar áreas de alto risco e invariantes. "Toda consulta deve filtrar tenant" é mais verificável do que "revise segurança". "Operações de cobrança exigem idempotência" ajuda o agente a ligar código local a uma consequência concreta.
Regras demais recriam outro problema. Um arquivo enorme compete com o diff e envelhece rápido. Poucas invariantes que já causaram defeitos oferecem mais sinal do que um manual genérico de boas práticas.
A revisão humana muda de lugar
Automação não elimina responsabilidade pelo merge. Ela desloca parte do trabalho da busca inicial para a avaliação dos achados. Uma pessoa ainda precisa confirmar se o cenário é possível, se a severidade está correta e se a correção proposta preserva outras restrições.
Isso exige uma interface de processo clara. Comentários da IA não deveriam ter o mesmo peso automático de um teste que falhou. A própria documentação afirma que o serviço não aprova nem bloqueia PRs. A equipe decide quais categorias viram gate e quais funcionam como segunda opinião.
Também convém preservar autoria. Se um agente escreveu o código e outro o revisou com modelos e contexto parecidos, os dois podem compartilhar pontos cegos. Testes independentes, observabilidade e revisão de domínio continuam necessários onde o erro custa mais.
Um piloto pode responder a pergunta certa
Escolha um conjunto pequeno de repositórios e registre quatro coisas por algumas semanas: custo por revisão, comentários aceitos, tempo gasto na triagem e defeitos encontrados depois do merge. Separe PRs humanos dos produzidos com forte assistência de agentes. O volume e o perfil de erro podem ser diferentes.
Depois, ajuste gatilhos. Revisão a cada push faz sentido quando mudanças são pouco frequentes ou quando o risco justifica cobertura contínua. Modo manual pode servir melhor a repositórios movimentados. PRs em draft talvez precisem de uma revisão única antes de ficar prontos, evitando pagar pela mesma estrutura incompleta várias vezes.
O Code Review amplia a capacidade de procurar problemas. A qualidade aparece quando a equipe limita o que procurar, verifica o que foi encontrado e mede se a fila termina melhor. Mais agentes sem um critério comum só produzem mais opiniões sobre o mesmo diff.
