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

Die Arbeit stellt SWE-CI vor, den ersten Benchmark auf Repository-Ebene, der die Fähigkeiten von KI-Agenten bei der langfristigen Wartung von Codebasen durch den Continuous-Integration-Zyklus bewertet und dabei den Fokus von statischer Ein-Schritt-Funktionalität auf dynamische, nachhaltige Codequalität verlagert.

Das Wesentliche

Hier ist eine einfache Erklärung der Forschungspapier "SWE-CI", als würde man sie einem Freund beim Kaffee erzählen – ohne Fachchinesisch, aber mit ein paar bildhaften Vergleichen.

Das große Problem: Der "Einmal-Koch" vs. Der "Langzeit-Koch"

Stell dir vor, du hast einen Koch (das ist die künstliche Intelligenz, der KI-Agent), der Rezepte schreiben soll.

Bisher haben wir diesen Koch nur getestet, indem wir ihm ein einzelnes Rezept gegeben haben: "Koch eine Suppe, die schmeckt wie diese hier." Wenn die Suppe am Ende schmeckte, bekam er einen Punkt. Das war wie ein Fotografie-Test: Ein einziger Moment, eine einmalige Aufgabe. Das nennt man "statische Reparatur".

Aber im echten Leben ist Softwareentwicklung kein einmaliges Kochen. Es ist eher wie das Betreiben eines großen Restaurants über Jahre hinweg.

• Heute kommt ein Gast und will weniger Salz.
• Nächste Woche will jemand eine neue Zutat hinzufügen.
• Im nächsten Monat muss das Menü komplett umgestellt werden, weil sich die Lieferanten geändert haben.

Das Problem: Ein Koch, der heute eine perfekte Suppe kocht, aber dabei Zutaten verwendet, die morgen nicht mehr verfügbar sind oder die Küche so unordentlich hinterlässt, dass morgen niemand mehr kochen kann – dieser Koch ist im echten Leben wertlos. Bisherige Tests haben das nicht gemessen. Sie haben nur geschaut: "Schmeckt die Suppe jetzt?" Nicht: "Kann man damit auch morgen noch kochen?"

Die Lösung: SWE-CI (Der "Langzeit-Trainings-Parcours")

Die Forscher von der Sun Yat-sen Universität und Alibaba haben sich gedacht: "Lass uns den Koch nicht nur einmal testen, sondern ihn durch ein ganzes Jahr im Restaurant laufen lassen."

Sie haben SWE-CI erfunden. Das ist wie ein Simulations-Training für KI-Köche, das auf dem Prinzip des "Continuous Integration" (kontinuierliche Integration) basiert.

Wie funktioniert das?
Stell dir vor, du hast ein altes Restaurant (den alten Code) und ein modernes, futuristisches Restaurant (den Ziel-Code).

1. Der Start: Die KI bekommt den alten Zustand.
2. Der Loop (Die Schleife): Die KI muss das Restaurant schrittweise umbauen.
   • Sie analysiert, was fehlt.
   • Sie schreibt einen Plan.
   • Sie baut etwas um.
   • Sie testet, ob alles noch funktioniert.
   • Wichtig: Sie macht das nicht einmal, sondern 71 Mal hintereinander über einen Zeitraum von 233 Tagen (in der Simulation).
3. Das Ziel: Am Ende muss das Restaurant so aussehen wie das moderne Ziel-Restaurant, UND es muss während des ganzen Umbaus so funktioniert haben, dass keine Gäste (Tests) vertrieben wurden.

Das Team: Der Architekt und der Handwerker

Damit das funktioniert, haben die Forscher die KI in zwei Rollen aufgeteilt, wie in einem echten Bauprojekt:

1. Der Architekt (Architect Agent):
   • Er schaut sich die Baustelle an und sagt: "Hey, hier fehlt ein Fenster, und die Tür klemmt. Wir müssen das Dach neu planen."
   • Er schreibt keine konkreten Bauanweisungen, sondern ein Ziel-Design. Er sagt: "Wir brauchen mehr Licht."
2. Der Handwerker (Programmer Agent):
   • Er nimmt die Anweisung und baut das Fenster ein. Er entscheidet selbst, welches Glas er nimmt und wie er es montiert.

Diese beiden arbeiten im Kreis: Architekt plant -> Handwerker baut -> Test -> Architekt plant den nächsten Schritt. So wird simuliert, wie echte Software-Teams arbeiten.

Die Bewertung: Der "Zukunftsscore" (EvoScore)

Früher gab es nur "Bestanden" oder "Durchgefallen". Bei SWE-CI gibt es einen neuen Score, den EvoScore.

Stell dir vor, du bewertest einen Schüler nicht nur nach seiner Note im Mathe-Test heute, sondern danach, wie gut er sich in den nächsten 10 Jahren entwickelt.

• Wenn die KI heute eine schnelle, aber "schmutzige" Lösung baut (wie einen Kleber, der hält, aber morgen wieder abfällt), bekommt sie Punkte, verliert aber später, wenn neue Anforderungen kommen.
• Wenn die KI heute sauber und strukturiert baut, hat sie am Anfang vielleicht etwas länger gebraucht, aber später gewinnt sie, weil sie leicht weiterentwickelt werden kann.

