SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration

Dit paper introduceert SWE-CI, het eerste repository-level benchmark dat agenten evalueert op hun vermogen om codebases te onderhouden via een continu-integratiecyclus, waardoor de focus verschuift van statische, eenmalige foutoplossing naar dynamische, langetermijnonderhoudbaarheid.

De kern

Stel je voor dat je een gigantisch, levend huis bouwt.

Tot nu toe hebben we de slimste computerprogramma's (de AI-agenten) getest op één specifieke vaardigheid: kunnen ze een gat in de muur dichten als je ze dat één keer vraagt? Als ze dat kunnen, krijgen ze een goed cijfer. Dit is zoals het testen van een metselaar die perfect een baksteen in een gat kan leggen als je hem alleen die ene baksteen geeft.

Maar in het echte leven is bouwen veel lastiger. Je moet niet alleen gaten dichten; je moet het huis jarenlang verbouwen, verdiepingen toevoegen, de keuken verplaatsen en de fundering versterken, terwijl je tegelijkertijd zorgt dat het huis niet instort.

Dit is precies wat het nieuwe onderzoek SWE-CI doet. Het is een nieuwe manier om te testen of AI-programma's echt goede "bouwmeesters" zijn voor de lange termijn, in plaats van alleen maar goede "reparateurs" voor de korte termijn.

Hier is de uitleg in simpele taal:

1. Het oude probleem: De "Snapshot"-valkuil

Vroeger testten we AI met een foto (een snapshot).

• Hoe het werkte: Je gaf de AI een foto van een kapotte deur en vroeg: "Maak dit goed." De AI maakte een oplossing, en als de deur open ging, was het goed.
• Het probleem: De AI kon een "snelle, lelijke oplossing" kiezen. Bijvoorbeeld: hij plakt een stuk tape op de deur. De deur gaat open (test geslaagd!), maar als je morgen een nieuw raam moet inbouwen, zit die tape in de weg en stort alles in. De AI had de test gehaald, maar het huis is nu onveilig voor de toekomst.

2. De nieuwe oplossing: SWE-CI (De "Levende Bouwplaats")

SWE-CI verandert de test. In plaats van één foto, geven we de AI een levende bouwgeschiedenis.

• De Opdracht: We nemen een echt bestaand computerprogramma (zoals een populief appje) uit het verleden (bijvoorbeeld van 2 jaar geleden) en laten de AI het bouwen tot aan de huidige versie.
• De Reis: Dit is geen één-opdracht. Het is een lange reis van 71 stappen (commits) over 233 dagen.
• De Regel: De AI moet elke stap doen, testen, en dan de volgende stap nemen. Als de AI in stap 3 een slechte beslissing neemt (zoals die tape op de deur), wordt stap 4, 5 en 6 steeds moeilijker. Uiteindelijk moet het hele huis (het programma) werken.

3. Hoe werkt de test? (Het Architect-Programmeur Team)

Om dit realistisch te maken, gebruiken de onderzoekers een slim team van twee AI's:

• De Architect: Kijkt naar wat er mis is en zegt: "We moeten een nieuwe trap bouwen." Hij schrijft een plan, maar laat de details over aan de ander.
• De Programmeur: Voert het plan uit. Hij bouwt de trap.
• De CI-Lus (Continuous Integration): Dit is als een kwaliteitscontroleur die elke dag langs komt. Na elke stap van de Programmeur wordt er getest: "Werkt het nog? Zijn er nieuwe gaten ontstaan?" Als er gaten zijn, moet de Architect een nieuw plan maken.

4. De score: "EvoScore" (De Duurzaamheidsmeter)

Hoe weten we of de AI goed is?

• Oude manier: "Heeft hij de test gehaald?" (Ja/Nee).
• Nieuwe manier (EvoScore): "Hoe makkelijk is het om morgen nog iets te bouwen?"
  • Als de AI een mooie, stevige trap bouwt, wordt de score hoger naarmate het project vordert.
  • Als de AI een snelle, lelijke oplossing kiest, wordt de score lager naarmate het project vordert, omdat de volgende bouwer (of de AI zelf in de volgende ronde) vastloopt.

5. Wat hebben ze ontdekt?

De onderzoekers hebben 18 verschillende AI-modellen getest. Hier zijn de belangrijkste lessen:

