O gate de PR e tarde demais

A maioria dos times trata code review como um gate no final: escrever codigo, abrir um PR, esperar um revisor. Isso funcionava quando humanos escreviam cada linha e PRs eram pequenos. Nao funciona quando agentes de IA geram centenas de mudancas em uma feature branch antes de alguem olhar o resultado.

Quando um PR e aberto, os problemas ja estao consolidados. Drift estrutural aconteceu tres commits atras. Uma clausula de guarda foi removida no segundo commit e ninguem notou. A fronteira de autenticacao se ampliou em um refactor que parecia cleanup. O revisor ve uma parede de mudancas e ou passa o olho ou gasta uma hora reconstruindo o que aconteceu.

Esperar ate o PR estar aberto para comecar a verificar e como esperar ate o predio estar pronto para verificar a fundacao.

Revisao durante o desenvolvimento, nao depois

Os times que entregam com seguranca usando IA nao guardam toda a revisao para o final. Eles verificam continuamente, durante o ciclo de desenvolvimento.

Isso significa rodar verificacao apos cada mudanca significativa, nao apenas antes do merge. Quando um agente de IA termina uma tarefa, o desenvolvedor verifica o que realmente mudou antes de passar para o proximo prompt. Quando uma feature branch tem cinco commits, cada um foi verificado antes do proximo ser construido em cima.

Isso nao e "revisar mais." E revisar mais cedo, quando o contexto esta fresco, as mudancas sao pequenas e o custo de corrigir um problema e minutos em vez de horas.

Um CTO processando mais de 1.000 PRs por semana de agentes de IA descreveu: "Alguem precisa cuidar das criancas. Isso e CI/CD. Esse e o novo campo de batalha." Mas CI/CD roda no final. A verdadeira alavancagem e verificacao durante a sessao, antes da branch sequer ser enviada.

Do spec ao merge: verificacao em cada estagio

Um ciclo de revisao continua tem checkpoints em cada estagio, nao apenas no ultimo.

Durante o planejamento. Antes de escrever qualquer codigo, o spec define o que "correto" significa. O que deve mudar, o que nao deve, quais restricoes se aplicam. Sem isso, nao ha como verificar se a implementacao corresponde a intencao. Um arquiteto descreveu o problema: "Eu comeco cada revisao reconstruindo o que 'correto' atualmente significa para aquela area da base de codigo." Se essa reconstrucao acontece antes do desenvolvimento comecar, a revisao no final fica mais simples.

Durante a implementacao. Apos cada mudanca significativa, verificacao roda localmente. O desenvolvedor ve o que estruturalmente mudou, quais sao os sinais de risco e se algo foi perdido. Problemas sao capturados quando tem um commit de idade, nao vinte. E aqui que a maioria dos problemas e mais barata de corrigir e onde o desenvolvedor ainda tem contexto completo do que pretendia.

Antes do push. Uma verificacao local final cobre o diff completo contra a branch base. Esse e o gate de qualidade do proprio desenvolvedor antes de envolver outros. Captura efeitos de acumulacao que revisoes individuais de commit podem perder: pequenas mudancas que se acumulam em um grande raio de impacto.

No CI. A mesma verificacao roda automaticamente em cada PR. Essa nao e a primeira vez que alguem ve os resultados. E a ultima verificacao, confirmando que o que o desenvolvedor ja verificou localmente ainda se mantem. Se CI e a primeira vez que problemas aparecem, o processo upstream falhou.

Por que CI sozinho nao e suficiente

CI captura problemas, mas os captura no ponto mais caro. A branch foi enviada, o PR esta aberto, um revisor foi atribuido. Se CI sinaliza algo, voce esta agora em um ciclo de corrigir-enviar-esperar que adiciona horas ou dias.

Mais importante, CI roda depois que o desenvolvedor perdeu contexto. Se um problema foi introduzido tres commits atras, o desenvolvedor ja seguiu em frente. Reconstruir por que fez aquela mudanca e qual e a correcao certa leva mais tempo do que teria levado na hora.

CI e necessario. E a rede de seguranca. Mas nao deveria ser o mecanismo primario para capturar problemas. O mecanismo primario deveria ser verificacao local durante o desenvolvimento, com CI confirmando o que ja foi verificado.

O efeito composto

Quando verificacao roda continuamente, cada revisao e pequena. Um unico commit e facil de entender, facil de verificar, facil de corrigir. Quando verificacao so roda no final, o revisor enfrenta a complexidade acumulada de todas as mudancas de uma vez.

Esse e o mesmo principio por tras de PRs pequenos, mas aplicado ao processo de verificacao em si. Verificacoes pequenas e continuas sao mais faceis do que uma grande revisao. O tempo total gasto revisando pode ser o mesmo ou menor, mas a qualidade de cada revisao e maior porque o escopo e gerenciavel e o contexto esta fresco.

Times que verificam continuamente relatam gastar menos tempo na revisao final do PR, nao mais. O gate de CI se torna um passo de confirmacao, nao um passo de descoberta. Revisores focam em intencao e arquitetura em vez de reconstruir o que aconteceu.