Code review na era dos agentes: quem revisa o código gerado por IA

Quando um agente escreve o código, a primeira pergunta não é “funciona?”, e sim “quem vai revisar?”. A velha intuição (o autor escreve, o revisor lê) deixa de servir, porque o “autor” é um modelo que não arca com consequências e não se lembra da decisão de ontem. O code review não desaparece. O que muda é a estrutura dele. Os melhores times que eu acompanho montam duas revisões: primeiro um agente revisor, depois um humano. Cada um pega uma classe diferente de bugs, e esse é justamente o ponto.

O modelo de duas revisões

A primeira camada é o agente revisor: uma passada separada do modelo, que lê o diff antes de uma pessoa. A segunda camada é o humano, que lê o que sobrou depois do agente. A ordem não é por acaso. O agente é barato e nunca se cansa, então vai primeiro: ele filtra o ruído antes que isso comece a custar tempo de sênior. O humano entra por último, porque a atenção humana é o recurso mais caro de todo o processo e não pode ser desperdiçada com coisas que uma máquina pega sozinha.

Não é “a mesma coisa duas vezes”. Se o agente e o humano pegassem os mesmos bugs, a segunda camada seria desperdício. O valor aparece justamente porque os campos de visão dos dois não se sobrepõem. O agente enxerga padrões no código. O humano enxerga sentido no problema.

Por que cada revisão pega bugs diferentes

O agente revisor é excelente no que é mecânico e repetitivo: estilo inconsistente, tipos faltando, um ramo de erro sem tratamento, um caminho de código ingênuo que ninguém vai testar, duplicação que o autor não percebeu porque só olhou para o próprio arquivo. O modelo lê mil linhas sem se entediar e aponta vinte lugares onde falta tratamento de null. E faz isso com a mesma consistência às 9h e às 23h, no primeiro PR do dia e no trigésimo.

O humano pega o que o modelo, por estrutura, não consegue ver: uma leitura errada do domínio. O agente recebeu a tarefa “calcule o desconto” e calculou o desconto, só que nesta empresa o desconto é calculado sobre o preço líquido, e não sobre o bruto, e esse fato não está em lugar nenhum do código, porque vive na cabeça de três pessoas. O modelo não sabe que está escrevendo uma resposta correta para a pergunta errada. Quem pega isso é um humano que conhece o contexto.

A segunda coisa reservada ao humano: o “problema resolvido pela metade”. Um agente consegue fechar um ticket com um código que trata o happy path e parece completo, enquanto fica em silêncio sobre a migração de dados que ficou de fora, o edge case da lista vazia e a retrocompatibilidade da API. O código compila, os testes passam, o PR parece pronto. Só que o problema está 50% resolvido, e os outros 50% são exatamente o que explode em produção. O modelo não tem a noção de “isso realmente encerra o assunto?”. O humano tem.

O agente revisor comenta, mas nunca aprova sozinho

Esta é a regra que não se quebra: o agente revisor pode comentar, mas não pode aprovar um PR por conta própria. Aqui, a diferença entre um assistente e quem decide é absoluta. No momento em que o agente começa a fazer merge das próprias observações sem uma decisão humana, você fecha um loop em que a máquina julga a máquina, e as duas têm os mesmos pontos cegos.

O motivo é prático, não filosófico. O agente revisor roda sobre a mesma distribuição de treinamento que o agente autor. As mesmas premissas que o autor adotou em silêncio, o revisor considera óbvias e deixa passar. Um bug de domínio invisível para o autor também é invisível para um revisor da mesma família de modelos. É por isso que a aprovação humana não é uma formalidade: é o único ponto do loop em que entra contexto de fora dos dados de treinamento.

Na prática: o agente revisor deixa comentários no PR, marca os pontos de risco e sugere correções. O status “approved” é dado por um humano, de forma consciente, assumindo a responsabilidade pelo que entra na main. O agente nunca é a última assinatura.

O que acontece quando o agente entrega 5x mais PRs

É aqui que começa o verdadeiro problema de escala. O agente não escreve cinco vezes melhor: ele escreve cinco vezes mais. Um engenheiro com um agente bem configurado abre tantos PRs quanto um time pequeno abria antes. O gargalo deixa de ser escrever código. Passa a ser a revisão.

