Why Are AI Agent Involved Pull Requests (Fix-Related) Remain Unmerged? An Empirical Study
Este estudo empírico analisa mais de 8.000 pull requests relacionados a correções de cinco agentes de codificação de IA para identificar que falhas em casos de teste e resoluções de problemas duplicados são os principais obstáculos para a integração, enquanto falhas de compilação são raras, destacando, assim, as principais limitações nos agentes de IA atuais e direções para melhorar a colaboração entre humanos e IA na manutenção de software.
Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo
Imagine um projeto de software como um canteiro de obras gigante e movimentado. Os "mantenedores" são os gerentes do local que decidem quais plantas serão construídas e quais serão jogadas no lixo. Recentemente, eles começaram a contratar agentes de IA (como assistentes robóticos) para elaborar planos de reparo (chamados de "Pull Requests" ou PRs) para consertar partes quebradas do edifício.
Este artigo é como um relatório de detetive perguntando: "Com que frequência esses assistentes robóticos realmente têm seus planos de reparo aprovados e, quando não são, por quê?"
Aqui está o detalhamento de suas descobertas, usando analogias simples:
1. O Panorama Geral: A Taxa de Sucesso
Os pesquisadores analisaram mais de 8.000 planos de reparo enviados por cinco tipos diferentes de robôs de IA (OpenAI Codex, GitHub Copilot, Devin, Cursor e Claude Code).
- A Boa Notícia: Cerca de 65% das vezes, os gerentes do local disseram "Sim, construa isso!" e integraram o conserto. Os robôs estão fazendo um trabalho decente.
- A Má Notícia: Cerca de 26% das vezes, os gerentes disseram "Não" e fechararam o plano sem construí-lo. Outros 9% ainda estão na sala de espera, indecisos.
- As Diferenças entre os Robôs: Nem todos os robôs são criados iguais.
- OpenAI Codex é o aluno de destaque: foi aprovado 81% das vezes.
- Devin foi o que mais teve dificuldades: ele só foi aprovado 43% das vezes, o que significa que mais da metade de seus planos de reparo foram rejeitados.
2. O "Porquê": Por que os Planos são Rejeitados?
Os pesquisadores investigaram profundamente os 326 planos rejeitados para descobrir exatamente por que falharam. Eles encontraram 12 razões diferentes, que agruparam em três categorias principais:
A. Problemas de "Conserto Errado" (Questões Técnicas)
Às vezes, o robô tenta consertar um vazamento, mas acaba quebrando o cano.
- Falhas de Teste (O motivo técnico mais comum): O conserto do robô passou pela própria lógica do robô, mas falhou nos testes rigorosos de segurança do projeto. É como um chef cozinhando uma refeição que parece ótima, mas tem um gosto terrível quando o inspetor de saúde (o conjunto de testes) a experimenta.
- Consertos Incompletos ou Errados: O robô adivinhou o problema, mas resolveu a coisa errada, ou consertou apenas metade dele.
- Falhas de Build/Deploy: Raramente, o conserto estava tão quebrado que o edifício nem sequer conseguia ser montado (não compilava ou não rodava).
B. Problemas de "Momento Errado" (Questões de Processo)
Às vezes, o conserto é realmente bom, mas o momento está errado.
- Alguém Fez Antes (O motivo nº 1 para Rejeição): Isso aconteceu em 22% dos casos. O robô estava trabalhando duro para consertar uma janela quebrada, mas um humano (ou outro robô) já a havia consertado cinco minutos antes. O plano do robô foi rejeitado simplesmente porque era redundante.
- Inatividade: O robô enviou um plano, mas depois ficou em silêncio. Os gerentes ficaram entediados esperando uma resposta e fecharam o ticket.
- Baixa Prioridade: O problema que o robô tentou consertar não era mais importante ou os gerentes do projeto decidiram ignorá-lo.
C. Problemas de "Falha de Comunicação"
- Sem Revisão: O robô pediu uma revisão, mas nenhum gerente humano sequer olhou para ela.
- Rejeição Silenciosa: O plano foi fechado sem qualquer explicação, deixando o robô (e os pesquisadores) no escuro sobre o porquê de ter falhado.
3. O Fator "Velocidade"
Os pesquisadores também mediram quanto tempo levava para um plano ser aprovado.
- Integrações Rápidas: Muitos consertos bons foram aprovados muito rapidamente.
- Integrações Lentas: Alguns levaram muito tempo. Curiosamente, o "aluno de destaque" (OpenAI Codex) teve os tempos de aprovação mais consistentes e rápidos, enquanto outros tiveram tempos de espera muito mais imprevisíveis.
A Conclusão
O artigo conclui que, embora os robôs de IA estejam ficando melhores em escrever código, escrever código não é o suficiente.
Para que um plano de reparo seja aprovado no mundo real, o robô precisa:
- Passar nos testes rigorosos de segurança (não apenas parecer bom).
- Não duplicar o trabalho que humanos ou outros robôs já fizeram.
- Manter-se engajado na conversa com os gerentes humanos.
Atualmente, os maiores obstáculos não são que os robôs não consigam escrever código; é que eles frequentemente falham nos testes ou são ultrapassados por outras pessoas consertando o mesmo problema. O estudo sugere que, para a IA se tornar verdadeiramente um "colega virtual" confiável, ela precisa entender melhor o contexto do projeto e o tempo do fluxo de trabalho, não apenas o código em si.
Afogado em artigos na sua área?
Receba digests diários dos artigos mais recentes que correspondam às suas palavras-chave de pesquisa — com resumos técnicos, no seu idioma.