💬 NLP

Dialogue SWE-Bench: A Benchmark for Dialogue-Driven Coding Agents

Dieses Paper führt Dialogue SWE-Bench ein, einen neuartigen Benchmark und einen auf Personas basierenden Benutzersimulator zur Evaluierung der Fähigkeit von Coding-Agenten, Software-Engineering-Probleme durch Dialoge zu lösen, wobei aufgezeigt wird, dass die Dialogfähigkeit eine eigenständige Leistungsdimension darstellt, die nicht zwangsläufig mit der Stärke des Coding-Modells korreliert.

Ursprüngliche Autoren: Brendan King, Jeffrey Flanigan

Veröffentlicht 2026-06-15

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Brendan King, Jeffrey Flanigan

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie versuchen, einen kaputten Toaster zu reparieren.

Der alte Weg (Aktuelle Benchmarks):
Im Moment, wenn wir KI-Coding-Assistenten testen, verhalten wir uns wie ein Roboter, der einem Roboter ein perfektes, 10-seitiges Handbuch gibt. Das Handbuch besagt: „Der Toaster ist defekt, weil das Heizelement locker ist. Bitte ziehen Sie es fest.“ Die KI liest das Handbuch, repariert den Toaster und wir geben ihr einen goldenen Stern.

Das Problem ist: Echte Menschen sprechen nicht so. Wir haben keine perfekten Handbücher. Wir sagen: „Hey, mein Toaster verhält sich seltsam“, und die KI muss fragen: „Macht er ein Geräusch? Raucht er? Was passiert, wenn man den Hebel drückt?“

Der neue Weg (Dialogue-SWEBench):
Dieses Paper stellt ein neues Testfeld namens Dialogue-SWEBench vor. Anstatt der KI ein perfektes Handbuch zu geben, bauen sie eine Simulation auf, in der die KI mit einem „Geister-User“ sprechen muss, um ein echtes Softwareproblem zu lösen.

So haben sie es aufgebaut:

1. Der „Geister-User“-Simulator

Die Forscher haben ein spezielles KI-Programm erstellt, das die Rolle des menschlichen Nutzers übernimmt.

Die Persona: Dieser Geister-User hat eine Persönlichkeit (wie „ängstlich und vorsichtig“ oder „faul und ungeduldig“).
Das Wissen: Der Geister-User kennt die ganze Geschichte des Bugs (wie ein geheimes Skript), aber es ist ihm strengstens untersagt, der KI alles auf einmal zu verraten. Er muss Details erst preisgeben, wenn danach gefragt wird.
Die Selbstkorrektur: Wenn der Geister-User versehentlich etwas Unmögliches sagt (wie „Ich habe den Code gerade eben auf meinem Handy ausgeführt“), fängt sich der Simulator selbst ab, sagt „Hoppla, das kann ich nicht tun“ und schreibt die Nachricht um, um sie realistisch zu gestalten. Dies stellt sicher, dass der Test fair ist.

2. Der Testlauf

In diesem neuen Test kann der KI-Coding-Agent nicht einfach eine Datei ansehen und sie reparieren. Er muss:

Dem vagen Problem des Nutzers zuhören („Mein Code stürzt ab!“).
Klärungsfragen stellen („Welche Fehlermeldung sehen Sie?“).
Die Antwort erhalten.
Den Code reparieren.
Die Reparatur mit dem Nutzer verifizieren.

Wenn die KI versucht, die Antwort zu erraten, ohne zu fragen, oder wenn sie zu viele unnötige Fragen stellt, scheitert sie.

3. Die große Überraschungsentdeckung

Die Forscher haben die klügsten verfügbaren Coding-KIs (wie GPT-5 und andere) in dieser neuen „Chat“-Umgebung getestet. Dabei fanden sie etwas Überraschendes heraus:

Ein großartiger Programmierer zu sein, macht dich nicht automatisch zu einem großartigen Gesprächspartner.

Die „Großhirn“-Falle: Die größten, leistungsfähigsten Modelle (die „Großhirne“) waren im Teil der Konversation tatsächlich schlechter. Sie neigten dazu, zu viele unnötige Fragen zu stellen oder verloren beim Chat-Fluss den Faden.
Der „Klein, aber fein“-Gewinner: Ein etwas kleineres Modell (GPT-5-mini) machte einen besseren Job bei der Konversation und löste mehr Probleme für weniger Geld.
Die Geheimzutat: Die Forscher entwickelten einen neuen Typ von Agenten, der ein „Schema“ verwendet (denken Sie an eine Checkliste oder ein mentales Whiteboard). Während die KI chattet, füllt sie Kästchen auf ihrer Checkliste aus: Was ist der Bug? Was ist das erwartete Ergebnis? Was fehlt noch?
- Dieser „Schema-gestützte“ Agent war am besten darin, Probleme zu lösen, weil er während der Konversation organisiert blieb, anstatt einfach nur zu raten.

4. Das Urteil

Das Paper kommt zu dem Schluss, dass wir Coding-Agenten bisher wie Roboter getestet haben, die alleine in einem Labor arbeiten. Aber in der realen Welt sind sie Teamkollegen, die mit Menschen zusammenarbeiten.

