Por Que PRs de Agentes São Rejeitados

Uma das mudanças mais importantes em desenvolvimento de software não é que a IA escreve código. É que a IA já consegue abrir pull requests inteiros. Isso muda o trabalho do dev senior de uma forma mais profunda do que parece.

Antes, revisar código era avaliar o trabalho de outro humano que, em tese, entendia contexto do time, produto e arquitetura. Agora, parte crescente dos PRs vem de agentes que podem ser rápidos, úteis e convincentes, mas que não têm o mesmo compromisso social com o sistema. O agente não sente vergonha de entregar um patch grande demais. Não fica desconfortável por não ter entendido o requisito. Não lembra que aquele módulo sempre quebra em homolog.

Estudos recentes analisando PRs gerados por agentes mostram algo importante: nenhum agente é melhor em tudo. Claude Code, Codex, Cursor, Devin e Copilot têm forças diferentes conforme tipo de tarefa. Alguns performam melhor em features, outros em fixes, outros em documentação. Isso confirma o que times já percebem na prática: o problema não é escolher "o melhor agente", é saber que tipo de trabalho você está delegando e como revisar.

Este post é sobre as razões pelas quais PRs de agentes são rejeitados, o que isso muda no papel do dev senior e como montar um fluxo de review que aproveita velocidade sem aceitar dívida técnica disfarçada.

O Agente Erra Antes de Escrever Código

Muita gente olha para o diff e tenta descobrir onde o agente errou. Mas várias falhas nascem antes do primeiro arquivo editado. O agente entendeu mal o objetivo, escolheu o recorte errado ou otimizou para um critério que ninguém pediu.

Isso acontece porque tarefas humanas carregam contexto implícito. Quando alguém diz "corrige o filtro da tela de propostas", um dev do time talvez saiba que existe uma regra de negócio em aberto, que a API tem comportamento legado, que o bug só aparece com perfil específico e que homolog está com dados incompletos. O agente não sabe disso se ninguém tornar explícito.

O resultado é um PR tecnicamente coerente para o problema errado. O código compila. O teste passa. O diff parece organizado. Mas a feature não resolve o bug real, ou resolve quebrando um fluxo lateral.

Esse é o primeiro trabalho novo do dev senior: revisar intenção antes de revisar implementação. O PR precisa responder: qual problema ele acha que está resolvendo? Quais premissas assumiu? Quais caminhos descartou? Quais contratos tocou? Se essas respostas não estão claras, a revisão já começa atrasada.

Patch Grande Demais É Sinal de Alarme

Agentes têm uma tendência perigosa: quando não sabem o caminho mais curto, criam um caminho longo. Refatoram mais do que precisa, adicionam abstração preventiva, mexem em estilo, reorganizam arquivos e deixam um diff difícil de revisar.

Para um humano, diff grande tem custo social. O revisor reclama. O autor aprende a reduzir escopo. Para agente, esse feedback precisa ser codificado. Sem instrução explícita, ele pode continuar entregando PRs que parecem produtivos pela quantidade de mudança, mas são caros de manter.

Um bom review de PR agêntico deve perguntar: este patch é o menor conjunto de mudanças que resolve o problema? Se não é, por quê? Cada arquivo tocado precisa ter justificativa. Cada abstração nova precisa pagar aluguel imediatamente.

Esse ponto é ainda mais importante porque código gerado por IA pode parecer limpo em superfície. Nomes bons, funções pequenas, comentários educados. Mas se o patch aumenta acoplamento ou duplica regra de negócio, a legibilidade local esconde deterioração global.

Teste Raso É Outro Padrão Repetido

Agentes escrevem testes com facilidade. O problema é que facilidade não significa qualidade. Um teste pode só confirmar o comportamento que o próprio agente implementou, sem validar regra de negócio real.

Esse é um padrão comum: o agente cria teste feliz, com dados simples, sem cobrir erro, permissão, edge case, concorrência ou compatibilidade com estado existente. O CI fica verde e o PR ganha aparência de rigor. Mas a cobertura nova não protege contra a falha que importava.

Para revisar teste de agente, eu uso uma regra simples: o teste falharia contra a implementação antiga? Se não falharia, talvez seja só decoração. Outra pergunta: o teste expressa requisito ou detalhe de implementação? Teste que só congela estrutura interna pode atrapalhar refactor sem proteger usuário.

Feedback sensors ajudam aqui. Linters e typecheck pegam erros superficiais. Testes pegam regressões conhecidas. Mutation testing e fuzzing podem revelar teste fraco. Mas nenhum sensor substitui o revisor perguntando se o teste representa o risco real.

O Agente Nem Sempre Segue Review

Uma falha subestimada é o agente não seguir feedback de review corretamente. Ele pode corrigir um ponto e desfazer outro. Pode interpretar comentário literal demais. Pode aplicar sugestão em lugar errado. Pode fazer uma correção ampla quando o revisor pediu ajuste pontual.

