Understanding the Rejection of Fixes Generated by Agentic Pull Requests -- Insights from the AIDev Dataset
Este artigo analisa o conjunto de dados AIDev para identificar 14 razões específicas pelas quais quase metade dos pull requests gerados por IA são rejeitados, categorizando esses modos de falha para fornecer orientações acionáveis para melhorar o desempenho de agentes, a priorização de tarefas e a integração em fluxos de trabalho de desenvolvimento 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 que você contrata uma equipe de estagiários robôs supervelozes e hiperentusiastas para corrigir erros no seu software. Você lhes dá um problema e eles imediatamente começam a digitar código, construindo um "Pull Request" (que é como uma proposta para alterar o código).
Este artigo é basicamente um boletim escolar sobre o que acontece quando esses estagiários robôs (especificamente Copilot, Devin, Cursor e Claude) tentam consertar as coisas. Os pesquisadores descobriram uma estatística surpreendente: quase metade das vezes (46,41%), o chefe humano joga o trabalho do robô no lixo.
Aqui está uma análise de por que isso acontece, usando analogias simples:
O Grande Problema: A Conta do "Esforço Desperdiçado"
Cada vez que um robô gera uma correção que é rejeitada, há uma perda dupla. Primeiro, o robô desperdiça sua própria "capacidade cerebral" (recursos computacionais e tokens). Segundo, e mais importante, um humano tem que parar o que está fazendo, ler o trabalho bagunçado do robô, perceber que está errado e escrever um comentário explicando o porquê. Isso é tempo humano desperdiçado.
Os pesquisadores analisaram 306 dessas propostas rejeitadas para descobrir exatamente por que os humanos disseram "Não". Eles encontraram quatro razões principais para a rejeição:
1. A "Ferramenta Errada para o Trabalho" (Problemas de Implementação)
Às vezes, o robô tenta corrigir o problema, mas usa a abordagem errada.
- A Analogia: Imagine que seu carro não liga. Você pede a um mecânico para consertá-lo. Ele aparece e tenta consertar o rádio em vez do motor, ou tenta consertar o motor com um martelo em vez de uma chave de fenda.
- O que aconteceu: Os robôs frequentemente entenderam mal as instruções, consertaram a coisa errada ou propuseram uma solução que era tecnicamente impossível ou incompleta.
2. O "Teste Quebrado" (Problemas Técnicos)
No desenvolvimento de software, antes de uma correção ser aceita, ela precisa passar por uma série de testes automatizados (como uma inspeção de segurança).
- A Analogia: O robô constrói uma nova ponte, mas quando o inspetor dirige um caminhonete sobre ela, a ponte desmorona. O robô não verificou se sua própria ponte suportava peso.
- O que aconteceu: O código que os robôs escreveram frequentemente falhou nos "testes de segurança" automatizados (pipelines de CI) ou quebrou outras partes do software que já estavam funcionando.
3. O "Estagiário Fantasma" (Problemas de Provedor)
Às vezes, o robô simplesmente para de funcionar ou é interrompido.
- A Analogia: Você pede ao estagiário para escrever um relatório, mas no meio do caminho, o estagiário sai do prédio, ou a conexão de internet cai, deixando você com uma página em branco.
- O que aconteceu: O próprio serviço de IA travou, o robô sofreu "limitação de taxa" (ficou sem o limite de requisições permitidas) ou a sessão simplesmente morreu antes de concluir o trabalho.
4. A "Correção Inútil" (Problemas de Relevância)
Às vezes, o robô está trabalhando em um problema que não importa mais.
- A Analogia: Você pede ao estagiário para consertar um vazamento na cozinha. Quando o estagiário termina o reparo, a cozinha foi reformada e o vazamento já sumiu, ou alguém já o resolveu com um método melhor.
- O que aconteceu: O problema que o robô estava corrigindo era de baixa prioridade, o problema já havia sido resolvido por outra pessoa, ou o robô ficou ocioso por tanto tempo que o projeto seguiu adiante sem ele.
O "Custo" do Erro
O artigo também mediu quanta "bagunça" os robôs fizeram antes de serem rejeitados.
- Churn de Código: Esta é uma forma elegante de dizer "quanto código foi escrito e depois deletado". Os pesquisadores descobriram que as correções rejeitadas envolveram uma mediana de 81 a 293 linhas de código. Isso é muita digitação para um erro!
- Comentários: Os humanos tiveram que escrever uma média de 1 a 4,5 comentários para explicar por que a correção era ruim. Como quase metade de todas as correções dos robôs são rejeitadas, isso significa que metade de todos os comentários humanos escritos para esses robôs são apenas dizendo: "Não, isso não funciona".
A Conclusão: Como Treinar Melhor os Estagiários
Os autores sugerem que, para parar de perder tempo, os humanos precisam dar instruções melhores aos robôs antes de eles começarem a trabalhar. Especificamente:
- Dê um Mapa: Diga ao robô exatamente como resolver o problema e o que não fazer.
- Prepare o Teste: Diga ao robô como verificar o próprio trabalho para garantir que ele passe nos testes de segurança antes de mostrá-lo ao chefe.
- Escolha os Trabalhos Certos: Não peça ao robô para consertar bugs minúsculos e sem importância que não valem o tempo de revisão humana.
Em resumo: agentes de IA são poderosos, mas no momento, são como estagiários entusiasmados que precisam de instruções muito claras e específicas para evitar desperdiçar o tempo e a energia de todos.
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.