Agentes de IA no código aberto: uma síntese do MSR 2026

Sumário executivo

Esta síntese integra resultados de 62 artigos publicados no MSR Mining Challenge 2026, analisando as contribuições dos agentes de codificação de IA para software de código aberto. A pesquisa revela um cenário complexo onde os agentes de IA exibem capacidade significativa, mas introduzem desafios distintos em termos de qualidade de código, dinâmica de revisão e padrões de integração. Embora os agentes demonstrem mudanças de código estrutural comparáveis aos humanos em muitos contextos, surgem lacunas críticas no rigor da validação, na acumulação de dívida técnica e no desempenho específico de tarefas.

Importante: Todo este texto foi criado por Claude Cowork e Codex. O procedimento foi o seguinte:

Enviei o prompt inicial ao Codex com GPT-5.4 e esforço de raciocínio alto.
Enviei o mesmo conteúdo ao Claude Opus com esforço de raciocínio alto.
Pedi ao Codex para revisar ambas as sínteses, verificar inconsistências e mesclar as descobertas.

Fiz verificações aleatórias para garantir que as referências apontassem para os artigos corretos. No entanto, este texto pode conter erros ou informações factualmente incorretas. As descobertas correspondem aos meus sentimentos durante a conferência, depois de conversar com tantos autores.

Resumo

Os agentes de codificação de IA já são um grande fenômeno OSS: o conjunto de dados AIDev captura 932.791 pull requests criadas por agentes em 116.211 repositórios e 72.189 desenvolvedores, portanto, essas descobertas refletem o uso no mundo real em escala.
Os PRs criados por agentes são geralmente mais propensos à rejeição do que os PRs humanos, mas a lacuna depende muito mais do tipo de tarefa, do tamanho do PR, das normas do repositório e do agente específico do que apenas da “autoria de IA”.
Documentação, tarefas e pequenas correções de bugs são os pontos de entrada mais seguros para os agentes, enquanto recursos, refatoração, trabalho de desempenho e grandes mudanças de manutenção permanecem muito mais difíceis de serem implementados com sucesso.
A qualidade do código é a maior preocupação a longo prazo: mesmo os PRs de agentes integrados muitas vezes carregam problemas de código, redundância, crescimento de complexidade e manutenção que os revisores nem sempre detectam.
Os testes estão melhorando, mas continuam irregulares. Muitos PRs de agente incluem agora testes e podem alcançar uma cobertura decente, mas os PRs de cobertura zero ainda são comuns e as evidências de validação são muitas vezes mais fracas do que deveriam ser.
Os resultados de segurança são mistos, em vez de uniformemente piores: os agentes podem introduzir falhas graves, como segredos codificados ou injeção de comando, mas em soluções restritas e bem definidas, às vezes podem igualar ou superar os humanos.
A revisão humana ainda está fazendo o verdadeiro trabalho de integração. Os mantenedores muitas vezes precisam restringir o escopo, corrigir problemas de build ou testes e alinhar as mudanças com as expectativas do projeto, especialmente quando os PRs dos agentes são subexplicados.
Os agentes não são intercambiáveis. Codex, Claude Code, Cursor, Devin e Copilot mostram padrões de edição, estilos de comunicação e pontos fortes específicos de tarefas distintos, o que significa que as equipes devem escolher agentes com base no trabalho, em vez de assumir um perfil genérico de “agente de IA”.
A comunicação de pull requests é mais importante do que muitas equipes esperam: descrições fracas, pull requests silenciosas e inconsistência no código da mensagem reduzem substancialmente a probabilidade de mesclagem e retardam a revisão.
A taxa de mesclagem não é suficiente como métrica de sucesso. Para entender se o desenvolvimento de agentes está realmente funcionando, as equipes e os pesquisadores precisam rastrear reversões, referências downstream, correções após o merge e a carga de limpeza humana após a integração.

Contexto do conjunto de dados

O Desafio de Mineração MSR 2026 é baseado no conjunto de dados AIDev, que captura 932.791 pull requests criadas por agentes em 116.211 repositórios e 72.189 desenvolvedores. O conjunto de dados abrange cinco agentes de codificação amplamente estudados: OpenAI Codex, Devin, GitHub Copilot, Cursor e Claude Code [63].

Síntese Temática de Resultados

1. Padrões de aceitação e rejeição de pull requests

PRs gerados por IA são frequentemente mais propensos à rejeição do que códigos de autoria humana, mas o tamanho da lacuna depende fortemente do tipo de tarefa, da dinâmica de revisão e do agente específico, e não apenas da autoria do agente [9, 11, 16]. Implementações incompletas, testes fracos, incompatibilidades de documentação e soluções inadequadas são recorrentes em estudos de rejeição como principais modos de falha para PRs criados por agentes [9, 13, 33]. O tipo de tarefa é um fator dominante de aceitação, com documentação e outras tarefas restritas integrando-se mais facilmente do que recursos, trabalho de desempenho ou grandes mudanças de manutenção, enquanto o tamanho do PR e a revisão antecipada sinalizam ainda mais os resultados [17, 20, 41, 49]. O contexto social e de processo ainda é importante: a reputação do criador, os padrões de engajamento de revisão e se a mesma conta envia e mescla um PR, todos influenciam os resultados, e uma classe restrita, mas importante, de PRs pequenos e focados ainda pode superar os limites de mesclagem automática em repositórios favoráveis [12, 8, 61].

2. Qualidade do código e acumulação de dívida técnica

