A equipe do Claude Code da Anthropic diz que o número de pull requests integrados mais que dobrou de junho a setembro, enquanto a proporção revertida caiu mais de 40%. Seu relato de 15 de outubro descreve a aprovação humana ajustada ao risco em repositórios separados do monorepositório principal da Anthropic. São métricas da própria equipe; elas não estabelecem o que causou a melhora.

Líderes de engenharia podem usar o serviço público Code Review para reunir constatações enquanto definem seus próprios requisitos de integração. O serviço relata possíveis defeitos; a equipe decide quais verificações e pessoas podem permitir que uma mudança seja lançada.

A grande mudança

  • O que mudou: A revisão por IA pode examinar uma mudança proposta e o código ao redor, verificar possíveis bugs e colocar as constatações que persistem junto às linhas relevantes. Isso dá às equipes de engenharia outra fonte de evidências de revisão à medida que agentes produzem código.
  • Por que importa: O revisor público lê o código sem executá-lo e não concede permissão de lançamento. Testes e regras de aprovação do repositório são decisões separadas que um líder de engenharia precisa configurar.
  • O que observar: A frequência das revisões afeta os gastos, e um limite de orçamento pode fazer com que revisões sejam puladas. As equipes que adotam o serviço precisam distinguir uma revisão concluída sem problemas detectados de uma revisão que nunca foi executada.

O processo interno define a aprovação pelo risco

A sequência da equipe do Claude Code combina testes, revisões por agentes, revisão de segurança e integração contínua. Uma fila de integração vem antes do lançamento gradual; sinalizadores de funcionalidades e reversão cuidam da recuperação.

Sua política de aprovação para autores confiáveis é:

Risco da mudança

Aprovações humanas exigidas após as verificações automatizadas

Baixo, incluindo textos e funcionalidades apenas para uso interno

Nenhuma

Médio, incluindo mudanças comuns no produto

Uma

Alto, além de caminhos designados para dois revisores

Duas

A pessoa que orienta um agente conta para o requisito; a aprovação de um agente não. As aprovações valem para um commit específico. Depois de três rodadas de revisão, o revisor pede ao autor que reconsidere a abordagem. As passagens seguintes se limitam ao novo diff. Reversões e incidentes servem de indicadores de segurança, mas ainda não há controle automático para tornar a aprovação mais rigorosa quando eles pioram.

O que o revisor público faz

O manual atual do Code Review descreve vários agentes lendo o diff e o código próximo na infraestrutura da Anthropic. Uma etapa de verificação checa as constatações propostas; depois o serviço elimina duplicatas, ordena por gravidade e publica comentários e uma execução de verificação. Ele lê o código sem compilá-lo nem executá-lo. Sua execução de verificação não reprova um pull request, e o serviço nunca aprova nem bloqueia um.

O acesso exige uma organização Team ou Enterprise e repositórios GitHub. O manual exclui organizações que usam Zero Data Retention, a configuração HIPAA ou chaves de criptografia gerenciadas pelo cliente. Essas restrições importam antes de uma equipe enviar código proprietário para revisão. O BIG CHANGE examinou os documentos; não implantou nem testou esse fluxo de trabalho.

As instruções de configuração exigem um usuário com a função Owner na organização Claude, um proprietário da organização GitHub para instalar e vincular o aplicativo e acesso de escrita para adicionar repositórios. O aplicativo solicita permissões mais amplas do que as usadas pela própria revisão. Administradores escolhem revisões Quick, Standard ou Deep e se elas ocorrem uma vez por pull request, após cada push ou sob demanda. A revisão automática pula rascunhos e forks; alguém com acesso de escrita pode solicitar uma revisão manual.

Instruções e aplicação das regras têm funções diferentes

O manual de personalização distingue CLAUDE.md, que fornece o contexto do projeto, de REVIEW.md, que define prioridades e exclusões específicas da revisão. O serviço lê as instruções de revisão na branch base ou padrão, nunca na própria mudança proposta. O comando local /code-review lê CLAUDE.md, mas não REVIEW.md. Portanto, orientações compartilhadas pelas duas ferramentas devem ficar em CLAUDE.md.

As regras do repositório garantem sua aplicação. A documentação de proteção de branches do GitHub descreve verificações de status obrigatórias, aprovações dos proprietários do código e resolução das conversas de revisão. Também permite descartar aprovações quando o diff revisado muda. Normalmente, administradores podem contornar as proteções, a menos que a regra também se aplique a eles. Por isso, um líder de engenharia precisa examinar a regra efetiva e as permissões para contorná-la junto com os comentários do revisor.

Conforme documentado, o revisor público não fornece um teste de aplicação aprovado nem uma aprovação humana obrigatória. Manter esses registros separados permite conferir quais evidências sustentaram uma integração.

Meça as revisões que foram executadas

A cobrança do Code Review usa tokens por meio de créditos de uso, separadamente do uso incluído no plano. A Anthropic não publica um preço fixo por revisão. O custo varia conforme a profundidade da revisão, a mudança e o código ao redor, além das constatações que precisam de verificação. Revisar cada push acrescenta revisões ao mesmo pull request.

O manual de custos recomenda um piloto limitado, um teto mensal de gastos e a medição do custo médio do repositório. Revisões podem ser puladas quando o limite do serviço, o limite da organização ou o saldo de créditos se esgota, inclusive quando o restante fica abaixo do custo esperado de uma revisão. Uma revisão pulada gera um comentário que explica o motivo.

Durante um piloto, confirme se o serviço de revisão previsto foi executado sobre a mudança prevista, se os testes e as aprovações humanas obrigatórios continuam valendo e se a equipe consegue reverter um lançamento problemático. Demonstrar um benefício em outro contexto exige os registros de revisão, reversões e incidentes da própria equipe que adota o serviço. A cobertura anterior do BIG CHANGE sobre produção de código e trabalho concluído examina um estudo separado sobre empresas.

Fontes e leituras adicionais