💻 computer science

Beyond Final Code: A Process-Oriented Error Analysis of Software Development Agents in Real-World GitHub Scenarios

Deze studie analyseert de procesgerichte fouten van AI-softwareontwikkelingsagenten op GitHub, onthult dat Python-uitvoeringsfouten de oplossingskansen beïnvloeden en identificeert drie bugs in de SWE-Bench-benchmark die de nauwkeurigheid beïnvloeden.

Oorspronkelijke auteurs: Zhi Chen, Wei Ma, Lingxiao Jiang

Gepubliceerd 2026-04-10

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Zhi Chen, Wei Ma, Lingxiao Jiang

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 groep zeer slimme, maar nog jonge software-ontwerpers (we noemen ze "AI-agenten") hebt aangenomen om een enorme, complexe bouwopdracht te voltooien: het repareren van een gebrekkig huis (een softwareproject) op basis van een klachtenformulier (een GitHub-issue).

De meeste mensen kijken alleen naar het eindresultaat: "Is het huis nu wel veilig? Ja of nee?"
De auteurs van dit onderzoek, Zhi Chen en zijn team, zeggen echter: "Wacht even, laten we niet alleen naar het eindproduct kijken, maar naar hoe ze gebouwd hebben. Laten we hun dagboeken, hun foutmeldingen en hun worstelingen bekijken."

Hier is wat ze hebben ontdekt, vertaald naar alledaags taalgebruik:

1. Het Grote Geheim: Het is niet het eindresultaat, maar het proces

Vroeger keken onderzoekers alleen naar of de AI de code correct schreef. Maar in de echte wereld is software bouwen een proces van vallen en opstaan. De AI's proberen, maken fouten, lezen de foutmelding, proberen het opnieuw, en hopen dat het werkt.
De onderzoekers hebben de "trajecten" (de digitale dagboeken) van bijna 4.000 pogingen van 8 top-AI's bestudeerd. Ze wilden weten: Wat gebeurt er als de AI vastloopt? En hoe beïnvloedt dat het eindresultaat?

2. Fouten zijn niet altijd dodelijk, maar veel fouten wel

Stel je voor dat je een auto probeert te repareren.

Eén of twee fouten: Als de AI een paar keer per ongeluk de verkeerde moer vastdraait, kan ze dat vaak wel oplossen. Het eindresultaat is nog steeds goed.
Te veel fouten: Als de AI echter 15 keer per minuut de verkeerde moer vastdraait, raakt ze in paniek. Ze draait te veel schroeven los, maakt de motor te groot, en raakt de weg kwijt.
De conclusie: Hoe meer fouten een AI maakt tijdens het proces, hoe kleiner de kans is dat het eindresultaat werkt. En het ergste? Hoe meer fouten, hoe langer ze erover doen (meer "redeneren"), wat kostbaarder en trager is.

3. De "Grote Boze Wolf" van de fouten

De onderzoekers hebben gekeken welke fouten de AI's het vaakst maken. Het is alsof ze een lijst hebben gemaakt van de meest voorkomende valkuilen in een bouwput:

De "Ik ken die spullen niet"-fout: De AI probeert een gereedschap te gebruiken dat ze niet hebben geïnstalleerd (bijv. ModuleNotFoundError). Dit is heel vaak, maar gelukkig weten ze dit meestal snel op te lossen.
De "Dit past niet"-fout: Ze proberen een vierkante bout in een ronde gat te draaien (TypeError). Ook dit komt vaak voor.
De "Gevaarlijke Val": Er zijn echter fouten waar de AI's echt in vastlopen. Denk aan fouten in de database (waar de gegevens in worden opgeslagen) of systeemfouten (OSError).
- Analogie: Het is alsof de AI probeert een muur te bouwen, maar de fundering is verkeerd. Ze proberen het 10 keer, maar de muur blijft omvallen. Deze fouten zijn het moeilijkst om op te lossen.

4. De "Geheime" fouten die blijven hangen

Soms denkt de AI: "Oké, ik heb het gerepareerd!" en stuurt het resultaat op. Maar in het testlab (de testfase) blijkt dat de fout die ze eerder hadden, nog steeds aanwezig is.
Het is alsof een dokter een patiënt behandelt, denkt dat hij genezen is, maar de patiënt heeft de koorts nog steeds. Deze "sluipende" fouten zijn gevaarlijk omdat ze de AI laten denken dat het werk klaar is, terwijl het niet zo is.

5. De verrassing: Soms is het niet de AI, maar de meetlat!

