Um debate recente no Hacker News resumiu uma sensação que muita equipe já conhece: escrever código ficou absurdamente rápido; validar se ele faz o que deveria continua caro. Com IA no fluxo, essa diferença ficou ainda mais visível.
O relato não era sobre abolir review. Era sobre um gargalo que mudou de lugar. Quando abrir uma PR leva minutos, o revisor recebe mais mudanças, mais contexto para reconstruir e mais risco escondido atrás de um diff aparentemente limpo.
O review não ficou lento por preguiça
Em uma das respostas, a recomendação foi começar pela pergunta que quase sempre fica implícita: para que serve o review naquele time? Encontrar defeito, dividir conhecimento, proteger arquitetura, manter padrão ou discutir produto são trabalhos diferentes. Misturar tudo numa única aprovação transforma a PR em fila.
Outra resposta descreveu PRs pequenos e encadeados: contrato, especificação, mecânica, lógica, integração e limpeza. Não é uma receita universal, mas resolve uma coisa básica: o revisor consegue manter a mudança na cabeça. PR gigante pede que alguém reconstrua um sistema inteiro para dizer “LGTM”.
IA aumenta a necessidade de contexto
O ganho de velocidade é real. Só que texto de código convincente não prova que a decisão é boa para aquele produto. Um assistente pode respeitar a sintaxe e ainda ignorar convenções locais, duplicar regra de negócio ou escolher uma abstração que deixa a próxima alteração pior.
Por isso, usar IA para gerar o primeiro rascunho não deveria empurrar toda a validação para uma pessoa no fim da esteira. O trabalho mais útil é antecipar contexto: qual problema a mudança resolve, quais invariantes não podem quebrar e como o comportamento foi testado.
O que vale automatizar antes de chamar alguém
As orientações de engenharia do Google tratam velocidade de review como uma preocupação explícita, mas sem defender aprovação cega. A ideia é reduzir espera e retrabalho com mudanças revisáveis, resposta clara e ferramentas para o que é mecânico.
- Deixe formato, lint e testes na CI. Revisor não deveria gastar atenção com uma vírgula que uma ferramenta já sabe apontar.
- Explique a intenção no começo da PR. Uma boa descrição informa o que mudou, por quê e como conferir.
- Limite o tamanho pela capacidade de entender. Se não dá para explicar a mudança sem uma reunião longa, talvez ela ainda seja grande demais.
- Separe bloqueio de sugestão. Nem todo comentário precisa parar entrega; isso reduz atrito sem baixar a régua.
- Use IA como segunda leitura, não como carimbo. Ela pode resumir diff e sugerir teste, mas não substitui responsabilidade técnica.
O gargalo é uma pista de processo
Quando o review trava, a saída mais fácil é cobrar que alguém aprove mais rápido. A saída que costuma escalar melhor é descobrir o que está chegando tarde: contexto, teste, decisão de arquitetura ou alinhamento de produto.
O código pode ter ficado barato para produzir. Confiança continua sendo construída devagar — e essa talvez seja exatamente a parte que vale proteger.