Coding-Skill ≠ Chat-Skill: Ein Modell kann brillant im Schreiben von Code sein, aber schrecklich darin, herauszufinden, was der Mensch eigentlich braucht.
Die Lösung: Um bessere Coding-Assistenten zu erschaffen, müssen wir sie darauf trainieren, bessere Zuhörer und Fragesteller zu sein, nicht nur bessere Programmierer.

Kurz gesagt: Das Paper hat einen „Chat-Simulator“ gebaut, um zu testen, ob Coding-KIs tatsächlich mit Menschen chatten können, um Bugs zu beheben. Sie fanden heraus, dass die größten, teuersten Modelle nicht immer die besten Gesprächspartner sind, und dass es einer KI hilft, eine mentale Checkliste zu nutzen, um Probleme viel besser zu lösen.

Technisches Resümee: Dialogue-SWEBench

Problemstellung

Aktuelle Benchmarks für Coding-Agenten, wie etwa SWE-Bench, evaluieren Systeme in einem vollautonomen Setting, in dem die Agenten zu Beginn eine vollständige und korrekte Problembeschreibung erhalten. Dieser Ansatz versäumt es, die interaktive Natur der realen Softwareentwicklung abzubilden, bei der Nutzer häufig in einen Dialog treten, um Ausgaben des Agenten zu korrigieren, abzulehnen oder zu klären. Studien zeigen, dass Nutzer die Ausgaben von Agenten in 44 % der Fälle korrigieren, während Agenten selten Rückfragen zur Klärung stellen (1–2 %). Darüber hinaus setzen bestehende Benchmarks oft eine perfekte Spezifikation voraus, wohingegen reale Probleme häufig unterbestimmt oder vage sind. Folglich besteht eine signifikante Lücke zwischen aktuellen Evaluationsmetriken und den tatsächlich erforderlichen Fähigkeiten für interaktive, dialoggesteuerte Coding-Agenten.

Methodik

Dialogue-SWEBench Benchmark

Die Autoren führen Dialogue-SWEBench ein, einen Benchmark, der darauf ausgelegt ist, die Fähigkeit von Coding-Agenten zu evaluieren, reale Software-Engineering-Probleme (SWE) strikt durch einen Dialog mit einem Nutzer zu lösen. Der Benchmark wird durch die Reformulierung von Aufgaben aus SWE-Bench Verified erstellt:

Transformation des Inputs: Anstatt den vollständigen Issue-Text als statische Spezifikation bereitzustellen, beginnt die Aufgabe mit einer festen, initialen Nutzeranfrage ( $u_1$ ), die die Intention des Nutzers widerspiegelt, aber entscheidende Details auslässt, die für die Lösung notwendig sind.
Interaktive Schleife: Die Agenten operieren in einer Umgebung, in der sie Standard-Coding-Aktionen ausführen können (Dateien bearbeiten, Tests ausführen) sowie eine neue message_user-Aktion nutzen können. Diese Aktion ermöglicht es dem Agenten, den Nutzer zu befragen und eine simulierte Antwort als Beobachtung zu erhalten.
Terminierung: Die Schleife endet, wenn der Agent eine finish-Aktion ausführt und einen Git-Patch einreicht. Der Erfolg wird dadurch bestimmt, ob der Patch alle zugehörigen Ausführungstests besteht.

Nutzer-Simulator

Um eine getreue und reproduzierbare Evaluierung zu gewährleisten, haben die Autoren einen persona-basierten Nutzer-Simulator unter Verwendung eines quantisierten LLaMa 3.3 70B Modells entwickelt.

Wissensfundierung: Der Simulator ist auf den vollständigen ursprünglichen GitHub-Issue-Text ( $I_{text}$ ) konditioniert, ist jedoch daran gehindert, auf das Code-Repository zuzugreifen oder Code selbst auszuführen. Er muss als ein Nutzer agieren, der das Problem kennt, aber die Lösung nicht implementieren kann.
Selbst-Revisions-Mechanismus: Um Halluzinationen zu verhindern und die Umgebungsvorgaben einzuhalten (z. B. dass der Nutzer keinen Code ausführen kann), nutzt der Simulator einen Selbst-Revisionsschritt. Eine Kandidatenantwort des Nutzers wird generiert, durch dasselbe LLM auf Verstöße (wie das Behaupten, Code ausgeführt zu haben, oder das Verlassen der Rolle) validiert und gegebenenfalls revidiert, bevor sie an den Agenten zurückgegeben wird.
Personas: Um die Dialogdiversität zu erhöhen, wird jedem Problem eine spezifische Nutzer-Persona zugewiesen (z. B. „vorsichtig“, „perfektionistisch“, „pragmatisch“), die den Tonfall und das Verhalten der simulierten Antworten beeinflusst.

Schema-gesteuerter Agent

Die Autoren schlagen einen neuartigen schema-gesteuerten Coding-Agenten vor, um die Dialogleistung zu verbessern. Dieser Agent verwendet Prompts, um eine strukturierte interne Repräsentation (ein „Schema“) des Dialogzustands aufrechtzuerhalten.