O código gerado pelo agente apresenta preocupações de qualidade que muitas vezes persistem mesmo após a integração. Análises focadas em build mostram que a maioria das edições de build criadas por agentes são de qualidade neutra, mas problemas nas dependências e manutenção ainda aparecem em uma minoria significativa de casos [4]. PRs silenciosos podem aumentar a complexidade ciclomática e preservar ou aumentar questões de qualidade sem atrair muita discussão, o que sugere que alguma degradação passa despercebida pela revisão [15]. Análises após o merge de PRs de agentes integrados descobrem que os code smells dominam os problemas observados, enquanto os bugs funcionais são menos frequentes, mas mais graves, e estudos separados relatam mais redundância, métodos desnecessários e um ceticismo mais forte do revisor sobre a manutenibilidade no código de autoria do agente [55, 62, 32]. Estudos de dívida técnica e legibilidade sugerem ainda que as mudanças geradas podem trocar a manutenibilidade por conveniência, e reversões posteriores geralmente citam excesso de engenharia, incorreção funcional e problemas de gerenciamento de dependência como razões pelas quais o código do agente não funciona [29, 31, 28].

3. Vulnerabilidades de segurança e perfis de risco

Os resultados de segurança no código gerado pelo agente são mistos, em vez de uniformemente piores ou melhores. Análises focadas na segurança mostram que PRs criados por agentes apresentam fraquezas reais, incluindo credenciais codificadas e injeção de comando, mas o desempenho varia de acordo com tarefa, agente e escopo de mudança, com agentes às vezes superando humanos em pequenas e focadas correções de bugs [25]. Estudos sobre temas de revisão também mostram que as preocupações relacionadas à segurança são mais comuns em PRs rejeitados, e estudos de reversão indicam que as reversões relacionadas à segurança são raras, mas têm um impacto potencialmente alto quando ocorrem [7, 28]. Estudos de comunicação acrescentam que humanos, bots e agentes mencionam identificadores de vulnerabilidade de diferentes maneiras, com menções a agentes comparativamente raras e concentradas em descrições de pull requests, títulos e mensagens de commit, em vez de discussões de revisão mais ricas [56]. Em domínios sensíveis, como repositórios de blockchain, esse quadro misto reforça a necessidade de interpretar a atividade do agente juntamente com a maior consequência da falha [39, 25].

4. Práticas de teste e dinâmica de cobertura

Os testes continuam a ser centrais, mas desiguais em todo o desenvolvimento dos agentes. Estudos em larga escala descobrem que os testes são cada vez mais comuns em PRs criados por agentes, variam de acordo com o agente e o tipo de tarefa, e muitas vezes continuam a evoluir após o envio inicial, em vez de chegarem completos no primeiro patch [44, 57]. As análises de cobertura mostram que os PRs somente com IA podem alcançar uma cobertura diferencial mais alta do que os PRs humanos, ao mesmo tempo que mantêm a qualidade das afirmações amplamente comparável, mas os PRs com cobertura zero permanecem comuns em todos os grupos [58]. Estudos de geração de testes mostram ainda que os testes criados por agentes são frequentemente mais longos e densos nas asserções, mas as análises de falhas revelam que os erros de tempo de execução e de asserção dominam quando esses testes quebram, apontando para um desempenho sintático mais forte do que semântico [60, 46]. A mesma lacuna de validação aparece em trabalhos não funcionais, como a otimização, onde os PRs de desempenho de autoria do agente têm menos probabilidade do que os PRs humanos de incluir evidências de validação explícitas [5].

5. Colaboração e dinâmica de revisão de IA humana

A dinâmica de revisão difere materialmente entre PRs de autoria humana e de agente. Estudos de temas de revisão mostram que o feedback sobre o código de autoria do agente centra-se na correção e na lógica, mas as preocupações com documentação, refatoração, teste, reversão e segurança tornam-se mais proeminentes em PRs rejeitados [7]. Outras análises mostram que os mesmos sinais de revisão não operam de forma idêntica entre PRs humanos e de agentes: a discussão adicional do revisor pode se correlacionar com menores chances de mesclagem para PRs de agentes, e os envios de agentes são mais frequentemente mesclados pela mesma conta que os abriu [8]. A intervenção humana continua a ser importante mesmo quando não é onipresente; os mantenedores frequentemente intervêm para restringir o escopo, reparar testes ou criar problemas e alinhar as mudanças do agente com as expectativas do projeto, enquanto o feedback do revisor-bot parece muito menos decisivo e pode prolongar o tempo de resolução quando o volume de comentários aumenta [27, 40]. A prática de OSS, portanto, ainda reflete a formação de equipes entre humanos e IA, em vez de autonomia direta, com muitos PRs assistidos por IA chegando rapidamente e com pouco feedback explícito, especialmente de contribuidores sem propriedade prévia do código [14].

6. Padrões comportamentais e impressões digitais específicos do agente

Cada agente de IA exibe assinaturas comportamentais distintas que suportam identificação confiável e diferenciação significativa. A impressão digital comportamental pode identificar o agente remetente com 97,2% F1, mostrando que a estrutura do commit, o estilo do corpo do PR e as características do código variam sistematicamente entre as ferramentas [23]. Essas diferenças também são importantes operacionalmente: comparações estratificadas por tarefa e em nível de tarefa mostram que o Codex tem um desempenho consistentemente bom em muitas categorias, enquanto Claude Code, Cursor, Devin e Copilot mostram pontos fortes mais restritos ou compensações distintas em aceitação, volume de revisão e qualidade da mensagem [17, 42]. A análise de patches comportamentais reforça o mesmo ponto, com Claude Code inclinando-se para a reescrita, Devin para edições incrementais, Codex para edições mistas de remodelação e preservação e Copilot para repetição local mais forte [45]. Estudos de CI/CD e auto-merge sugerem ainda que os agentes variam em especialização e sucesso de integração, em vez de se comportarem como uma única classe homogênea [22, 61].

7. Consistência do código da mensagem e qualidade da comunicação