• AI wordt steeds beter: Nieuwere modellen zijn duidelijk beter in het bouwen van stevige huizen dan oudere modellen.
• Sommige AI's zijn "kortzichtig": Sommige modellen zijn geweldig in het snel dichten van gaten (ze halen de eerste test), maar ze bouwen zo'n rommelige muren dat je na 10 stappen vastloopt. Ze maken "technische schulden" (zoals een huis vol met tape en lijm).
• Het grootste probleem: Regressies: Dit is een technisch woord voor "iets dat eerst werkte, maar nu kapot is". De meeste AI's maken tijdens het lange proces fouten die oude dingen kapot maken. Slechts een paar modellen (zoals de 'Claude Opus' serie) kunnen dit goed voorkomen.

Conclusie

SWE-CI zegt eigenlijk: "Stop met testen of AI's alleen maar goed kunnen repareren. Laten we testen of ze kunnen bouwen en onderhouden zonder het huis in te laten storten."

Het is de verschuiving van: "Kun je dit gat dichten?" naar "Kun je dit huis 100 jaar laten staan terwijl we er elke dag aan werken?"

Dit onderzoek helpt ons te begrijpen welke AI's we kunnen vertrouwen om complexe software voor de lange termijn te bouwen, en welke AI's we beter niet moeten gebruiken voor grote projecten.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het paper "SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration", geschreven in het Nederlands.

1. Het Probleem

Hoewel Large Language Model (LLM)-gebaseerde agenten uitstekende prestaties leveren bij het automatiseren van software-engineeringstaken zoals statische bugfixing (zoals aangetoond door benchmarks als SWE-bench), missen deze benchmarks een cruciaal aspect van de echte wereld: langdurig onderhoud.

• Beperking van bestaande benchmarks: Bestaande evaluaties gebruiken een "snapshot"-paradigma. Een agent krijgt één vereiste en moet één keer een oplossing genereren. Hierbij wordt alleen gekeken naar functionele correctheid op dat ene moment.
• Het realiteitsprobleem: Softwareontwikkeling is een dynamisch proces met complexe requirement-wijzigingen en lange iteraties. Een agent die een "brittle" (kwetsbare) fix hard-codes, kan dezelfde tests slagen als een agent die schone, uitbreidbare code schrijft. Het verschil in onderhoudbaarheid wordt pas zichtbaar wanneer de codebase moet evolueren (nieuwe eisen, interface-wijzigingen).
• Gevolg: Bestaande benchmarks kunnen niet meten of een agent in staat is om codekwaliteit te behouden over een lange periode, noch of eerdere beslissingen technische schuld (technical debt) accumuleren die toekomstige wijzigingen belemmeren.

2. Methodologie: SWE-CI

Om dit gat te overbruggen, stellen de auteurs SWE-CI (SoftWare Engineering – Continuous Integration) voor. Dit is de eerste repository-level benchmark die is gebouwd rondom een Continuous Integration (CI)-lus.

A. Data Curation (Dataverzameling)

De dataset bestaat uit 100 taken, elk afgeleid van echte open-source Python-repositories op GitHub. Het proces omvat vier stappen:

1. Repository Selectie: Repositories die minstens 3 jaar actief worden onderhouden, >500 sterren hebben, configuratiebestanden en unit-tests bevatten, en een permissieve licentie hebben.
2. Commit Span Extractie: Identificatie van maximale subsequenties van commits waarbij de dependencies ongewijzigd blijven. De begin- en eindpunten vormen een paar: een base commit (startpunt) en een oracle commit (doelwit).
3. Omgevingsconstructie: Automatische generatie van Docker-omgevingen en zelfherstellende mechanismen om testomgevingen werkend te houden.
4. Filtering: Selectie van paren met een significante evolutie (gemiddeld 233 dagen, 71 commits, en >500 gewijzigde regels code).

B. Evaluatie-Paradigma: Evolution-Based

In tegenstelling tot statische benchmarks, gebruikt SWE-CI een iteratieve lus:

• Input: Een basiscodebase ($c_0$) en een doelwit ($c^*$).
• Proces: De agent moet de codebase stap voor stap evolueren naar het doelwit door een lus van analyse en codering te doorlopen.
• Agent-Protocol: Er wordt een Architect-Programmer dual-agent workflow gebruikt:
  • Architect: Analyseert de testgaten, identificeert root causes en genereert een high-level requirements document (maximaal 5 dringende eisen per ronde).
  • Programmer: Implementeert deze eisen in de code.