Dit is misschien wel het meest interessante stukje. Tijdens het onderzoek ontdekten de auteurs 3 fouten in het SWE-Bench-systeem zelf (het systeem dat gebruikt wordt om de AI's te testen).

Analogie: Het is alsof je een sporter laat rennen op een baan, maar de meetlat van de scheidsrechter is verkeerd afgesteld. De sporter loopt perfect, maar de scheidsrechter zegt: "Je hebt verloren!"
De onderzoekers hebben deze fouten gemeld aan de makers van het testsysteem. Een was al vastgezet, de andere twee worden gerepareerd. Dit betekent dat sommige AI's eerder "slecht" werden beoordeeld dan ze eigenlijk waren.

Wat betekent dit voor de toekomst?

De boodschap is duidelijk:

We moeten leren van de fouten, niet alleen van het succes. Als we willen dat AI's betere software bouwen, moeten we ze leren om sneller en slimmer om te gaan met die "geheime" fouten (zoals database-problemen).
Minder fouten = minder energie. Als een AI minder vaak vastloopt en minder vaak hoeft te proberen, verbruikt ze minder energie en kost het minder tijd. Dat is beter voor het milieu en voor onze portemonnee.
Een standaard taal. Nu praten alle AI's in verschillende talen (sommige schrijven hun dagboek in JSON, andere in tekst). Het zou helpen als ze allemaal hetzelfde dagboekformulier gebruikten, zodat we ze makkelijker kunnen vergelijken.

Kortom: Dit onderzoek zegt: "Kijk niet alleen naar de mooie, afgewerkte code. Kijk naar de struikelblokken onderweg. Als we die struikelblokken begrijpen, kunnen we de AI's leren om steviger te lopen."

Probleemstelling

De opkomst van AI-gedreven softwareontwikkelingsagenten (die Large Language Models of LLM's gebruiken) heeft de capaciteit om complexe, repository-niveau taken aan te pakken aanzienlijk verbeterd. Echter, de huidige evaluatiemethoden focussen bijna uitsluitend op de statische analyse van de uiteindelijke code-output (bijv. of de patch de tests bestaat). Dit biedt een beperkt inzicht in het dynamische probleemoplossingsproces van de agenten. Er is een gebrek aan onderzoek naar de fouten die optreden tijdens het iteratieve proces van redeneren, debuggen en aanpassen. Zonder inzicht in deze procesdata is het moeilijk om de echte beperkingen van agenten te begrijpen, hun foutopsporingscapaciteiten te verbeteren of de rekenkosten te optimaliseren.

Methodologie

De auteurs voeren een empirische studie uit op basis van data van het SWE-Bench Verified benchmark, een standaard voor het evalueren van AI-agenten op real-world GitHub-problemen.

Dataset:
- Bron: 500 GitHub-issues uit 12 populaire Python-repositories.
- Agenten: 8 top-rangschikkingen agenten (bijv. W&B Programmer, Blackbox AI, CodeAct) met een oplospercentage tussen de 44% en 65%.
- Data: 3.977 trajectbestanden van de oplossingsfase (solving-phase) en 3.931 logbestanden van de testfase.
Analyse-aanpak:
De studie volgt de workflow van de agenten in twee fasen en beantwoordt vier onderzoeksvragen (RQ's):
1. RQ1 (Exploratie): Analyse van de correlatie tussen het aantal Python-uitvoeringsfouten tijdens het oplossen en de kwaliteit van de uiteindelijke patch (oplospercentage) en het aantal redeneerstappen.
2. RQ2 (Prevalentie): Identificatie van de meest voorkomende fouttypen (bijv. ModuleNotFoundError, TypeError) via regex-parsing van uitvoerlogs.
3. RQ3 (Uitdaging): Bepaling van welke fouten het moeilijkst te herstellen zijn, gemeten aan de hand van recurrentie (hoe vaak dezelfde fout binnen één taak terugkeert).
4. RQ4 (Falen & Cross-Phase): Analyse van waarom patches falen in de testfase en of fouten uit de oplossingsfase onopgelost blijven naar de testfase ("cross-phase errors"). Ook wordt de SWE-Bench-platform zelf gecontroleerd op bugs.

Belangrijkste Bijdragen

Eerste procesgerichte analyse: Dit is het eerste werk dat trajecten van oplossingsfasen en testlogs gezamenlijk analyseert, in plaats van alleen te kijken naar de eindcode.
Identificatie van kritieke fouten: Het paper classificeert fouten in "veelvoorkomende" en "uitdagende" categorieën, wat richtlijnen geeft voor waar agenten moeten worden verbeterd.
Ontdekking van benchmark-bugs: De auteurs vonden drie kritieke bugs in het SWE-Bench-platform die de eerlijkheid en nauwkeurigheid van de evaluatie ondermijnen. Deze zijn gemeld en bevestigd door de beheerders.
Open Science: De datasets en analyse-scripts zijn openbaar gemaakt om transparantie en reproduceerbaarheid te bevorderen.

Resultaten

1. Impact van Fouten op Prestaties (RQ1)

Het voorkomen van een enkele fout heeft geen significante negatieve invloed op het eindresultaat; agenten kunnen vaak leren van feedback.
Echter, een hoge frequentie van fouten correleert sterk met een lager oplospercentage. Taken met 11-15 fouten hebben een oplospercentage van slechts 37,2%, en bij 20+ fouten daalt dit naar 22,6%.
Er is een sterke positieve correlatie ( $r \approx 0,59$ ) tussen het aantal fouten en het aantal redeneerstappen. Meer fouten leiden tot langere, complexere trajecten en hogere rekenkosten.

2. Prevalente Fouttypen (RQ2)
De analyse identificeerde 32 veelvoorkomende fouttypen. De meest voorkomende zijn:

Afhankelijkheidsfouten: ModuleNotFoundError (1053 keer) en ImportError. Dit wijst op problemen met het configureren van de uitvoeringsomgeving.
Type- en Toegangsfouten: TypeError (992 keer) en AttributeError. Dit suggereert tekortkomingen in typebeheer en datastructuur-toegang.
Database-fouten: OperationalError en IntegrityError (vooral in Django en SQLite) komen veel voor en wijzen op gebrek aan domeinkennis over database-integriteit.

3. Uitdagende Fouten (RQ3)
Fouten die binnen één taak herhaaldelijk voorkomen, zijn het moeilijkst op te lossen:

Systeemfouten: OSError heeft het hoogste recurrentiepercentage (71,43%), wat betekent dat agenten moeite hebben met bestandsysteem-interacties.
Database-integriteit: django.db.utils.IntegrityError en sqlite3.IntegrityError hebben ook zeer hoge recurrentiepercentages (~50-57%), wat aangeeft dat SQL-query's en schema-migraties een zwak punt zijn.
Verrassend: ModuleNotFoundError is zeer frequent, maar heeft een lage recurrentie (14%), wat betekent dat agenten deze fouten doorgaans snel kunnen oplossen zodra ze ze tegenkomen.

4. Falen en Cross-Phase Fouten (RQ4)

De meeste onopgeloste taken falen door parsing- of runtime-fouten tijdens het testen, wat suggereert dat agenten de kwaliteit van hun patches verkeerd inschatten en te vroeg stoppen met debuggen.
Cross-phase fouten: Fouten zoals TypeError en ModuleNotFoundError worden soms in de oplossingsfase gezien maar niet opgelost, en verschijnen opnieuw in de testfase.
Platform Bugs: Drie bugs werden gevonden in SWE-Bench:
1. Een taak (astropy-7606) waarbij alle tests slaagden maar de taak onterecht als "niet opgelost" werd gemarkeerd.
2. Twee taken (astropy-8707, astropy-8872) waarbij het opzetten of verzamelen van tests faalde, waardoor een eerlijke evaluatie onmogelijk was.

Significantie en Implicaties

De studie benadrukt dat de huidige focus op "eindcode" onvoldoende is voor het optimaliseren van softwareontwikkelingsagenten.

Verbetering van Agenten: Er is een dringende behoefte aan strategieën voor proactieve foutvoorkoming (bijv. statische analyse vooraf) en geavanceerde foutherstelmechanismen, vooral voor database-integriteit en systeemfouten.
Efficiëntie en Duurzaamheid: Het verminderen van de frequentie van fouten en de daaruit voortvloeiende lange redeneertrajecten is cruciaal voor het verlagen van de rekenkosten en het maken van AI-gedreven ontwikkeling "groener".
Standaardisatie: De auteurs pleiten voor een gestandaardiseerd formaat voor trajectlogs (nu vaak JSON, YAML, Markdown) om toekomstige vergelijkingen en analyses te vergemakkelijken.
Benchmark Betrouwbaarheid: De ontdekking van bugs in SWE-Bench onderstreept het belang van zorgvuldige validatie van evaluatieplatforms in het AI-onderzoek.

Kortom, dit paper verschuift de focus van "werkt de code?" naar "hoe werkt de agent?", waardoor waardevolle inzichten worden verkregen voor het bouwen van robuustere, efficiëntere en betrouwbaardere AI-agenten.