A qualidade da comunicação é um gargalo de integração recorrente para PRs agentes. A inconsistência no código da mensagem aparece em uma minoria pequena, mas consequente, de PRs de autoria do agente e está associada a menor aceitação e tempos de mesclagem muito mais longos, especialmente quando as descrições afirmam trabalho que o código na verdade não implementa [24]. Estudos comparativos também mostram que os agentes escrevem mensagens mais fortes no nível de commit do que resumos no nível de PR, enquanto a legibilidade e a integridade variam de acordo com o tipo de PR e com o estilo de comunicação dos diferentes agentes [6, 47, 34]. Ao mesmo tempo, tanto os PRs humanos quanto os agentes podem mostrar um alto alinhamento semântico entre descrições e diferenças, o que sugere que a dificuldade de revisão é motivada menos pela incompatibilidade de tópicos brutos do que pela fraca explicação e capacidade de revisão de alto nível [43]. Um problema relacionado é o trabalho subexplicado: PRs silenciosos e PRs fracamente fundamentados tornam a revisão mais difícil, e os arquivos de instruções melhoram os resultados apenas de forma inconsistente, a menos que sejam claros, estruturados e suficientemente específicos [15, 52].

8. Integração CI/CD e confiabilidade do sistema de construção

A CI/CD e as mudanças de construção continuam a ser uma área frágil para o desenvolvimento agente. Estudos de fluxo de trabalho mostram que PRs criados por agentes são bem-sucedidos em CI/CD na maioria das vezes, mas a confiabilidade varia de acordo com a tarefa e o idioma, sendo o trabalho de correção de bugs especialmente propenso a falhas [10]. Os agentes modificam as configurações de CI/CD e o YAML do fluxo de trabalho, mas essas alterações são relativamente incomuns e são revisadas com um pouco mais de cautela do que as alterações não CI/CD, mesmo que alguns agentes mostrem especialização de configuração [22]. Estudos de integração contínua acrescentam que os agentes podem resolver falhas muito mais rapidamente do que os humanos, mas também introduzem a maioria das falhas que mais tarde ajudam a corrigir, deixando os mantenedores humanos profundamente envolvidos na estabilização [26]. A análise do código de construção sugere que a maioria das edições de construção criadas por agentes são neutras, mas problemas de dependência e manutenção ainda surgem dentro dos arquivos de construção [4].

9. Variação de desempenho específico do tipo de tarefa e do domínio

A eficácia do agente varia drasticamente entre os tipos de tarefas, o que torna essencial a avaliação baseada no contexto. Estudos estratificados por tarefas mostram uma lacuna de aproximadamente 29 pontos percentuais entre as categorias de tarefas de maior e menor aceitação, com documentação, tarefas e alguns trabalhos de correção chegando mais facilmente do que recursos, testes ou alterações relacionadas ao desempenho [17, 42]. A sensibilidade ao tamanho também difere por tarefa: PRs de correção de bugs toleram mudanças substancialmente maiores do que PRs de recursos antes que a probabilidade de mesclagem caia drasticamente [41]. Estudos de domínio mostram que esses padrões não são uniformes entre os ecossistemas: os projetos Android aceitam PRs de agente com mais frequência do que o iOS, enquanto os repositórios de blockchain mostram aceitação semelhante entre grupos de agentes, mas forte sensibilidade no tempo de resolução para PRs maiores [37, 39]. As tarefas não funcionais sublinham ainda mais a variabilidade, uma vez que os PRs relacionados com o desempenho e a energia são mais difíceis de validar e muitas vezes mais difíceis de fundir do que o trabalho mais rotineiro [5, 35, 59].

10. Experiência do desenvolvedor e atrito de integração

A experiência do desenvolvedor e o contexto do repositório moldam materialmente o custo de trabalhar com agentes de codificação. Os codificadores de baixa experiência enviam PRs maiores que atraem muito mais comentários de revisão, permanecem abertos por muito mais tempo e são aceitos com menos frequência, sugerindo que a assistência da IA pode transferir a carga de verificação para os revisores, em vez de removê-la [38]. Em ambientes de OSS, os PRs assistidos por IA também vêm desproporcionalmente de contribuidores sem propriedade prévia do código e muitas vezes recebem feedback limitado mesmo quando mesclados, o que pode mascarar uma supervisão fraca [14]. A governança do repositório também é importante: o comportamento de mesclagem automática agrupa fortemente no nível do repositório, e repositórios menos maduros ou mais permissivos têm maior probabilidade de permitir que PRs pequenos e focados passem diretamente [61]. Os arquivos de instruções ajudam alguns projetos, mas não resolvem o atrito de integração de maneira confiável, a menos que sejam bem estruturados e mantidos ativamente [52].

11. Refatoração de comportamento e estratégias de modificação de código

Os agentes adotam estratégias de refatoração e modificação que diferem das abordagens humanas de maneiras reconhecíveis. Estudos de refatoração mostram que as refatorações Java criadas por agentes são dominadas por edições relacionadas a anotações, enquanto as refatorações humanas são muito mais diversificadas estruturalmente; apenas o Cursor mostra um aumento estatisticamente significativo nos problemas de refatoração em relação aos desenvolvedores [18]. Estudos de modificação em larga escala acrescentam que as principais diferenças entre PRs de agentes e humanos estão no empacotamento de commits, nos arquivos tocados e nas linhas excluídas, e não apenas no volume total de linhas adicionadas [43]. A análise comportamental de patches complementa isso, mostrando tendências estáveis específicas do agente para reescrita, edição incremental ou repetição local mais forte entre idiomas e tarefas [45].

12. Interação do ecossistema de código e gerenciamento de dependências