• Doel: De agent moet alle tests van het doelwit laten slagen na een reeks iteraties, waarbij elke iteratie de staat van de codebase beïnvloedt voor de volgende.

C. Metriek: EvoScore

Om onderhoudbaarheid kwantitatief te meten, introduceren de auteurs EvoScore (Evolution Score).

• Normalized Change ($a(c)$): Een asymmetrische metriek die meet hoeveel de agent de kloof tussen de huidige code en het doelwit heeft overbrugd, of hoeveel regressie (broken tests) er is opgetreden.
• Future-Weighted Mean: EvoScore berekent een gewogen gemiddelde van de normalized change over alle iteraties ($N$):
  $$e = \frac{\sum \gamma_i a(c_i)}{\sum \gamma_i}$$
  Waarbij $\gamma \geq 1$. Een hogere $\gamma$ geeft meer gewicht aan latere iteraties. Dit straalt uit dat een echt onderhoudbare codebase makkelijk blijft aanpassen naarmate de evolutie vordert. Agenten die technische schuld opbouwen, zien hun score dalen in latere rondes.

3. Belangrijkste Bijdragen

1. Nieuw Paradigma: SWE-CI verschuift de evaluatie van "functionele correctheid in één keer" naar "langdurige onderhoudbaarheid via een CI-lus".
2. Realistische Dataset: Een benchmark van 100 complexe taken met een gemiddelde evolutiegeschiedenis van 233 dagen en 71 commits, wat veel realistischer is dan statische patches.
3. Dual-Agent Workflow: Een innovatief evaluatieprotocol dat de rolverdeling tussen architect (eisen definiëren) en programmeur (implementeren) nabootst, wat dichter bij professionele softwareteams staat.
4. EvoScore: Een nieuwe metriek die technische schuld en regressie direct bestraft, waardoor het onderscheid tussen kwetsbare en robuuste oplossingen zichtbaar wordt.

4. Resultaten

De auteurs hebben experimenten uitgevoerd met 18 modellen van 8 verschillende providers, verbruikend meer dan 10 miljard tokens.

• Observatie 1 (Voortgang): De code-onderhoudscapaciteiten van LLMs nemen snel toe. Nieuwere modellen (post-2026) scoren significant beter dan hun voorgangers. De Claude Opus-serie en GLM-5 presteren het beste.
• Observatie 2 (Strategische Verschillen): Verschillende providers hebben verschillende prioriteiten.
  • Modellen van MiniMax, DeepSeek en GPT neigen naar lange termijn optimalisatie (hoge scores bij $\gamma > 1$).
  • Modellen van Kimi en GLM neigen naar korte termijn winst (hoge scores bij lage $\gamma$).
  • Dit suggereert verschillen in trainingsstrategieën per provider.
• Observatie 3 (Regressie): Dit is het grootste zwakke punt. De zero-regression rate (percentage samples zonder enige regressie tijdens het hele proces) ligt voor de meeste modellen onder de 0,25. Slechts twee modellen uit de Claude-opus-serie halen >0,5. Dit betekent dat LLMs moeite hebben om tijdens langdurig onderhoud de stabiliteit van bestaande code te behouden; ze breken vaak eerder werkende functionaliteit.

5. Betekenis en Impact

SWE-CI biedt een kritieke nieuwe dimensie voor het evalueren van AI-agenten:

• Diagnostische Waarde: Het onthult dat hoewel LLMs goed zijn in statische bugfixing, ze nog niet betrouwbaar zijn in dynamische, multi-turn onderhoudsscenario's waar technische schuld een rol speelt.
• Toekomstige Richting: De benchmark dwingt onderzoekers en ontwikkelaars om zich te richten op strategieën die technische schuld minimaliseren en codekwaliteit op lange termijn waarborgen, in plaats van alleen het passeren van een test-suite in één keer.
• Industriële Relevantie: Omdat onderhoud 60-80% van de totale softwarekosten uitmaakt, is de evaluatie van onderhoudbaarheid essentieel voor de adoptie van AI in professionele softwareontwikkeling.

Kortom, SWE-CI bewijst dat "werken" niet genoeg is; code moet ook "onderhoudbaar" zijn, en huidige AI-agenten hebben hier nog aanzienlijke moeite mee.