← Nieuwste papers
💻 computer science

ChainSWE: Benchmarking Coding Agents on Multi-Bug Software Maintenance

Dit artikel introduceert ChainSWE, de eerste benchmark die is ontworpen om programmeeragenten te evalueren op sequentiële, afhankelijke bugfixes binnen een gedeelde codebase, wat onthult dat de prestaties van agenten significant dalen naarmate de ketenlengte toeneemt in vergelijking met traditionele, geïsoleerde bugfix-evaluaties.

Oorspronkelijke auteurs: Qirui Jin, Lingching Tung, Kenan Li, Qiyang Shi, Yushi She, Huanzhong Jia, Harrison Zhao, Kejing Xia, Zhenbang Du, Yikai Zhang, Jiaxin Pei, Zhenyu Zhang, Zhen Qi, Yuyan Duan, Wenke Lee, Zijian Jin

Gepubliceerd 2026-07-07
📖 5 min leestijd🧠 Diepgaand

Oorspronkelijke auteurs: Qirui Jin, Lingching Tung, Kenan Li, Qiyang Shi, Yushi She, Huanzhong Jia, Harrison Zhao, Kejing Xia, Zhenbang Du, Yikai Zhang, Jiaxin Pei, Zhenyu Zhang, Zhen Qi, Yuyan Duan, Wenke Lee, Zijian Jin

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

Het Grote Idee: Van "Eén keer en Klaar" naar "De Lange Duur"

Stel je voor dat je een team van superintelligente robotmechaniciens inhuurt om een vloot auto's te repareren.

De Oude Manier (Huidige Benchmarks):
Elke keer dat je een monteur een probleem geeft, overhandig je hem een gloednieuwe, perfecte auto. Hij repareert de lekke band, jij controleert zijn werk, en dan stuur je hem naar huis. De volgende dag geef je hem een andere auto met een ander probleem.

  • Het Probleel: Dit test niet of ze goed zijn in het onderhouden van een auto over een langere periode. In de echte wereld krijgen monteurs niet elke dag een nieuwe auto. Ze werken aan dezelfde auto: eerst een lekke band repareren, dan een piepende rem, en daarna een vreemd motorgeluid, allemaal aan hetzelfde voertuig.

De Nieuwe Manier (CHAINSWE):
De onderzoekers hebben een nieuwe test gebouwd genaamd CHAINSWE. In plaats van de monteurs nieuwe auto's te geven, geven ze ze één auto en een lijst van 304 problemen die zich over meerdere jaren hebben voorgedaan.

  • De monteur repareert het eerste probleem.
  • Daarna, zonder de auto te resetten, moet hij het tweede probleem oplossen op basis van de staat van de auto na de eerste reparatie.
  • Dan het derde, enzovoort.

De Twee Manieren waarop Robots Falen

Het onderzoek toonde aan dat wanneer robots proberen een lange lijst problemen op dezelfde code (de "auto") op te lossen, ze twee specifieke soorten fouten maken die ze niet maken bij het oplossen van enkelvoudige problemen:

1. De "Over-Decorateur" Fout (Overshoot)

  • Het Scenario: De robot krijgt de opdracht om een lekkende kraan te repareren. Hij repareert de kraan perfect. Maar in zijn enthousiasme schildert hij ook de keukenkastjes over en vervangt hij de vloertegels, ook al is daar niet om gevraagd.
  • Het Gevolg: Later komt er een mens binnen om een kapotte lichtschakelaar te repareren. Omdat de robot eerder de vloertegels en kastjes heeft veranderd, sluiten de instructies voor de lichtschakelaar niet meer aan. De "extra" arbeid van de robot heeft de volgende taak verpest.
  • In het papier: De robot verandert bestanden die hij niet had mogen aanraken, wat de tests voor toekomstige bugs breekt.

2. De "Half-Af" Fout (Undershoot)

  • Het Scenario: De robot krijgt de opdracht om een lekkende kraan te repareren. Hij realiseert zich dat de kraan zowel een nieuwe leiding als een nieuw ventiel nodig heeft om te werken. Hij vervangt alleen de hendel van de kraan (omdat dat in de notitie stond) en laat de kapotte leiding en het ventiel ongemoeid.
  • Het Gevolg: De kraan lijkt gerepareerd, maar hij lekt nog steeds. Later probeert een mens de waterdruk te regelen. Omdat de robot de leiding eerder niet heeft gerepareerd, faalt de reparatie van de waterdruk volledig.
  • In het papier: De robot repareert het specifieke bestand dat in de bugrapportage wordt genoemd, maar vergeet de ondersteunende bestanden bij te werken die niet expliciet in de bugrapportage werden vermeld, waardoor de code in een defecte staat achterblijft voor de volgende bug.

Wat gebeurde er toen ze de Robots Testten?

De onderzoekers testten 7 verschillende "AI-mechaniciens" (Taalmodellen) met deze nieuwe "Lange Duur"-test.

  • De Resultaten: Wanneer de robots aan enkelvoudige bugs werkten (de oude manier), waren ze vrij goed (ongeveer 60% succes). Maar wanneer ze aan een keten van bugs moesten werken (de nieuwe manier), daalde hun prestatie met wel 70%.
  • De "Kettingreactie": Hoe dieper ze in de lijst met bugs kwamen, hoe slechter ze het deden. Tegen de tijd dat ze de 3e of 4e bug op rij bereikten, faalden ze bijna constant.
  • Waarom? De robots raakten in de war door hun eigen eerdere werk. Ze konden zich niet herinneren welke bestanden ze hadden aangepast, of ze vergaten dat hun eerdere "snelle reparaties" het fundament voor de volgende taak hadden beschadigd.

Hielp "Geheugen" een Stap Verder?

De onderzoekers probeerden de robots te helpen door ze verschillende manieren te geven om te onthouden wat ze hadden gedaan:

  1. Volledig Geheugen: Het lezen van de volledige geschiedenis van alles wat ze ooit hadden gezegd.
  2. Samengevat Geheugen: De robot vragen om een korte samenvatting te schrijven van wat hij eerder heeft gedaan.
  3. Helper-Robots: Een kleine robot gebruiken om het bewerken van bestanden uit te voeren, terwijl de hoofdrobot alleen instructies geeft.

De Verrassing: Geen van deze trucjes hielp echt veel. Sterker nog, de robot vragen om zijn werk samen te vatten of een helper te gebruiken, maakte de situatie vaak slechter. De robots konden de "rommel" die ze in de code hadden veroorzaakt, simpelweg niet aan, ongeacht hoe hard ze probeerden te onthouden.

De Kern van het Verhaal

Het papier concludeert dat we AI-coders momenteel testen alsof het "one-hit wonders" zijn (één ding repareren en weer vertrekken). Maar in de echte wereld is softwareonderhoud een marathon, geen sprint.

Om AI te bouwen die daadwerkelijk software kan onderhouden, moeten we stoppen met het testen op geïsoleerde taken en beginnen met het testen op ketens van taken, waarbij ze te maken krijgen met de rommelige, imperfecte code die ze zelf hebben gecreëerd. Op dit moment worstelen zelfs de slimste AI-modellen om een codebase schoon te houden wanneer ze bug na bug achter elkaar moeten oplossen.

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.

Probeer Digest →