Os agentes demonstram um comportamento ecossistêmico relativamente conservador, mas ainda imperfeito. As importações de bibliotecas aparecem em muitos PRs criados por agentes, mas novas adições de dependência são raras, geralmente limitadas em número e muitas vezes fixadas explicitamente na versão, sugerindo que os agentes trabalham com mais frequência em ecossistemas de projetos existentes do que os expandem agressivamente [3]. Mesmo assim, os problemas de gerenciamento de dependências continuam sendo um modo de falha importante e contribuem materialmente para reversões posteriores [28]. Essa combinação aponta para um fluxo de trabalho onde os agentes geralmente evitam mudanças agressivas no ecossistema, mas ainda lutam com compatibilidade e integração quando tocam em dependências [3, 28].

13. Padrões de clonagem de código e comportamento de reutilização

Os padrões de reutilização de código mostram sobreposições e diferenças importantes entre as contribuições humanas e dos agentes. Em PRs criados por agentes, os clones Tipo III e Tipo I são as formas mais comuns de duplicação, e os clones que persistem em vários commits têm muito mais probabilidade de serem mesclados do que introduções de clones únicos [48]. Em projetos colaborativos, a maioria das genealogias de clones ainda são introduzidas por humanos, mas as linhagens originadas por agentes sobrevivem em taxas aproximadamente semelhantes, o que sugere que a principal diferença reside na manutenção a jusante, em vez da rejeição imediata [54]. Os desenvolvedores humanos frequentemente realizam o trabalho posterior de estabilização e normalização em clones criados por agentes, reforçando o padrão mais amplo de limpeza pós-geração e acompanhamento humano [48, 54].

14. Padrões de adoção de agentes e efeitos de maturidade do repositório

As características do repositório influenciam fortemente a forma como as contribuições dos agentes são integradas e aceitas. Os agentes de codificação produzem os maiores ganhos de rendimento quando introduzidos em repositórios sem ferramentas prévias de IA, enquanto os riscos de manutenção e o crescimento de alertas permanecem visíveis, independentemente da exposição anterior [30]. A maturidade do repositório também molda as normas de integração: o comportamento de mesclagem automática é altamente específico do repositório, com repositórios mais maduros menos propensos a mesclar tudo automaticamente e mais propensos a impor requisitos de revisão consistentes [61]. Os arquivos de instruções acrescentam outra camada de governança, mas os seus benefícios são heterogêneos; apenas uma minoria de projetos mostra fortes melhorias na taxa de merge após adicioná-los, e melhores resultados tendem a aparecer em projetos com instruções mais longas e estruturadas [52].

15. Persistência após o merge e acompanhamento do ciclo de vida

A mesclagem não é o ponto final do trabalho do agente. A análise de referência downstream mostra que apenas 4,2% dos PRs de autoria do agente são referenciados posteriormente, mas 95,62% dessas referências são iniciadas por humanos, que muitas vezes desenvolvem, adaptam ou corrigem o trabalho anterior do agente, em vez de simplesmente aceitá-lo como final [36]. Mesmo após a integração bem-sucedida, 2,66% dos PRs de agente atraem posteriormente a reversão de commits, e estudos após o merge de PRs de correção de bugs mesclados ainda encontram problemas comuns de manutenção, além de bloqueadores funcionais menos frequentes, mas mais graves [28, 55]. As evidências da genealogia dos clones reforçam o mesmo padrão: os humanos frequentemente estabilizam e normalizam os clones criados por agentes ao longo do tempo, o que significa que o valor a longo prazo depende da persistência e do esforço de manutenção posterior, em vez de apenas decisões iniciais de merge [54]. Juntos, esses estudos sugerem que a aceitação é uma métrica de sucesso incompleta e que a avaliação do agente deve rastrear reversões, referências subsequentes, sobrevivência do clone e carga de limpeza após o merge.

Implicações para profissionais