Der EvoScore belohnt also diejenigen, die technische Schulden vermeiden. Er fragt: "Wie leicht ist es, an diesem Code in der Zukunft weiterzuarbeiten?"

Was haben sie herausgefunden?

Die Forscher haben 18 verschiedene KI-Modelle getestet (wie Claude, GPT, DeepSeek etc.) und dabei über 10 Milliarden Wörter "verbraucht". Das Ergebnis ist gemischt:

1. Sie werden besser: Die neuen KIs sind deutlich besser als die alten. Sie können nicht nur Fehler reparieren, sondern auch längerfristig planen.
2. Aber sie machen immer noch Fehler: Die meisten KIs sind wie ungeduldige Schüler. Sie wollen das Problem jetzt lösen. Dabei bauen sie oft Dinge ein, die später kaputtgehen.
   • Das "Rückwärts-Problem" (Regression): In über 75% der Fälle haben die KIs beim Umbau versehentlich Dinge kaputt gemacht, die vorher funktioniert haben. Das ist, als würde der Koch beim Hinzufügen von Gewürzen aus Versehen das ganze Essen versalzen.
3. Unterschiedliche Philosophien: Manche KI-Anbieter (wie MiniMax oder GPT) sind eher auf langfristige Stabilität trainiert, andere (wie Kimi) eher darauf, sofortige Ergebnisse zu liefern.

Fazit

SWE-CI ist wie ein neuer, härterer Führerschein für KI-Programmierer. Bisher haben wir nur geprüft, ob sie ein Auto einmal starten können. Jetzt prüfen wir, ob sie ein Auto über Jahre hinweg warten, reparieren und umbauen können, ohne dass es unterwegs liegen bleibt.

Die Nachricht ist: Die KIs werden immer schlauer, aber sie müssen noch lernen, Geduld und Sauberkeit in ihre Arbeit zu investieren, damit sie im echten, chaotischen Alltag von Software-Entwicklung bestehen können.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration" auf Deutsch:

1. Problemstellung

Obwohl Large Language Models (LLMs) und agentenbasierte Systeme in Benchmarks wie SWE-bench beeindruckende Fähigkeiten beim statischen Bug-Fixing und der Einzelfile-Codegenerierung gezeigt haben, besteht eine kritische Lücke in der Evaluierung realer Softwareentwicklung.

• Fehlende Langzeitperspektive: Etablierte Benchmarks nutzen ein „Snapshot-Paradigma" (einmalige Anforderung, einmalige Lösung). Dies erfasst nicht die Realität der Softwareentwicklung, die durch langfristige Wartung, komplexe Anforderungsänderungen und iterative Feature-Entwicklung geprägt ist.
• Unsichtbarkeit von Wartbarkeit: Ein Agent, der einen fragilen, „harten" Fix implementiert, kann denselben Test bestehen wie ein Agent, der sauberen, erweiterbaren Code schreibt. Der Unterschied in der Wartbarkeit zeigt sich erst, wenn der Code weiterentwickelt werden muss (z. B. durch neue Anforderungen oder Schnittstellenänderungen).
• Mangel an dynamischen Metriken: Es fehlt an einem Standard, der bewertet, wie gut Agenten die Codequalität über einen langen Zeitraum hinweg aufrechterhalten können, ohne technische Schulden anzuhäufen oder Regressionen einzuführen.

2. Methodik: SWE-CI Benchmark

Das Paper stellt SWE-CI (SoftWare Engineering – Continuous Integration) vor, den ersten Repository-Level-Benchmark, der auf dem Prinzip des Continuous Integration (CI)-Loops basiert.

A. Datenerstellung (Data Curation)

Der Benchmark besteht aus 100 Aufgaben, die aus echten Python-Repositories stammen (Filterkriterien: >3 Jahre Wartung, >500 Sterne, Lizenzen, Tests).

• Evolutionärer Ansatz: Jede Aufgabe definiert ein Paar aus einem Base Commit (Startzustand) und einem Oracle Commit (Zielzustand).
• Umfang: Im Durchschnitt erstreckt sich jede Aufgabe über 233 Tage und 71 aufeinanderfolgende Commits mit mindestens 500 Zeilen geänderter Quellcode (ohne Tests).
• Umgebung: Für jedes Paar wird ein isoliertes Docker-Umgebungs-Snapshot erstellt, um Reproduzierbarkeit zu gewährleisten.

B. Evaluierungs-Paradigma (Evolution-based Evaluation)

Im Gegensatz zum statischen „One-Shot"-Ansatz nutzt SWE-CI einen iterativen Loop:

1. Dynamische Anforderungsgenerierung: Die Anforderung ($r_i$) wird nicht statisch vorgegeben, sondern dynamisch aus dem aktuellen Codezustand ($c_i$) und dem Zielzustand ($c^*$) abgeleitet.
2. Dual-Agent-Workflow:
   • Architect-Agent: Analysiert Testlücken, identifiziert Fehlerursachen und erstellt ein hochleveliges Anforderungsdokument (max. 5 dringende Anforderungen), das den nächsten Schritt definiert.
   • Programmer-Agent: Setzt die Anforderungen um, plant die Implementierung und schreibt den Code.
3. CI-Loop: Dieser Prozess wiederholt sich über mehrere Runden (bis zu 20 Iterationen), wobei der Code schrittweise vom Base- zum Oracle-Zustand evolviert wird.

C. Metriken

• Normalized Change ($a(c)$): Eine Metrik, die den Fortschritt relativ zum Startzustand ($c_0$) und dem Zielzustand ($c^*$) misst. Sie unterscheidet zwischen Verbesserungen (positiv) und Regressionen (negativ) und normalisiert diese auf eine Skala von -1 bis 1.
• EvoScore (Evolution Score): Die zentrale Metrik für Wartbarkeit. Sie berechnet einen gewichteten Durchschnitt der Normalized Changes über alle Iterationen:
  $$e = \frac{\sum \gamma^i a(c_i)}{\sum \gamma^i}$$
  Dabei ist $\gamma \ge 1$. Ein höheres $\gamma$ belohnt Agenten, die in späteren Iterationen stabil bleiben (langfristige Wartbarkeit), während ein niedrigeres $\gamma$ kurzfristige Erfolge priorisiert. Dies spiegelt die ISO/IEC 25010-Definition von Wartbarkeit wider.

3. Wichtige Beiträge

1. Paradigmenwechsel: SWE-CI ist der erste Benchmark, der die Evaluierung von Code-Generatoren von statischer Korrektheit hin zu dynamischer, langfristiger Wartbarkeit verschiebt.
2. Realistische Simulation: Durch die Nutzung echter Commit-Historien und eines CI-Loops mit dualen Agenten (Architekt/Programmierer) wird der reale Softwareentwicklungsprozess nachgebildet.
3. Neue Metrik (EvoScore): Einführung einer gewichteten Metrik, die technische Schulden und die Fähigkeit zur langfristigen Evolution quantifiziert.
4. Datenbank: Bereitstellung eines hochwertigen Datensatzes mit 100 komplexen, realen Evolutionsszenarien aus 68 verschiedenen Repositories.

4. Ergebnisse (Experimente)

Die Autoren führten Experimente mit 18 Modellen von 8 verschiedenen Anbietern durch (Verbrauch > 10 Milliarden Tokens).

• Fortschritt bei Wartung: Die Fähigkeiten von LLMs zur Code-Wartung entwickeln sich beschleunigt weiter. Neuere Modelle (post-2026) schneiden deutlich besser ab als Vorgänger. Die Claude Opus-Serie und GLM-5 führen das Feld an.
• Unterschiedliche Prioritäten der Anbieter: Die Modelle zeigen unterschiedliche Strategien in Bezug auf den Parameter $\gamma$:
  • Anbieter wie MiniMax, DeepSeek und GPT bevorzugen Modelle, die auf langfristige Stabilität optimiert sind (hohe $\gamma$-Werte).
  • Anbieter wie Kimi und GLM neigen zu kurzfristigen Gewinnen.
  • Qwen, Doubao und Claude zeigen über verschiedene Einstellungen hinweg eine stabile Performance.
• Kritisches Defizit bei Regressionen: Dies ist das wichtigste Ergebnis. Die meisten Modelle erreichen eine Zero-Regression-Rate von unter 0,25. Das bedeutet, dass in über 75 % der Fälle während des langfristigen Wartungsprozesses mindestens ein zuvor bestehender Test fehlschlägt. Nur zwei Modelle der Claude Opus-Serie lagen über 0,5.
  • Fazit: Obwohl LLMs bei einmaligen Aufgaben gut sind, scheitern sie aktuell noch daran, die Codequalität über lange, iterative Phasen ohne das Einführen neuer Fehler (Regressionen) zu stabilisieren.

5. Bedeutung und Ausblick

SWE-CI demonstriert, dass die aktuelle Evaluierung von KI-Agenten für die Softwareentwicklung unvollständig ist. Die Fähigkeit, Code zu schreiben, ist nicht gleichbedeutend mit der Fähigkeit, Code zu warten.

• Diagnostischer Wert: Der Benchmark deckt auf, dass Agenten dazu neigen, technische Schulden anzuhäufen, die in späteren Iterationen katastrophal werden.
• Richtung für die Forschung: Die Ergebnisse zeigen, dass zukünftige Modelle nicht nur auf Korrektheit, sondern explizit auf Stabilität und Vermeidung von Regressionen in dynamischen Umgebungen trainiert werden müssen.
• Industrierelevanz: Da Wartung 60–80 % der Lebenszykluskosten von Software ausmacht, ist die Entwicklung von Agenten, die SWE-CI bestehen, ein entscheidender Schritt hin zu vollautomatisierter, industrieller Softwareentwicklung.