Os times que não previram isso caem em um de dois modos. Ou a revisão vira só um carimbo: as pessoas clicam em “approve” porque a fila tem quarenta itens e ninguém lê nada com honestidade. Ou a revisão vira o gargalo que apaga todo o ganho de velocidade dos agentes: você escreve 5x mais rápido, mas entrega no ritmo antigo de qualquer jeito, porque os PRs ficam três dias parados na fila.

A saída não é ler mais rápido. É ler menos, porém com mais inteligência. O agente revisor deve assumir toda a base da pirâmide: estilo, tipos, lacunas óbvias. O humano recebe um PR já filtrado, com os pontos de risco marcados, e lê só o que exige julgamento humano. O segundo mecanismo é a diferenciação: um PR que muda o texto do rodapé não precisa da mesma revisão que uma mudança no código de cobrança. O terceiro: PRs pequenos. Um agente que entrega 5x mais deve entregar pedaços 5x menores, porque revisar dez diffs pequenos é mais honesto do que revisar um enorme.

Fadiga de revisão e como combatê-la

Fadiga de revisão não é preguiça: é a fisiologia da atenção. Depois do vigésimo PR no mesmo dia, uma pessoa já não lê, só escaneia. O cérebro muda para o modo de reconhecimento de padrões: “parece com os anteriores, deve estar ok”. É exatamente nesse momento que um bug de domínio passa, porque, por definição, ele parece correto.

Com agentes, o problema se intensifica, porque o código de um agente é uniformemente caprichado. Sem erros de digitação, sem indentação estranha, nada que faça o olho parar. Tudo parece bom, então o revisor para de fazer pausas. Paradoxalmente, a perfeição cosmética do código gerado por modelo adormece a vigilância mais rápido do que o código cru de um júnior, que obriga você a pensar.

O que funciona na prática. Limite o número de revisões por pessoa por dia: depois de certo ponto, a qualidade cai abaixo de zero, ou seja, você deixa entrar mais bugs do que pega. Faça rodízio de revisores para que ninguém leia trinta PRs seguidos. Exija do autor (inclusive do agente) uma descrição de “o quê e por quê” no PR, porque a leitura começa pela intenção, não pelo diff. E separe as revisões “triviais” das “arriscadas”: faça as segundas de manhã, com a cabeça descansada, e não às 18h como a vigésima do dia.

Um checklist prático de PR para a era dos agentes

Esta é a lista que um humano percorre de forma consciente, depois que o agente revisor já deixou os comentários dele. O agente cuida dos pontos mecânicos; esta lista trata do que o modelo não vai pegar:

1. Este código resolve o problema certo, e não o problema ao lado?
2. O problema está fechado ou isso é só o happy path? Onde estão os edge cases?
3. As premissas de domínio estão corretas para esta empresa, e não para o livro-texto?
4. O que acontece com a migração de dados e com a retrocompatibilidade?
5. Os testes verificam comportamento ou só que uma linha foi executada?
6. O agente revisor marcou pontos de risco, e cada um deles foi resolvido?
7. O PR é pequeno o bastante para ter sido lido com honestidade?
8. Estou assumindo a responsabilidade por este merge, ou estou clicando em “approve” por cansaço?

O último ponto é o mais importante. Se a resposta for “clicando por cansaço”, o processo tem PRs demais para pouca atenção humana, e o que você conserta é o processo, em vez de empurrar o PR.

Mito: se o agente escreve, o agente que revise

Tentador e falso. Sim, um segundo agente vai pegar algumas coisas, e deve pegar: esse é todo o papel da primeira camada. Mas dois modelos da mesma família compartilham os mesmos pontos cegos. A interpretação do domínio, o problema “resolvido pela metade” e a responsabilidade pela produção continuam humanos. O agente revisor escala a revisão na base da pirâmide, onde os bugs são numerosos e mecânicos. O humano guarda o topo, onde os bugs são raros, caros e invisíveis para a máquina. Tire o humano e você tira o único ponto do loop que enxerga além dos dados de treinamento.

TL;DR

Code review na era dos agentes são duas revisões: primeiro o agente revisor, depois o humano. O agente pega estilo, tipos e lacunas mecânicas; o humano pega a leitura errada do domínio e o problema resolvido pela metade. O agente comenta, mas nunca aprova sozinho, porque compartilha os pontos cegos do autor. Quando o agente entrega 5x mais PRs, a revisão vira o gargalo: salve-a com filtragem, diferenciação de risco e PRs pequenos. Combata a fadiga de revisão com limites e rodízio. Siga o checklist, e a última pergunta é sempre: estou assumindo a responsabilidade por este merge?