Implementar políticas de revisão consciente do tipo de tarefa: As taxas de aceitação variam 29 pontos percentuais entre categorias de tarefas, sugerindo que fluxos de trabalho de revisão de tamanho único são ineficazes. Os profissionais devem adotar processos de revisão diferenciados, com um escrutínio mais leve para tarefas bem definidas (documentação, correções de bugs) e revisão intensiva para mudanças complexas (refatoração, otimização de desempenho, desenvolvimento de recursos). Na prática, isso significa introduzir agentes primeiro em trabalhos estreitos e com baixo raio de explosão e exigir um exame minucioso adicional para grandes manutenções, alterações sensíveis a alterações de ruptura ou críticas de segurança. Os limites de reconhecimento de tamanho devem variar de acordo com o agente e o tipo de tarefa, uma vez que PRs menores e focados demonstram uma probabilidade de mesclagem substancialmente maior em todos os agentes.
Estabelecer barreiras de qualidade antes do merge: A aceitação silenciosa sem discussão introduz dívida técnica em escala; 56,87% dos PRs silenciosos aumentam a complexidade ciclomática apesar da integração. Implementar verificações de qualidade obrigatórias para PRs de agentes, incluindo análise estática, validação de cobertura de teste (exigindo cobertura diferente de zero) e verificação de consistência de código de mensagem. A comunicação de pull requests também deve fazer parte do padrão de qualidade: as pull requests de autoria do agente devem fornecer um resumo preciso da mudança, a lógica por trás dela e evidências concretas de validação. A lacuna de aceitação de 51,7% e o atraso de mesclagem de 3,5x para PRs de alta inconsistência justificam o investimento em triagem automatizada. As restrições de tamanho devem ser aplicadas contextualmente, com os PRs do Copilot e do Cursor limitados de forma mais agressiva do que as contribuições do Codex devido a janelas terapêuticas distintas.
Selecione agentes com base na especialização da tarefa: Agentes individuais demonstram pontos fortes distintos (Codex em tarefas gerais, Copilot em documentação apesar da maior sobrecarga de revisão, Claude Code em alterações detalhadas de código). Os profissionais devem realizar pilotos em pequena escala para estabelecer métricas de desempenho de base para seus repositórios específicos antes da implantação generalizada. A variação de 29% entre agentes em tipos de tarefas idênticos justifica a seleção de agentes em vez de assumir a intercambialidade.
Priorizar testes e validação de segurança: 62,6% das falhas de testes são erros de tempo de execução que exigem compreensão semântica, e os agentes raramente mencionam identificadores de vulnerabilidade (90 menções versus 2.302 humanas), apesar de gerarem código com lacunas de segurança mensuráveis. Estabelecer a geração de testes suplementares e a verificação de segurança como portas obrigatórias. A taxa de MCI de 1,7% com impacto de aceitação de 51,7% sugere que a verificação da descrição do PR proporcionaria um alto ROI. Para domínios confidenciais (blockchain, código crítico de segurança), o padrão é diminuir os limites de aceitação e exigir validação humana.
Investir em treinamento de desenvolvedores e maturidade de CI/CD: Os codificadores do Vibe enfrentam tempos de resolução 5,16 vezes mais longos, apesar de contribuições 2,15 vezes maiores, indicando lacunas de treinamento. Fornece orientação estruturada sobre práticas de revisão de código, composição de PR e alinhamento com a infraestrutura do projeto. Mantenha um revisor humano responsável por cada alteração criada pelo agente, porque a revisão somente por bot e o feedback automatizado de baixo sinal não são substitutos fortes o suficiente para o julgamento humano quando a correção, a arquitetura ou o contexto de negócios são importantes. A taxa de falha de IC de 27,23% para PRs agentes versus taxa humana de 20,27% reflete oportunidades de ajuste; sistemas CI/CD maduros com ciclos de feedback claros aceleram a integração dos agentes. A maturidade dos repositórios e as estruturas de governança influenciam de forma mensurável a aceitação, sugerindo que os investimentos em infra-estruturas fundamentais geram retornos extraordinários.
Monitorar dívida técnica silenciosa: clones semânticos tipo 4 (1,87x mais altos no código do agente) e acúmulo de redundância ocorrem sem serem detectados quando os revisores se concentram na correção superficial. Implemente auditorias periódicas de qualidade de código visando especificamente padrões introduzidos por agentes e rastreie reversões, hotfixes e limpeza após o merge junto com métricas de dívida técnica em coortes de agentes. A deterioração de 65,1% na manutenibilidade em refatorações focadas na legibilidade sugere que as tentativas de otimização dos agentes muitas vezes saem pela culatra; restringir a autonomia de refatoração a mudanças bem definidas com validação explícita de melhoria de qualidade.
Definir expectativas claras por meio de diretrizes e ciclos de feedback: Apenas 27,7% dos projetos tiveram melhorias na taxa de mesclagem após adicionar arquivos de instrução, mas aqueles com arquivos maiores (976 palavras) bem estruturados apresentaram ganhos de 20%. Invista em diretrizes abrangentes e ricas em exemplos que descrevam padrões de código esperados, requisitos de teste, restrições de integração, convenções de repositório e prompts específicos de tarefas. Ciclos de feedback claros continuam críticos; a constatação de que 79,1% dos merges bem-sucedidos não apresentam feedback explícito sugere que diretrizes de alta qualidade podem compensar o trabalho de revisão, mas a qualidade da orientação é imensamente importante. As equipes devem, portanto, tratar os arquivos de instruções e orientações relacionadas como ativos de engenharia mantidos, em vez de artefatos únicos.

Implicações para pesquisadores

