Understanding the Rejection of Fixes Generated by Agentic Pull Requests -- Insights from the AIDev Dataset
Dit artikel analyseert de AIDev-dataset om 14 specifieke redenen te identificeren waarom bijna de helft van de door AI gegenereerde pull requests wordt afgewezen, waarbij deze faalmodi categoriseert om bruikbare richtlijnen te bieden voor het verbeteren van agentprestaties, taakprioritering en integratie in softwareontwikkelingsworkflows.
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 voor dat je een team van supersnelle, hyperenthousiaste robot-stagiairs inhuurt om bugs in je software op te lossen. Je geeft ze een probleem en ze beginnen onmiddellijk te typen, een "Pull Request" bouwen (wat een voorstel is om de code aan te passen).
Dit artikel is eigenlijk een rapportcijfer voor wat er gebeurt wanneer deze robot-stagiairs (specifiek Copilot, Devin, Cursor en Claude) proberen dingen te repareren. De onderzoekers ontdekten een verbijsterende statistiek: bij bijna de helft van de tijd (46,41%) gooit de menselijke baas het werk van de robot in de prullenbak.
Hier is een uitsplitsing van waarom dit gebeurt, met behulp van eenvoudige analogieën:
Het Grote Probleem: De "Verspilde Inspanning"-rekening
Elke keer dat een robot een oplossing genereert die wordt afgewezen, is dat een dubbel verlies. Ten eerste verspilt de robot zijn eigen "hersencapaciteit" (rekenkracht en tokens). Ten tweede, en belangrijker nog, moet een mens stoppen met waar hij mee bezig is, het slordige werk van de robot lezen, beseffen dat het fout is, en een opmerking schrijven om uit te leggen waarom. Dat is verspilde menselijke tijd.
De onderzoekers bekeken 306 van deze afgewezen voorstellen om precies te achterhalen waarom de mensen "Nee" zeiden. Ze vonden vier hoofdoorzaken voor de afwijzing:
1. Het "Verkeerde Gereedschap voor de Klus" (Implementatieproblemen)
Soms probeert de robot het probleem wel op te lossen, maar gebruikt hij de verkeerde aanpak.
- De Analogie: Stel dat je auto niet start. Je vraagt een monteur om het te repareren. Hij komt opdagen en probeert de radio te reparen in plaats van de motor, of hij probeert de motor te repareren met een hamer in plaats van een moersleutel.
- Wat er gebeurde: De robots begrepen de instructies vaak verkeerd, repareerden het verkeerde ding, of stelden een oplossing voor die technisch onmogelijk of incompleet was.
2. De "Kapotte Test" (Technische problemen)
In software moet een fix, voordat deze wordt geaccepteerd, een reeks geautomatiseerde tests doorstaan (zoals een veiligheidsinspectie).
- De Analogie: De robot bouwt een nieuwe brug, maar wanneer de inspecteur er met een vrachtwagen overheen rijdt, stort de brug in. De robot heeft niet gecontroleerd of zijn eigen brug wel gewicht kon dragen.
- Wat er gebeurde: De code die de robots schreven, faalde vaak bij de geautomatiseerde "veiligheidstests" (CI-pipelines) of maakte andere onderdelen van de software die al werkten, kapot.
3. De "Geest-stagiair" (Provider-problemen)
Soms stopt de robot gewoon met werken of wordt hij onderbroken.
- De Analogie: Je vraagt de stagiair om een rapport te schrijven, maar halverwege loopt de stagiair het gebouw uit, of de internetverbinding valt weg, waardoor je met een leeg blad achterblijft.
- Wat er gebeurde: De AI-service zelf crashte, de robot werd "rate-limited" (de limiet van toegestane verzoeken bereikt), of de sessie werd simpelweg afgebroken voordat hij de klus kon klaren.
4. De "Nutteloze Fix" (Relevantieproblemen)
Soms werkt de robot aan een probleem dat niet meer relevant is.
- De Analogie: Je vraagt de stagiair om een lek in de keuken te repareren. Tegen de tijd dat de stagiair de reparatie heeft voltooid, is de keuken gerenoveerd en is het lek verdwenen, of heeft iemand anders het al met een betere methode opgelost.
- Wat er gebeurde: Het probleem dat de robot aan het oplossen was, had een lage prioriteit, het probleem was al door iemand anders opgelost, of de robot zat zo lang ongebruikt, dat het project in de tussentijd is voortgegaan.
De "Kosten" van de Fout
Het artikel mat ook hoeveel "rommel" de robots maakten voordat ze werden afgewezen.
- Code Churn: Dit is een chique manier om te zeggen "hoeveel code er geschreven en daarna weer verwijderd is". De onderzoekers vonden dat afgewezen fixes betrokken bij een mediaan van 81 tot 293 regels code. Dat is veel typwerk voor een fout!
- Reacties: Mensen moesten gemiddeld 1 tot 4,5 reacties schrijven om uit te leggen waarom de fix slecht was. Omdat bijna de helft van alle robot-fixes wordt afgewezen, betekent dit dat de helft van alle menselijke reacties geschreven aan deze robots simpelweg zegt: "Nee, dit werkt niet."
De Les: Hoe de Stagiairs Beter Op te Leiden
De auteurs suggereren dat mensen, om tijdverspilling te voorkomen, de robots betere instructies moeten geven voordat ze aan het werk gaan. Specifiek:
- Geef een Kaart: Vertel de robot precies hoe hij het probleem moet oplossen en wat hij niet moet doen.
- Stel de Test op: Vertel de robot hoe hij zijn eigen werk kan controleren om er zeker van te zijn dat het de veiligheidstests doorstaat voordat hij het aan de baas laat zien.
- Kies de Juiste Klussen: Vraag de robot niet om piepkleine, onbelangrijke bugs te repareren die de menselijke beoordelingstijd niet waard zijn.
Kortom: AI-agenten zijn krachtig, maar op dit moment zijn ze als enthousiaste stagiairs die zeer duidelijke, specifieke instructies nodig hebben om te voorkomen dat ze ieders tijd en energie verspillen.
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.