Why Are AI Agent Involved Pull Requests (Fix-Related) Remain Unmerged? An Empirical Study
Deze empirische studie analyseert meer dan 8.000 fix-gerelateerde pull requests van vijf AI-coderingsagenten om vast te stellen dat het falen van testgevallen en dubbele probleemoplossingen de primaire barrières zijn voor het mergen, terwijl build-fouten zeldzaam zijn, waardoor de belangrijkste beperkingen in huidige AI-agenten en richtingen voor het verbeteren van mens-AI-samenwerking bij softwareonderhoud worden benadrukt.
Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer
Stel je een softwareproject voor als een enorme, drukke bouwplaats. De "maintainers" (beheerders) zijn de bouwplaatsmanagers die beslissen welke blauwdrukken gebouwd worden en welke in de prullenbak belanden. Onlangs zijn ze begonnen met het inhuren van AI-agenten (zoals robotische assistenten) om reparatieplannen op te stellen (genaamd "Pull Requests" of PR's) om kapotte onderdelen van het gebouw te repareren.
Dit artikel is als een detectiveverslag dat de vraag stelt: "Hoe vaak worden de reparatieplannen van deze robotische assistenten daadwerkelijk goedgekeurd, en wanneer dat niet gebeurt, waarom?"
Hier is de uitsplitsing van hun bevindingen, met behulp van eenvoudige analogieën:
1. Het Grote Plaatje: Het Succespercentage
De onderzoekers keken naar meer dan 8.000 reparatieplannen ingediend door vijf verschillende soorten AI-robots (OpenAI Codex, GitHub Copilot, Devin, Cursor en Claude Code).
- Het Goede Nieuws: Ongeveer 65% van de tijd zeiden de bouwplaatsmanagers: "Ja, bouw dit!" en voegden de fix toe (merged). De robots doen een behoorlijk goede job.
- Het Slechte Nieuws: Ongeveer 26% van de tijd zeiden de managers: "Nee," en sloten het plan zonder het te bouwen. Een ander 9% zit nog in de wachtkamer, onbeslist.
- De Verschillen tussen de Robots: Niet alle robots zijn gelijk.
- OpenAI Codex is de sterleerling: Het werd 81% van de tijd goedgekeurd.
- Devin had het meeste moeite: Het werd slechts 43% van de tijd goedgekeurd, wat betekent dat meer dan de helft van de reparatieplannen werd afgewezen.
2. De "Waarom": Waarom worden plannen afgewezen?
De onderzoekers groeven diep in de 326 afgewezen plannen om precies te vinden waarom ze faalden. Ze vonden 12 verschillende redenen, die ze in drie hoofdcategorieën hebben onderverdeeld:
A. De "Verkeerde Fix" Problemen (Technische Problemen)
Soms probeert de robot een lek te repareren, maar maakt hij eigenlijk de leiding kapot.
- Testfouten (De meest voorkomende technische reden): De fix van de robot voldeed aan de eigen logica van de robot, maar faalde bij de strikte veiligheidstests van het project. Het is alsof een chef een maaltijd kookt die er geweldig uitziet, maar verschrikkelijk smaakt wanneer de inspecteur (de test suite) het proeft.
- Onvolledige of Verkeerde Fixes: De robot raadde het probleem wel, maar loste het verkeerde ding op, of repareerde slechts de helft ervan.
- Build/Deploy Fouten: Zelden was de fix zo kapot dat het gebouw niet eens geassembleerd kon worden (het kon niet compileren of draaien).
B. De "Slechte Timing" Problemen (Proces Problemen)
Soms is de fix eigenlijk goed, maar is de timing niet goed.
- Iemand anders was de eerste (De #1 reden voor afwijzing): Dit gebeurde in 22% van de gevallen. De robot was hard aan het werk om een gebroken raam te repareren, maar een mens (of een andere robot) had het vijf minuten geleden al gerepareerd. Het plan van de robot werd simpelweg afgewezen omdat het redundant was.
- Inactiviteit: De robot diende een plan in, maar bleef daarna stil. De managers werden ongeduldig tijdens het wachten op een reactie en sloten de ticket.
- Lage Prioriteit: Het probleem dat de robot probeerde te fixen was niet langer belangrijk, of de projectmanagers besloten het te negeren.
C. De "Communicatieprobleem" Problemen
- Geen Review: De robot vroeg om een review, maar er heeft nooit een menselijke manager naar gekeken.
- Stille Afwijzing: Het plan werd gesloten zonder enige uitleg, waardoor de robot (en de onderzoekers) in het duister bleven over waarom het faalde.
3. De "Snelheid" Factor
De onderzoekers maten ook hoe lang het duurde voordat een plan werd goedgekeurd.
- Snelle Merges: Veel goede fixes werden zeer snel goedgekeurd.
- Trage Merges: Sommige duurden lang. Interessant genoeg had de "sterleerling" (OpenAI Codex) de meest consistente en snelste goedkeuringstijden, terwijl anderen veel onvoorspelbaardere wachttijden hadden.
De Kern van het Verhaal
Het artikel concludeert dat hoewel AI-robots steeds beter worden in het schrijven van code, het schrijven van code niet genoeg is.
Om een reparatieplan goedgekeurd te krijgen in de echte wereld, moet de robot:
- De strikte veiligheidstests passeren (en niet alleen maar goed lijken).
- Niet dubbel werk doen dat mensen of andere robots al hebben gedaan.
- Betrokken blijven bij het gesprek met de menselijke managers.
Momenteel liggen de grootste hindernissen er niet in dat de robots niet in staat zijn om code te schrijven; het is eerder dat ze vaak falen bij de tests of te laat zijn omdat anderen hetzelfde probleem al hebben opgelost. De studie suggereert dat voor AI om echt een betrouwbare "virtuele teamgenoot" te worden, het beter moet worden in het begrijpen van de context van het project en de timing van de workflow, en niet alleen in de code zelf.
Verdrinkt u in papers in uw vakgebied?
Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.