Desenvolver modelos preditivos para triagem de pull requests de agentes: A previsão antecipada do esforço de revisão (alcançando AUC 0,96 com características estruturais) mostra uma promessa substancial para reduzir a carga do revisor. O trabalho futuro deve estender os modelos de mudanças incompatíveis para prever outras dimensões da complexidade da revisão, incluindo risco de segurança, adequação de testes e impacto na manutenção. Esses modelos devem permanecer atentos às tarefas, separando pequenas correções, documentação, refatoração, testes, CI/CD, manutenção sensível à segurança e trabalho de desempenho, em vez de agrupar tudo em sinais de aceitação agregados. Modelos de previsão multivariados que incorporam tipo de tarefa, identidade do agente, maturidade do repositório e estrutura de mudança poderiam permitir o roteamento automatizado para caminhos de revisão apropriados, reduzindo potencialmente os atrasos de resolução em 5,16x para contribuições complexas.
Investigar as causas raízes da variação do tipo de tarefa: A diferença de 29 pontos percentuais entre as categorias de tarefas com maior e menor aceitação excede enormemente a variação entre agentes, mas permanece pouco compreendida mecanisticamente. Conduza análises detalhadas sobre por que o desenvolvimento de recursos, a refatoração e a otimização de desempenho geram modos de falha distintos. Estudos baseados em hipóteses que comparem as trajetórias de raciocínio dos agentes entre os tipos de tarefas poderiam identificar oportunidades de reciclagem. A análise qualitativa do feedback dos revisores em todas as categorias de tarefas esclareceria se as lacunas de aceitação refletem diferenças genuínas de qualidade ou preconceitos dos revisores.
Projetar estudos de intervenção sobre ferramentas de apoio ao revisor: A lacuna de aceitação de 51,7% e o atraso de 3,5x para PRs com alto ICM sugerem uma oportunidade imediata de pesquisa de intervenção. Teste mecanismos de correção automatizados (sugerindo reescritas de descrição com base em diferenças de código), variações de engenharia de prompts e verificação de descrição post-hoc. Além da consistência do código da mensagem, crie ferramentas voltadas para o revisor que sinalizem a provável carga de revisão, destaquem padrões de mudança arriscados e descubram onde a escassa atenção humana é mais necessária. Experimentos controlados randomizados em repositórios reais estabeleceriam se a melhoria do suporte à revisão e da qualidade da descrição pode preencher lacunas de aceitação. Além disso, investigue se os agentes podem aprender a autoverificar a integridade de sua própria implementação antes do envio.
Estabelecer o acompanhamento longitudinal das métricas da dívida técnica: A análise atual revela padrões imediatos após o merge, mas a carga de manutenção a longo prazo permanece subexplorada. Acompanhe a progressão do code smell, taxas de refatoração, reversões, referências downstream e introdução de defeitos no código contribuído pelo agente durante períodos de 6 a 12 meses. Crie benchmarks e conjuntos de dados complementares para resultados não funcionais e de ciclo de vida, como segurança, alterações significativas, legibilidade, propagação de clones, qualidade de documentação e dívida de manutenção. Investigue se os clones Tipo 4 acumulados e a redundância criam clusters de defeitos duradouros ou se são absorvidos pelos padrões normais de manutenção. A extensão às comparações entre projetos esclareceria se os efeitos da dívida técnica variam de acordo com as características da base de código.
Conduzir estudos de dinâmica de colaboração centrados no ser humano: Pesquisas qualitativas sobre por que o envolvimento do revisor reduz a aceitação de PRs do agente (probabilidades 17,6 vezes menores) podem iluminar a dinâmica fundamental da confiança humana-IA. Estude como os desenvolvedores modelam mentalmente as capacidades dos agentes, quais padrões de feedback melhoram efetivamente as contribuições dos agentes e como as normas da equipe evoluem com a adoção dos agentes. Estudos etnográficos em organizações com diferentes níveis de maturidade de adoção de IA capturariam dinâmicas de transição e identificariam práticas que apoiam uma integração bem-sucedida.
Desenvolver modelos de comportamento e contextualização do agente: A impressão digital existente (pontuação F1 de 97,2% com recursos comportamentais) permite a detecção, mas carece de interpretabilidade. Trabalhos futuros devem criar ontologias de comportamento de agentes explicáveis, mapeando padrões de recursos para decisões de design subjacentes e modos de falha. Os pesquisadores também devem investigar formas mais ricas de fundamentação do projeto, como arquivos de instruções, memória de repositório, convenções de codificação e contexto arquitetônico, e testar quais estratégias de fundamentação melhoram mensuravelmente a capacidade de revisão, correção e manutenção a longo prazo. Essa base poderia permitir modelagem preditiva de comportamento e estruturas de comparação de agentes baseadas em princípios, independentes das taxas brutas de mesclagem.
Projetar estruturas de avaliação para desempenho específico de domínio: As métricas atuais se aplicam amplamente, mas ignoram as restrições de domínio; O desenvolvimento blockchain, móvel, crítico para a segurança e consciente da energia apresenta desafios distintos. Desenvolva rubricas de avaliação específicas de domínio, capturando critérios de aceitação técnicos e contextuais, e vincule essas rubricas a benchmarks mais amplos que medem o comportamento não funcional e do ciclo de vida, em vez de apenas a taxa de mesclagem. Pesquise se os agentes têm sucesso diferente em domínios especializados e se a solicitação ou o ajuste fino com reconhecimento de domínio melhoram os resultados. Estudos longitudinais em ecossistemas especializados (blockchain, estruturas de segurança) esclareceriam se os agentes de uso geral podem atender a requisitos específicos de domínio ou exigir especialização.

Referências

