Metade das Correções de Código Geradas por IA Não Passam na Revisão Humana

As correções de código propostas por agentes de codificação IA são rejeitadas por revisores humanos 46,41% do tempo, de acordo com uma análise do conjunto de dados AIDev que abrange 932.791 pull requests agenticos em 116.211 repositórios e 72.189 desenvolvedores. Isso representa horas de revisão humana perdidas, ciclos de computação CI e gasto de tokens em fluxos de trabalho que nunca são enviados.

Um artigo arXiv intitulado "Understanding the Rejection of Fixes Generated by Agentic Pull Requests" analisou 306 PRs agenticos não mesclados do GitHub Copilot, Devin, Cursor e Claude Code. Os pesquisadores identificaram 14 razões distintas para rejeição agrupadas em quatro modos de falha: implementação incorreta, falha na pipeline CI, incapacidade do agente e correções de baixa prioridade. Esta taxonomia fornece aos arquitetos um modelo de falha para depurar sua cadeia de ferramentas do agente.

Estudos acompanhantes no mesmo conjunto de dados quantificam a fricção. Entre 61.837 execuções de fluxos de trabalho GitHub Actions em 2.355 repositórios, Copilot e Codex alcançam taxas de sucesso CI/CD acima de 93%, enquanto Claude e Cursor quebram builds com mais frequência. No entanto, altas taxas de aprovação CI não garantem merges. As correções geradas pelo Copilot atraíram a maior discussão dos revisores, mas alcançaram a menor taxa de merge em 42,4% em PRs relacionados a correções, apesar de terem uma média de 2,56 comentários por PR. Todos os outros agentes ficaram abaixo de 1,0 comentário por PR. O Cursor atraiu a maior sentimento negativo. Devin auto-encerrou 32,1% de seus próprios PRs após detectar inatividade do revisor - postando comentários de "Encerrando devido à inatividade" - alcançando uma taxa de merge de 42,9% em trabalho de correção. A análise também encontrou uma correlação negativa entre a frequência de contribuição agentica e o sucesso geral do fluxo de trabalho, indicando que um volume maior de agentes erode a confiabilidade da pipeline.

O problema central: as correntes de ferramentas atuais tratam a geração de pull-request como geração aberta, em vez de trabalho de engenharia restrito. O artigo identifica três pontos de controle que reduzem a rejeição. Primeiro, forneça dicas explícitas de abordagem aos agentes antes da geração. Segundo, descreva restrições e padrões proibidos. Terceiro, aplique validação CI sem introduzir mudanças que quebrem. A implementação desses requer uma camada de orientação entre o rastreador de problemas e a janela de contexto do agente, filtrando tarefas de baixa prioridade e validando contra conjuntos de testes antes que humanos vejam a diferença.

Arquitetos corporativos devem esperar diferentes níveis de fricção em monorepos privados com ferramentas de teste proprietárias, portões de conformidade mais restritivos e janelas de contexto maiores. Os estudos não quantificam o custo oculto da mudança de contexto do revisor - o imposto de atenção quando 46% dos PRs agenticos atraem escrutínio antes da rejeição. A questão chave é se portões CI nativos do agente podem capturar modos de falha antes da criação do PR, ou se as ferramentas atuais geram muito volume para a largura de banda de revisão existente.

Os arquitetos devem adotar o padrão de orientação de três níveis - dicas de abordagem, delineamento de restrições e validação CI pré-envio - como um plano de controle obrigatório antes que qualquer bot agentico abra um pull request.