SWE-agent: Wie Interface-Design automatisierte Softwareentwicklung ermöglicht

Letzte Woche habe ich das SWE-bench-Paper gelesen und eine einfache Erkenntnis mitgenommen: Das bloße GPT-4 löst kaum 1,96 % der echten GitHub-Issues. Diese Woche wollte ich der Anschlussfrage auf den Grund gehen – was bewegt diese Zahl tatsächlich? SWE-agent von Yang et al. (NeurIPS 2024) liefert die Antwort, und sie ist täuschend langweilig: bessere Interfaces.

Das Paper

SWE-agent (John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan und Ofir Press; Princeton / Stanford) führt das Konzept eines Agent-Computer-Interfaces (ACI) ein – eine speziell entwickelte Softwareschicht zwischen einem LLM und einer Linux-Umgebung, die nicht für menschliche Benutzer, sondern für die Art und Weise konzipiert ist, wie Sprachmodelle Informationen tatsächlich verarbeiten. Die Behauptung ist, dass das Design dieses Interfaces und nicht das zugrunde liegende Modell der primäre Engpass für autonome Software-Engineering-Agenten ist.

Das System arbeitet mit GitHub-Issues aus dem SWE-bench: Es liest das Issue, navigiert im Repository, lokalisiert den relevanten Code, bearbeitet ihn und führt Tests aus, um den Fix zu verifizieren. Der neuartige Beitrag ist kein neues Modell oder Trainingsverfahren, sondern eine Reihe sorgfältig konzipierter Befehlsprimitive und Feedbackformate, die die Standard-Linux-Shell ersetzen.

Kernideen

• Interface übertrifft die reine Shell um 10,7 Prozentpunkte. Bei einer Ablationsstudie über 300 SWE-bench Lite-Instanzen löst SWE-agent 10,7 Pp. mehr Issues als ein ansonsten identischer Agent in einer nackten Linux-Shell. Das ist der größte Hebel im Paper.
• Datei-Viewer mit 100-Zeilen-Fenstern. Anstatt ganze Dateien per cat auszugeben, zeigt das ACI pro Schritt ca. 100 Zeilen mit Scroll-Befehlen. Zu wenig Kontext (30 Zeilen) kostet 3,7 Pp.; zu viel (die gesamte Datei) führt dazu, dass das Modell den Fokus verliert. Der ideale Bereich ist schmal.
• Ein Linter im Bearbeitungszyklus. Jeder Edit-Befehl führt eine Syntaxprüfung aus, bevor die Änderung übernommen wird. Dies verhindert, dass das Modell in Zuständen mit fehlerhaftem Code stecken bleibt, aus denen man allein durch natürliche Sprache nur schwer entkommt.
• Minimalistische Verzeichnissuche. Anstatt grep -r mit umgebendem Kontext (was das Modell überforderte), liefert das ACI nur eine Liste der passenden Dateinamen zurück. Weniger ist mehr, wenn das Modell entscheiden muss, wo es als Nächstes suchen soll.
• Gesamtergebnis des Benchmarks: 12,47 % auf SWE-bench mit GPT-4 Turbo, im Vergleich zu einem nicht-interaktiven RAG-System mit 3,8 % und 1,96 % für die einfache Retrieval-Baseline aus dem ursprünglichen SWE-bench-Paper. HumanEvalFix erreichte 87,7 %.
• ACI-Design lässt sich verallgemeinern. Eine Cybersecurity-Variante (SWE-agent EnIGMA) wendete dieselbe ACI-Philosophie auf CTF-Herausforderungen an und erreichte 13,5 % – dreimal stärker als bisherige Systeme – durch interaktive Agenten-Tools, die gleichzeitige Shell-Sitzungen verwalten.

Was Bestand hat – und was nicht

Die zentrale Erkenntnis – dass Interface-Design für Agenten ebenso wichtig ist wie Prompt Engineering – ist gut belegt, und ich halte sie für äußerst nützlich. Die Ablationsstudie ist ehrlich: Die Autoren isolieren Komponenten und zeigen, was jede einzelne beiträgt. Der Gewinn von 10,7 Pp. gegenüber der Shell-Baseline ist ein klares Ergebnis, das nicht durch Modellunterschiede erklärt werden kann.

Wovon ich weniger überzeugt bin: dem Benchmark selbst. Das SWE-bench-Testset enthält Issues, die in Komplexität, Mehrdeutigkeit und der Spezifikation des Ziel-Patches enorm variieren. Eine hohe Varianz in der Qualität der Issues bedeutet, dass der Wert von 12,47 % teilweise eine Aussage darüber ist, welche Issues zufällig im Evaluierungsset gelandet sind. Die Autoren merken dies implizit an, indem sie für Ablationsstudien Ergebnisse auf SWE-bench Lite (300 Issues) berichten, aber die Varianz innerhalb dieser Teilmenge ist immer noch hoch.