From Industry Claims to Empirical Reality: An Empirical Study of Code Review Agents in Pull Requests — Kowshik Chowdhury, Dipayan Banik, K M Ferdous, Shazibul Islam Shamim
When AI Teammates Meet Code Review: Collaboration Signals Shaping the Integration of Agent-Authored Pull Requests — Costain Nachuma, Minhaz F. Zibran
A Study of Library Usage in Agent-Authored Pull Requests — Lukas Twist, Jie M. Zhang
AI Builds, We Analyze: An Empirical Study of AI-Generated Build Code Quality — Anwar Ghammam, Mohamed Almukhtar
How Do Agents Perform Code Optimization? An Empirical Study — Huiyun Peng, Antonio Zhong Qiu, Ricardo Andrés Calvo Méndez, Kelechi G. Kalu, James C. Davis
Code Change Characteristics and Description Alignment: A Comparative Study of Agentic versus Human Pull Requests — Dung Pham, Taher A. Ghaleb
Understanding Dominant Themes in Reviewing Agentic AI-authored Code — Md. Asif Haider, Thomas Zimmermann
Let’s Make Every Pull Request Meaningful: An Empirical Analysis of Developer and Agentic Pull Requests — Haruhiko Yoshioka, Takahiro Monno, Haruka Tokumasu, Taiki Wakamatsu, Yuki Ota, Nimmi Weeraddana, Kenichi Matsumoto
Do AI-Generated Pull Requests Get Rejected More? (Yes but Why?) — Yiru Wang, Zhou Yang
Reliability of AI Bots Footprints in GitHub Actions CI/CD Workflows — Syed Muhammad Ashhar Shah, Sehrish Habib, Muizz Hussain, Maryam Abdul Ghafoor, Abdul Ali Bangash
Bug-Fixing in the Age of AI: Human vs. Agentic Pull Requests — Renato Domingues, Fernando Castor, Fernanda Madeiral
Why and When Agentic Pull Requests are (not) Accepted: An Exploratory Study — Strauss Marius Christoph, Schulze Sandro
When Bots Get the Boot: Understanding PR Rejections in the Era of AI Coders — Karla Gonzalez, Mariam El Mezouar
On Autopilot? An Empirical Study of Human-AI Teaming and Review Practices in Open Source — Haoyu Gao, Peerachai Banyongrakkul, Hao Guan, Mansooreh Zahedi, Christoph Treude
The Quiet Contributions: Insights into AI-Generated Silent Pull Requests — S. M. Mahedy Hasan, Md Fazle Rabbi, Minhaz Zibran
Why Are Agentic Pull Requests Accepted or Rejected? An Empirical Study — Sien Reeve Peralta, Fumika Hoshi, Hironori Washizaki, Naoyasu Ubayashi, Inase Kondo, Yoshiki Higo, Hiroki Mukai, Norihiro Yoshida, Kazuki Kusama, Hidetake Tanaka, Youmei Fan
Comparing AI Coding Agents: A Task-Stratified Analysis of Pull Request Acceptance — Giovanni Pinna, Jingzhi Gong, David Williams, Federica Sarro
How do Agents Refactor: An Empirical Study — Lukas Ottenhof, Daniel Penner, Abram Hindle, Thibaud Lutellier
Mining Type Constructs Using Patterns in AI-Generated Code — Imgyeong Lee, Tayyib Ul Hassan, Abram Hindle
Where Do AI Coding Agents Fail? An Empirical Study of Failed Agentic Pull Requests in GitHub — Ramtin Ehsani, Sakshi Pathak, Shriya Rawal, Abdullah Al Mujahid, Mia Mohammad Imran, Preetha Chatterjee
When is Generated Code Difficult to Comprehend? Assessing AI Agent Python Code Proficiency in the Wild — Nanthit Temkulkiat, Chaiyong Ragkhitwetsagul, Morakot Choetkiertikul, Ruksit Rojpaisarnkit, Raula Gaikovina Kula
When AI Agents Touch CI/CD Configurations: Frequency and Success — Taher A. Ghaleb
Fingerprinting AI Coding Agents on GitHub — Taher A. Ghaleb
Analyzing Message-Code Inconsistency in AI Coding Agent-Authored Pull Requests — Jingzhi Gong, Giovanni Pinna, Yixin Bian, Jie M. Zhang
When AI Writes Code: Investigating Security Issues in Agentic Software Changes — Esteban Dectot-Le Monnier de Gouville, Mohammad Hamdaqa, Moataz Chouchen
On the Reliability of Agentic AI in Continuous Integration Pipelines — Jasem Khelifi, Mahi Begoug, Ali Ouni, Mohammed Sayagh, Mohamed Aymen Saied, Moataz Chouchen
Behind Agentic Pull Requests: An Empirical Study on Developer Interventions in AI Agent-Authored Pull Requests — Syrine Khelifi, Ali Ouni, Maha Khemaja
When AI Code Doesn’t Stick: An Empirical Study on Reverted Changes Introduced by AI Coding Agents — Issam Oukhay, Mahi Begoug, Moataz Chouchen, Ali Ouni
Characterizing Self-Admitted Technical Debt Generated by AI Coding Agents — Zaki Brahmi, Ali Ouni, Mohammed Sayagh, Mohamed Aymen Saied
AI IDEs or Autonomous Agents? Measuring the Impact of Coding Agents on Software Development — Shyam Agarwal, Hao He, Bogdan Vasilescu
Do AI Agents Really Improve Code Readability? — Kyogo Horikawa, Kosei Horikawa, Yutaro Kashiwa, Hidetake Uwano, Hajimu Iida
What to Cut? Predicting Unnecessary Methods in Agentic Code Generation — Kan Watanabe, Tatsuya Shirai, Yutaro Kashiwa, Hajimu Iida
Understanding the Rejection of Fixes Generated by Agentic Pull Requests - Insights from the AIDev Dataset — Mahmoud Abujadallah, Ali Arabat, Mohammed Sayagh
How AI Coding Agents Communicate: A Study of Pull Request Characteristics and Human Review Responses — Kan Watanabe, Rikuto Tsuchida, Takahiro Monno, Bin Huang, Kazuma Yamasaki, Youmei Fan, Kazumasa Shimari, Kenichi Matsumoto
How Do Agentic AI Systems Deal With Software Energy Concerns? A Pull Request-Based Study — Tanjum Motin Mitul, Md. Masud Mazumder, Md Nahidul Islam Opu, Shaiful Chowdhury
Humans Integrate, Agents Fix: How Agent-Authored Pull Requests Are Referenced in Practice — Islem Khemissi, Moataz Chouchen, Dong Wang, Raula Gaikovina Kula
On the Adoption of AI Coding Agents in Open-source Android and iOS Development — Muhammad Ahmad Khan, Hasnain Ali, Muneeb Rana, Muhammad Saqib Ilyas, Abdul Ali Bangash
Novice Developers Produce Larger Review Overhead for Project Maintainers while Vibe Coding — Syed Ammar Asdaque, Imran Haider, Muhammad Umar Malik, Maryam Abdul Ghafoor, Abdul Ali Bangash
Studying the Footprints of AI Coding Agents in Blockchain Repositories — Munim Iftikhar, Maaz Shahid, Shahreyar Ashraf, Muhammad Saqib Ilyas, Abdul Ali Bangash
On the Footprints of Reviewer Bots’ Feedback on Agentic Pull Requests in OSS GitHub Repositories — Syeda Kaneez Fatima, Yousuf Abrar, Abdul Rehman Tahir, Amelia Nawaz, Shamsa Abid, Abdul Ali Bangash
The Dose Makes the Agent: Therapeutic Index Analysis of AI Coding Contributions — Giuseppe Destefanis, Ronnie de Souza Santos, Marco Ortu, Mairieli Wessel
A Task-Level Evaluation of AI Agents in Open-Source Projects — Shojibur Rahman, Md Fazle Rabbi, Minhaz Zibran
How AI Coding Agents Modify Code: A Large-Scale Study of GitHub Pull Requests — Daniel Ogenrwot, John Businge
An Empirical Study of Tests in Agentic Pull Requests — Sabrina Haque, Sarvesh Ingale, Christoph Csallner
Behavioral Analysis of AI Code Generation Agents: Edit, Rewrite, and Repetition — Mahdieh Abazar, Reyhaneh Farahmand, Gouri Ginde, Benjamin Tan, Lorenzo De Carli
An Empirical Analysis of Test Failures in AI-Generated Pull Requests — Alireza Hoseinpour, Sajjad Rezvani Boroujeni, Jashhvanth Tamilselvan Kunthavai, Kyle Cusimano, Abbas Heydarnoori
Readability of AI-Generated Pull Request Descriptions Across Pull Request Types — Aidan Tobar, Joseph Peterson, Abbas Heydarnoori
A Study on Code Clone Lifecycles in Pull Requests Created by AI Agents — Italo Uchoa
Early-Stage Prediction of Review Effort in AI-Generated Pull Requests — Duy Minh Dao Sy, Trung Kiet Huynh, Phu Quy Nguyen Lam, Phu Hoa Pham, Chi Nguyen Tran, Dinh Ha Duong Nguyen, Bao Tran Truong
Safer Builders, Risky Maintainers: A Comparative Study of Breaking Changes in Human vs Agentic PRs — K M Ferdous, Dipayan Banik, Kowshik Chowdhury, Shazibul Islam Shamim
Why Are AI Agent–Involved Pull Requests (Fix-Related) Remain Unmerged? An Empirical Study — Khairul Alam, Saikat Mondal, Banani Roy
Toward Instructions-as-Code: Understanding the Impact of Instruction Files on Agentic Pull Requests — Ali Arabat, Mohammed Sayagh
Who Writes the Docs in SE 3.0? Agent vs. Human Documentation Pull Requests — Kazuma Yamasaki, Joseph Ayobami Joshua, Tasha Settewong, Mahmoud Alfadel, Kazumasa Shimari, Kenichi Matsumoto
An Empirical Study of Code Clone Genealogies in Human–AI Collaborative Development — Denis Sousa, Italo Uchoa, Matheus Paixao, Chaiyong Ragkhitwetsagul, Thiago Lima
Beyond Bug Fixes: An Empirical Investigation of Post-Merge Code Quality Issues in Agent-Generated Pull Requests — Shamse Tasnim Cynthia, Al Muttakin, Banani Roy
Who Said CVE? How Vulnerability Identifiers Are Mentioned by Humans, Bots, and Agents in Pull Requests — Pien Rooijendijk, Christoph Treude, Mairieli Wessel
Human-Agent versus Human Pull Requests: A Testing-Focused Characterization and Comparison — Roberto Milanese, Francesco Salzano, Angelica Spina, Antonio Vitale, Remo Pareschi, Fausto Fasano, Mattia Fazzini
Test Coverage of Code Changes in AI-Generated Pull Requests — Tales Vinícius Alves da Cunha, Leopoldo Teixeira
How Do Agentic AI Systems Address Performance Optimizations? A BERTopic-Based Analysis of Pull Requests — Md Nahidul Islam Opu, Shahidul Islam, Muhammad Asaduzzaman, Shaiful Chowdhury
Testing with AI Agents: An Empirical Study of Test Generation — Suzuka Yoshimoto, Shun Fujita, Kosei Horikawa, Daniel Feitosa, Yutaro Kashiwa, Hajimu Iida
LGTM! Characteristics of Auto-Merged LLM-based Agentic PRs — Ruben Branco, Paulo Canelas, Catarina Gamboa, Alcides Fonseca
More Code, Less Reuse: Investigating Code Quality and Reviewer Sentiment towards AI-generated Pull Requests — Haoming Huang, Pongchai Jaisri, Shota Shimizu, Lingfeng Chen, Sota Nakashima, Gema Rodríguez-Pérez
AIDev: Studying AI Coding Agents on GitHub — Hao Li, Haoxiang Zhang, Ahmed E. Hassan