Workflow: Der Agent bestimmt zuerst den Typ des Issues (z. B. Bug, Feature) und entwirft ein Schema mit Schlüsseln für kritische Details (z. B. „erwartetes Verhalten“, „Reproduktionsschritte“).
Zustandsverwaltung: Werte werden als UNKNOWN markiert, bis sie diskutiert wurden. Der Agent wird angewiesen, diese Lücken durch Dialoge zu füllen, bevor er mit der Code-Exploration und der Patch-Generierung fortfährt. Diese Struktur ist darauf ausgelegt, den Agenten dazu zu leiten, gezielte, informationssuchende Fragen zu stellen, anstatt Annahmen zu treffen.

Evaluationsmetriken

Lösungsrate (Resolution Rate): Die primäre Metrik ist der Prozentsatz der Dialoge, die in einem Patch resultieren, der alle Ausführungstests besteht.
Dialogqualität: Die Autoren führen automatische Evaluationen für Natürlichkeit (Ease of Understanding) und Kohärenz (logischer Fortschritt zur Lösung) unter Verwendung eines LLM-as-a-Judge (Gemma 4 31B-IT) ein, die gegen menschliche Annotationen validiert wurden.

Zentrale Beiträge

Dialogue-SWEBench: Ein Benchmark-Datensatz, der 500 reale SWE-Probleme in interaktive, dialoggesteuerte Aufgaben transformiert, bei denen Agenten Issues ohne eine vollständige initiale Spezifikation lösen müssen.
Nutzer-Simulator: Ein neuartiger, Open-Source, persona-basierter Simulator mit einem Selbst-Revisions-Mechanismus, um realistische, konform zu den Constraints entwickelte Nutzerantworten für die Online-Evaluierung zu erzeugen.
Schema-gesteuerter Agent: Eine neue Agenten-Architektur, die Dialog-Schemas nutzt, um fehlende Informationen explizit zu verfolgen, was zu einer verbesserten Leistung gegenüber starken Baselines führt.
Automatische Dialog-Evaluation: Ein LLM-as-a-Judge-Framework zur Bewertung der Natürlichkeit und Kohärenz von Coding-Agent-Dialogen.

Ergebnisse

Die Autoren evaluierten modernste Closed-Source-Modelle (GPT-5, GPT-5-mini) und Open-Weight-Modelle (Qwen 3 Coder, Devstral 2 Small) unter Verwendung von drei Agenten-Konfigurationen: OpenHands (Standard), OH Interactive (Baseline für Ambiguitätsauflösung) und ihren vorgeschlagenen Schema-gesteuerten Agenten.

Performance: Der schema-gesteuerte Agent erreichte die höchste durchschnittliche Lösungsrate (46,9 %) über alle Modelle hinweg und übertraf damit OpenHands (32,9 %) und OH Interactive (44,1 %). Dies erreichte er bei den geringsten durchschnittlichen Kosten.
Dialog- vs. Coding-Fähigkeit: Die Ergebnisse zeigen, dass stärkere Coding-Modelle nicht zwangsläufig zu besseren Dialog-Agenten führen. Beispielsweise erreichte GPT-5-mini oft ähnliche oder bessere Lösungsraten als das größere GPT-5, während es nur einen Bruchteil der Kosten verursachte und natürlichere Dialoge produzierte.
Informationssuche: Es gibt eine starke Korrelation zwischen der Anzahl der informationssuchenden Dialogschritte und den Lösungsraten. Der schema-gesteuerte Agent nutzte konsistent mehr informationssuchende Schritte als die Baselines, was entscheidend für den Erfolg war.
Ablationsstudien: Das Entfernen des Nutzer-Simulators (Erzwingen einer Ein-Turn-Lösung) reduzierte die Performance drastisch (z. B. sank GPT-5-mini von 68,0 % auf 40,0 %), was bestätigt, dass Multi-Turn-Dialoge essenziell für die Lösung dieser Aufgaben sind.
Qualitätsanalyse: Während GPT-5 eine hohe Lösungsrate bei schwierigen Aufgaben erzielte, litt es unter niedrigeren Natürlichkeitswerten aufgrund von Verbosität und Repetition. Der schema-gesteuerte Ansatz verbesserte im Allgemeinen die Kohärenz.

Signifikanz

Das Paper argumentiert, dass die Dialogfähigkeit eine eigenständige und derzeit unterstudierte Dimension der Leistung von Coding-Agenten ist. Die Ergebnisse legen nahe, dass die bloße Skalierung von Coding-Modellen oder die Bereitstellung besserer Spezifikationen für den realen Einsatz unzureichend ist. Stattdessen ist die Fähigkeit, einen Multi-Turn-, informationssuchenden Dialog zu führen, ein kritischer Faktor für die Lösung realer Software-Engineering-Probleme. Die Autoren postulieren, dass die zukünftige Forschung die Schnittstelle zwischen Coding- und Dialogfähigkeiten adressieren muss, um Agenten zu bauen, die effektiv mit menschlichen Nutzern kollaborieren können, anstatt lediglich als vollautonome, spezifikationsabhängige Systeme zu operieren.