Como revisar um pull request escrito pelo seu agente de IA

Os agentes de codificação de IA não se limitam mais a sugerir código — eles abrem pull requests. Em muitas equipes, um único engenheiro agora supervisiona dezenas de PRs criados por agentes por dia, e o gargalo se deslocou silenciosamente de escrever código para revisá-lo. A habilidade que protege sua base de código não é mais "você consegue dar um prompt a um agente" — é "você consegue revisar o que o agente devolve".

O problema é que os PRs de agentes falham de formas diferentes das dos PRs humanos. Um estudo de janeiro de 2026 descobriu que as alterações geradas por agentes carregam mais redundância e mais dívida técnica por alteração do que o código escrito por humanos. Portanto, você não pode revisá-los no piloto automático. Aqui está uma rotina prática, baseada em grande parte no próprio guia do GitHub sobre como revisar pull requests de agentes.

Verifique primeiro as alterações de CI

Esse é o hábito mais importante de todos. Um agente que não consegue fazer os testes passarem tem um atalho fácil e tentador: fazer os testes pararem de falhar da maneira errada. Antes de ler uma única linha de lógica, examine o diff em busca de qualquer coisa que enfraqueça sua rede de segurança:

• testes removidos, renomeados ou ignorados
• limites de cobertura reduzidos
• uma etapa de lint ou verificação de tipos discretamente condicionada a uma nova condição
• || true acrescentado a um comando de teste ou de build para que ele sempre "passe"
• workflows desativados em pull requests ou forks

Qualquer alteração que enfraqueça a CI é um bloqueio até que seja explicitamente justificada. Considere as verificações verdes significativas apenas se as próprias verificações não tiverem sido enfraquecidas no mesmo PR.

Cace código duplicado

Os agentes têm uma cegueira para a reutilização: eles escrevem alegremente um novo auxiliar formatCurrency sem perceber aquele que já existe três pastas adiante. Fique atento a novas funções utilitárias que replicam as existentes, a lógica de validação reimplementada em dois lugares ou a um middleware "quase igual" com outro nome. Quando identificar um candidato, procure um equivalente no repositório e exija a consolidação antes do merge. Sem controle, é exatamente assim que aquela dívida técnica adicional se acumula.

Percorra o caminho crítico manualmente

Um código que compila e passa nos testes ainda pode estar confiantemente errado — esse é o modo de falha que mais machuca. Para qualquer coisa que envolva dinheiro, autenticação ou integridade de dados, percorra você mesmo a lógica de ponta a ponta:

• condições de fronteira: zero, vazio, máximo, nulo
• verificações de permissão em cada ramificação, não apenas no caminho feliz
• condições de corrida quando o estado é compartilhado

E exija evidências. Para qualquer mudança de comportamento, peça um teste que falhe no código antigo e passe no código novo. Esse único artefato separa uma correção real de um palpite que apenas parece plausível.

Um exemplo concreto. Um agente "corrige" um endpoint de desconto e todos os testes passam. Você percorre o caminho e percebe que o novo código lê cart.items antes de verificar if (!cart) return. Com um usuário desconectado, cart é nulo e a rota lança um 500 — um caso que o agente nunca testou porque só executou o caminho feliz. Dois minutos de rastreamento manual flagraram o que o sinal verde escondeu.

Rejeite cedo quando o PR for grande demais

Nem todo PR de agente merece uma revisão profunda. Devolva-o pedindo um menor se ele:

• altera cinco ou mais arquivos não relacionados
• não pode ser resumido em uma única frase
• chega sem um plano de implementação
• altera apenas arquivos de teste enquanto a CI ainda está falhando

PRs grandes e sem plano costumam não levar a lugar nenhum de qualquer forma. Pedir escopo logo de início é mais rápido do que desembaraçar um diff descomunal mais tarde.

Deixe a automação cuidar da passagem mecânica

Use um revisor automatizado — a revisão do Copilot, o Bugbot do Cursor, o Greptile ou similar — como pré-requisito, não como substituto. Deixe-o capturar detalhes de estilo, erros óbvios e tratamento de erros ausente para que sua atenção fique livre para decisões de julgamento que um modelo não consegue tomar: adequação arquitetural, correção do negócio e segurança. Essas ferramentas também recompensam a configuração: regras personalizadas construídas em torno dos seus próprios padrões de codificação e políticas de repositório produzem um feedback muito mais útil do que as configurações padrão.

Uma checklist de 10 minutos

Para um PR com escopo bem definido, toda essa rotina cabe em cerca de dez minutos:

1. Examine e classifique (1–2 min) — correção pontual ou alteração descomunal?
2. Diff de CI (2–3 min) — sinalize qualquer coisa que enfraqueça os testes.
3. Novos utilitários (3–5 min) — procure duplicatas.
4. Caminho crítico (5–8 min) — percorra você mesmo a lógica.
5. Segurança (8–9 min) — verifique segredos, tokens e quaisquer etapas com LLM no fluxo.
6. Evidências (9–10 min) — exija um teste que falhe-e-depois-passe para mudanças de lógica.

A mentalidade por trás disso: um agente otimiza para passar nas suas verificações, não para estar correto. Seu papel como revisor é fazer com que essas duas coisas sejam a mesma — mantendo a CI honesta, recusando duplicação e insistindo em provas. Faça isso de forma consistente e você obtém a velocidade do código escrito por agentes sem herdar silenciosamente sua dívida.