Prompt original (em inglês)

Este foi o prompt inicial usado para gerar o relatório. Outras instruções foram usadas depois para verificar a validade do texto.

In this folder, we have all PDFs of the MSR mining challenge. This year's challenge was to understand code changes done by agentic AI coders. You can read more about it in the website https://2026.msrconf.org/track/msr-2026-mining-challenge?#Call-for-Mining-Challenge-Papers and in dataset.pdf.

You will act as a senior software engineering researcher that will summarize and group the main findings of these papers by themes, similarly to performing a systematic literature review.

Your first task is to go paper by paper, read each of them, and then write a summary about the paper. Each summary must have the following: the title and list of authors, a two paragraph summary of the paper (which you can use the introduction and the conclusions part of the paper), and then a bullet point list with 5 to 7 main findings of the paper (which you can get from the results, findings, and implications sections of the paper). Each paper summary should be stored in a markdown file with the same name of the PDF.

Then, once all summaries are created, you will read all the summaries and analyze their main findings as a whole. You should group the main findings by themes. Each theme must have a bullet point list of the findings. Each finding must be accompanied by the paper that that finding comes from, and if it comes from multiple papers, list all the papers. The citation must be the name of the PDF.

Then, let's write a section called "Implications for Practitioners" with 5-7 recommendations based on these findings. Think of industry developers rather than OSS developers here.

Then, let's write a "Implications for Researchers", looking at all the findings. What type of work can they do to improve the current state of things.

Finally, create a References section at the bottom where you list the name of the pdf and its title and author list. Get them one by one from the summary files.