PRs de agentes de código já são parte do trabalho real. Claude Code, Codex, Copilot, Devin e Cursor conseguem abrir patches, responder feedback e tentar corrigir CI. O problema é que um PR gerado por agente pode parecer limpo e ainda custar caro para revisar.
Em 2026, um estudo MSR/arXiv analisou 33.596 PRs agentic no GitHub e encontrou 24.014 mesclados, ou 71,48% do total (arXiv, "Where Do AI Coding Agents Fail?", 2026). A leitura útil não é "agentes funcionam" ou "agentes falham". É descobrir por que uma parte relevante morre antes do merge.
Resumo prático
- PR agentic precisa chegar pequeno, testado e com escopo claro.
- Abandono de revisor, duplicidade e CI quebrado aparecem como padrões de rejeição.
- Subagentes ajudam quando revisam sinais separados, não quando criam mais narrativa.
- O melhor PR de agente economiza julgamento humano; ele não terceiriza responsabilidade.
Por que PRs de agentes de código falham antes do merge?
Em 2026, o estudo "Where Do AI Coding Agents Fail?" analisou 33.596 PRs de cinco agentes em projetos GitHub com mais de 100 estrelas (arXiv, 2026). Os PRs falham quando misturam escopo amplo, CI frágil e pouca coordenação com mantenedores.
O achado mais importante é prático. PRs de documentação, CI e build tiveram as melhores taxas de merge, enquanto tarefas de performance e correção de bug ficaram piores. Isso faz sentido: manutenção localizada é mais fácil de validar, mas bug e performance exigem contexto de produto, regressão e critério de aceitação.
O estudo também mostra que PRs não mesclados tendem a tocar mais arquivos, alterar mais linhas e falhar mais checagens de CI. Para um revisor, isso muda o custo cognitivo. Ele não está só lendo código. Está reconstruindo intenção, limite, impacto e prova.
Esse recorte aprofunda o texto sobre evals de PR que seguram agentes no CI. Evals medem o patch. Aqui, a pergunta é anterior: como empacotar o PR para ele merecer revisão.
Cápsula citável: PRs de agentes de código falham quando chegam como pacote grande demais para confiar. O estudo MSR/arXiv de 2026 analisou 33.596 PRs agentic e associou não merge a mudanças maiores, mais arquivos tocados e mais falhas de CI.
O que o PR precisa provar antes de pedir revisão?
Em 2026, o GitHub afirmou que o Copilot code review já processou mais de 60 milhões de revisões e que mais de uma em cada cinco revisões no GitHub envolve um agente (GitHub Blog, "Agent pull requests are everywhere", 2026). Volume sem prova vira fila.
O PR do agente precisa provar quatro coisas antes de marcar alguém. Primeiro, qual comportamento mudou. Segundo, por que o escopo ficou limitado. Terceiro, quais comandos rodaram. Quarto, que risco ainda precisa de julgamento humano. Sem isso, o revisor vira depurador de intenção.
Não aceite um corpo de PR que só diz que tudo foi implementado. Peça evidência curta: comando, saída resumida, arquivo crítico e caso negativo. Se a tarefa corrige bug, o teste deve falhar antes da correção. Se cria recurso, o PR deve mostrar limite e comportamento não suportado.
Isso conversa com harness de agentes de código para PRs confiáveis. O harness define o contrato. O PR entrega a prova de que o contrato foi seguido.
| Prova no PR | O que o revisor decide |
|---|---|
| Escopo declarado | Se o diff respeita a tarefa original. |
| Teste novo ou existente | Se a mudança pode ser validada sem fé. |
| Saída de CI | Se o agente quebrou o caminho básico. |
| Risco residual | Se precisa de reviewer de segurança, dados ou infra. |
Cápsula citável: Um PR de agente só está pronto para revisão quando traz intenção, escopo, comando e risco residual. O GitHub relata dezenas de milhões de revisões com Copilot; nesse volume, pedir revisão sem evidência transfere custo para humanos.
Como reduzir abandono de revisor sem pedir fé no agente?
Em 2026, a análise qualitativa do estudo classificou 562 PRs rejeitados acessíveis; abandono ou ausência de revisão significativa apareceu em 228 casos, cerca de 38% (arXiv, "Where Do AI Coding Agents Fail?", 2026). O PR morre quando ninguém enxerga valor suficiente para entrar no diff.
Abandono não é só preguiça do mantenedor. Em projetos ocupados, um PR amplo, sem plano e aberto por agente compete contra trabalho humano com contexto social. Se o patch parece experimento, duplicação ou tentativa genérica, ele perde prioridade antes da primeira revisão técnica.
O antídoto é reduzir ambiguidade. Abra PRs pequenos. Mostre issue ou requisito. Declare arquivos fora de escopo. Confirme que você procurou PRs parecidos. Se o agente gerou várias alternativas, não empurre todas para o mantenedor. Escolha uma e explique por que as outras foram descartadas.
No estudo, duplicidade apareceu em 142 PRs rejeitados, ou 23% da amostra categorizada. Esse dado é duro para agentes: eles podem escrever rápido, mas nem sempre sabem que outra pessoa já abriu trabalho equivalente. Antes de abrir PR, rode busca por issue, branch e PR aberto.
Experiência prática: eu trato PR agentic sem plano como rascunho interno. Só peço revisão quando o diff conta uma história curta: problema, limite, prova e pergunta pendente. Se a pergunta pendente é "você pode entender tudo?", o PR ainda não está pronto.
Onde CI e testes devem bloquear o patch?
Em 2026, o estudo encontrou falha de CI ou teste em 99 dos 562 PRs rejeitados categorizados, cerca de 17% da amostra (arXiv, "Where Do AI Coding Agents Fail?", 2026). CI deve bloquear não só teste vermelho, mas também tentativas de enfraquecer a verificação.
O GitHub recomenda tratar qualquer enfraquecimento de CI como parada dura em PRs de agente. Isso inclui teste removido, lint pulado, cobertura reduzida, workflow que deixa de rodar em PR e comando com atalho para passar mesmo falhando (GitHub Blog, "Agent pull requests are everywhere", 2026).
O gate mínimo deve verificar três coisas. A primeira é integridade do teste: nenhum teste removido, renomeado ou marcado como ignorado sem justificativa. A segunda é relação com a tarefa: bug corrigido precisa de teste de reprodução. A terceira é escopo: arquivos sensíveis exigem reviewer certo.
Para backend e DevOps, marque áreas de alto risco. Autenticação, cobrança, dados pessoais, migração, fila, workflow de CI, infraestrutura e permissão não devem passar só com aprovação do agente. O PR pode estar correto, mas o custo do erro é maior.
Cápsula citável: CI para PRs agentic precisa detectar teste quebrado e teste enfraquecido. O estudo MSR/arXiv encontrou falha de CI ou teste em cerca de 17% dos PRs rejeitados categorizados, e o GitHub recomenda bloquear qualquer mudança que reduza a verificação.
Como usar subagentes sem multiplicar ruído?
Em 2026, a documentação do Codex diz que subagentes ajudam em tarefas paralelas, como exploração de codebase ou plano de múltiplas etapas, mas também avisa que eles consomem mais tokens que uma execução única (OpenAI, "Subagents", 2026). Use subagentes para separar observação, não para inflar autoria.
Subagente bom revisa um sinal. Um olha testes. Outro olha segurança. Outro confere escopo. Outro compara requisito com diff. O agente principal consolida, mas não deve esconder divergência. Se o subagente de segurança bloqueia, o PR precisa carregar esse bloqueio.
A documentação do Claude Code lista benefícios como preservar contexto, limitar ferramentas e especializar comportamento com prompts focados (Anthropic, "Create custom subagents", 2026). Isso é útil porque PR de agente falha quando o revisor recebe contexto demais ou contexto errado.
Quando o PR exige várias sessões, subagentes e evidências sem despejar todo o histórico no prompt principal, eu uso o RemoteCode como ferramenta do autor para estender Claude Code e Codex em fluxos agentic com menos desperdício de contexto. Ele ajuda a coordenar o trabalho; não substitui review, CI ou gate de segurança.
Esse padrão complementa fan-out de subagentes para migrar código sem perder controle. Fan-out só ajuda quando cada saída tem formato curto, severidade, arquivo e próxima ação.
Cápsula citável: Subagentes melhoram PRs de agentes de código quando reduzem contexto para o revisor. Codex documenta subagentes para tarefas paralelas e alerta sobre custo de tokens; Claude Code destaca contexto isolado e restrição de ferramentas como benefícios práticos.
Qual é o checklist mínimo antes de abrir o PR?
Em 18 de junho de 2026, o GitHub anunciou que o Copilot code review passou a usar instruções relevantes de AGENTS.md no repositório (GitHub Changelog, "Copilot code review: AGENTS.md support and UI improvements", 2026). O checklist deve virar contexto versionado, não memória oral.
Antes de abrir o PR, valide esta sequência:
- O PR resolve uma issue, tarefa ou requisito nomeado.
- O diff toca poucos arquivos e explica qualquer exceção.
- O corpo do PR lista comandos rodados e resultado.
- Um teste falha antes da correção quando o caso é bug.
- Nenhum teste, lint, cobertura ou workflow foi enfraquecido.
- PRs e issues parecidos foram procurados antes da abertura.
- Áreas sensíveis disparam reviewer humano específico.
- O agente parou quando faltou contexto, em vez de inventar certeza.
Esse checklist pode morar no AGENTS.md, no template de PR ou em um job chamado agent-pr-eval. O formato importa menos que a aplicação. Se o agente não consegue produzir esse pacote, ele ainda está em etapa de rascunho.
Para times que já usam AGENTS.md enxuto para agentes de código, a melhoria é direta: adicione uma seção curta de PR agentic com prova obrigatória, limites de escopo e regra de parada.
Perguntas frequentes sobre PRs de agentes de código
PR de agente deve ser menor que PR humano?
Na prática, sim. Em 2026, o estudo MSR/arXiv observou que PRs não mesclados tendem a tocar mais arquivos e alterar mais linhas (arXiv, "Where Do AI Coding Agents Fail?", 2026). O agente pode produzir rápido, mas o revisor ainda paga pelo tamanho do diff.
O revisor pode confiar se todos os testes passaram?
Não sozinho. Em 2026, o GitHub alertou que agentes podem enfraquecer CI ao remover testes, pular lint ou alterar workflows (GitHub Blog, "Agent pull requests are everywhere", 2026). Teste verde importa, mas verifique se a prova não foi diminuída.
Subagente deve comentar direto no PR?
Só quando a saída tem contrato claro. Em 2026, OpenAI documentou subagentes para tarefas paralelas e Anthropic destacou restrição de ferramentas em subagentes (OpenAI, "Subagents", 2026; Anthropic, "Create custom subagents", 2026). Prefira comentário com achado, arquivo, severidade e próxima ação.
Como evitar PR duplicado de agente?
Comece por busca. Em 2026, duplicidade apareceu em 142 dos 562 PRs rejeitados categorizados no estudo MSR/arXiv (arXiv, "Where Do AI Coding Agents Fail?", 2026). Antes de abrir patch, procure issue, PR, branch e discussão existente com termos do problema.
Fontes consultadas
- arXiv, "Where Do AI Coding Agents Fail? An Empirical Study of Failed Agentic Pull Requests in GitHub", recuperado em 2026-07-16, https://arxiv.org/abs/2601.15195
- GitHub Blog, "Agent pull requests are everywhere. Here's how to review them", recuperado em 2026-07-16, https://github.blog/ai-and-ml/generative-ai/agent-pull-requests-are-everywhere-heres-how-to-review-them/
- GitHub Changelog, "Copilot code review: AGENTS.md support and UI improvements", recuperado em 2026-07-16, https://github.blog/changelog/2026-06-18-copilot-code-review-agents-md-support-and-ui-improvements/
- OpenAI, "Subagents", recuperado em 2026-07-16, https://developers.openai.com/codex/subagents
- Anthropic, "Create custom subagents", recuperado em 2026-07-16, https://docs.anthropic.com/en/docs/claude-code/sub-agents