Isso muda o formato ideal de feedback. Comentários vagos como "melhorar isso" funcionam mal. Feedback para agente precisa ser mais próximo de critério de aceitação: "não altere contrato público", "mantenha compatibilidade com X", "adicione teste que falha quando status inválido passa", "reduza diff removendo refactor não relacionado".

Também vale quebrar revisão em rodadas menores. PR de agente com 800 linhas, cinco domínios e 30 comentários vira um jogo de telefone sem fio. Melhor exigir patch menor, rodar sensores e só então avançar.

O dev senior vira editor de instruções. Ele não só aponta problema. Ele transforma problema em comando verificável para o agente corrigir. Essa habilidade vai valer muito.

Segurança Não Pode Ser "Review Depois"

Agentes podem introduzir falhas de segurança de forma sutil: validação insuficiente, logging de dados sensíveis, dependência insegura, bypass de autorização, tratamento errado de redirect, secrets em arquivo, permissões amplas demais. O patch pode parecer uma feature comum, mas abrir superfície crítica.

O risco aumenta porque agentes tendem a resolver localmente. Se precisam de dados, podem logar demais. Se precisam chamar API, podem ignorar timeout. Se precisam desbloquear fluxo, podem relaxar validação. Tudo parece "pragmático" até virar incidente.

Por isso segurança precisa entrar como sensor e como checklist de review. Semgrep, dependency scan, secret scan, SAST, políticas de permissão e testes de autorização devem rodar antes da revisão humana. O humano revisa o que sobrou, não o básico que máquina pode pegar.

Também recomendo marcar áreas sensíveis do repositório: auth, billing, dados pessoais, migrations, infraestrutura, criptografia, permissões. PR agêntico que toca essas áreas precisa de revisão mais rígida e talvez aprovação humana antes mesmo da implementação.

Como Revisar PR de Agente

Meu checklist prático para PRs de agentes começa antes do diff:

Qual era a tarefa original?
Quais premissas o agente assumiu?
O escopo do PR bate com a tarefa?
O patch é menor do que poderia ser?
Testes falham contra a versão antiga?
Alguma área sensível foi tocada?
O agente alterou comportamento não solicitado?
O PR deixa rastros suficientes para auditoria?

Depois olho para arquitetura. O agente respeitou padrões locais? Usou helpers existentes? Duplicou regra? Criou abstração nova sem necessidade? Quebrou fronteira de módulo? Mudou contrato público?

Por fim olho manutenção. Um dev do time entenderia isso daqui a seis meses? O nome das coisas está alinhado com domínio? O teste explica comportamento? O erro é observável? O rollback seria simples?

Essa revisão parece pesada, mas fica mais rápida com prática e sensores. O ponto é não revisar PR agêntico como se fosse só "código escrito mais rápido". Ele é código produzido por um processo diferente e precisa de controles adaptados.

Principais Aprendizados

PRs de agentes falham muitas vezes por intenção errada, não sintaxe.
Patch grande demais é um dos sinais mais claros de risco.
Teste gerado por agente pode ser raso e ainda assim deixar CI verde.
Feedback para agente precisa ser específico, verificável e limitado.
Dev senior vira revisor de intenção, arquitetura e risco.

Conclusão

Agentes de código não eliminam code review. Eles tornam code review mais importante. Quando a produção de código fica barata, o gargalo se move para julgamento: escolher escopo certo, proteger arquitetura, validar comportamento e impedir dívida técnica convincente.

O dev senior que vai se destacar não é o que rejeita agentes, nem o que aceita tudo que eles geram. É o que aprende a delegar bem, criar sensores, revisar intenção e transformar feedback humano em correção executável.

Essa é a nova barra. Não basta saber escrever código. É preciso saber governar código produzido por máquinas rápidas, úteis e imperfeitas.

Fontes e Referências

Sugestão de Imagens

Capa (prs_agentes_rejeitados_cover.png): tela de pull request com comentários de review destacando escopo, testes, segurança e arquitetura.

Inline 1: checklist visual para revisar PR de agente.

Inline 2: fluxo task -> agent PR -> sensors -> human review -> merge.

Por Que PRs de Agentes São Rejeitados

Receba os melhores artigos toda semana

Por Que PRs de Agentes São Rejeitados

O Agente Erra Antes de Escrever Código

Patch Grande Demais É Sinal de Alarme

Teste Raso É Outro Padrão Repetido

O Agente Nem Sempre Segue Review

Segurança Não Pode Ser "Review Depois"

Como Revisar PR de Agente

Principais Aprendizados

Conclusão

Fontes e Referências

Sugestão de Imagens

Receba os melhores artigos toda semana

eltonjose