Die größere Einschränkung ist der Umfang: SWE-bench misst die Lösung einzelner Issues in Isolation. Es gibt kein Sitzungsgedächtnis über Issues hinweg, kein Verständnis der Historie der Codebasis und keine Verfolgung von Abhängigkeiten zwischen mehreren Issues. SWE-Bench Pro (arXiv:2509.16941, 2025) zeigte später, dass selbst Spitzenmodelle unter 25 % fallen, wenn Issues koordinierte Änderungen an mehreren Dateien erfordern – die Leistung nimmt mit steigender Dateianzahl drastisch ab. Das ACI hilft innerhalb eines einzelnen Issues, aber das schwierige Problem ist der langfristige Fall über mehrere Dateien hinweg, für den SWE-agent nie konzipiert wurde.

Es stellt sich auch eine Frage zur Reproduzierbarkeit, auf die ich immer wieder zurückkomme: Die Entscheidungen beim Interface-Design (100-Zeilen-Fenster, minimalistische Suchausgabe) wurden durch iteratives Experimentieren auf dem Trainings-/Dev-Split gefunden. Diese Entscheidungen sind nicht ohne Weiteres auf neue Domänen übertragbar, ohne einen ähnlichen Optimierungsaufwand. Das sind reale Kosten.

Warum das für Finanz-KI wichtig ist

Das ACI-Framing lässt sich direkt auf das Designproblem von Beancount-Agenten übertragen. Ein Beancount-Ledger ist keine Befehlszeile, aber es ist ein strukturiertes Artefakt, das ein Modell lesen, navigieren und beschreiben muss. Die Lektionen sind übertragbar:

• Ein Ledger-Viewer, der jeweils 20–50 Transaktionen anzeigt – mit Scroll- und Filterbefehlen – wird einen Viewer übertreffen, der 10 Jahre Daten auf einmal ausgibt. Ein Überlaufen des Kontextfensters ist derselbe Fehlermodus.
• Ein Schreib-Validator, der die Ausgeglichenheit der doppelten Buchführung und die Existenz von Konten prüft, bevor er einen Eintrag committet, ist das Ledger-Äquivalent zum Linter von SWE-agent. Ohne diesen hat ein Agent, der einen syntaktisch falschen Eintrag erzeugt, keine Möglichkeit zur Korrektur.
• Minimalistische Suche ist wichtig: Die Abfrage „zeige mir alle Transaktionen im Konto X zwischen den Daten Y und Z“ sollte eine kompakte, scannbare Liste zurückgeben, keinen wortreichen Dump mit umgebendem Kontext.

Das Paper setzt auch einen praktischen Benchmark dafür, was man von frühen Versionen eines Beancount-Write-Back-Agenten erwarten kann. Eine Lösungsrate von 12,47 % bei gut definierten GitHub-Issues ist die aktuelle Obergrenze für einen sorgfältig entwickelten Agenten für Einzelaufgaben. Ledger-Write-Back umfasst eine ähnliche Aufgabenstruktur – eine Benutzerabsicht, eine strukturierte Datei, eine erforderliche Ausgabe, ein Verifizierer – und ich würde vergleichbare Raten bei gut definierten Aufgaben erwarten, mit einer deutlichen Verschlechterung bei Workflows über mehrere Einträge und Konten hinweg.

Was man als Nächstes lesen sollte

• MemGPT: Towards LLMs as Operating Systems [arXiv:2310.08560] – Das Kontextmanagement von SWE-agent ist reaktiv (Kürzung bei Überlauf); MemGPT schlägt einen proaktiven, abgestuften Speicher vor, der für Agenten notwendig erscheint, die über mehrjährige Beancount-Ledger urteilen müssen.
• SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks? [arXiv:2509.16941] – Schließt direkt dort an, wo SWE-agent zu kurz greift; die Daten zur Verschlechterung bei mehreren Dateien sind Pflichtlektüre für das Design der Schreibsicherheit in komplexen Ledgern.
• Gorilla: Large Language Model Connected with Massive APIs [arXiv:2305.15334] – Wenn es bei ACI um Interface-Design geht, geht es bei Gorilla um das Abrufen von APIs; beides zusammen ergibt ein vollständigeres Bild davon, wie Agenten Tools zuverlässig auswählen und aufrufen sollten.