Ask or Assume -- Wann Coding-Agenten nachfragen statt raten sollten
Nicholas Edwards und Sebastian Schuster untersuchen ein Problem, das jeder kennt, der mit Coding-Agenten arbeitet: Was passiert, wenn die Aufgabenstellung unvollstaendig ist? Menschliche Entwickler fragen nach. Aktuelle AI-Agenten raten -- und liegen oft falsch. Das Paper stellt einen Multi-Agent-Ansatz vor, der diese Luecke schliesst und auf SWE-bench Verified die Leistung eines voll spezifizierten Systems nahezu erreicht.
Kernaussagen
Das zentrale Problem: LLM-Agenten sind auf autonome Ausfuehrung optimiert, nicht auf kollaboratives Arbeiten mit unvollstaendigen Informationen. Bei unterspezifizierten Aufgaben auf SWE-bench Verified sinkt die Resolve Rate eines autonomen Agenten auf 54,8%. Der Mensch wuerde an dieser Stelle nachfragen.
Die Loesung ist ein Multi-Agent-Scaffold mit zwei spezialisierten Agenten. Der Intent Agent analysiert kontinuierlich den Konversationsverlauf und erkennt fehlende Informationen, Mehrdeutigkeiten oder implizite Annahmen. Er gibt strukturierte JSON-Entscheidungen aus: Braucht der Agent Klaerung, ja oder nein, und warum. Der Main Agent fuehrt die eigentliche Code-Arbeit aus -- Repositories navigieren, Dateien editieren, Code testen.
Die Entkopplung von Unsicherheitserkennung und Code-Ausfuehrung ist der Schluessel. Ein Einzelagent (UA-Single), der beides gleichzeitig tun muss, erreicht nur 61,2%. Der Multi-Agent-Ansatz (UA-Multi) kommt auf 69,4% -- fast gleichauf mit den 70,8% bei vollstaendig spezifizierten Aufgaben. Der Unterschied ist statistisch nicht signifikant (p=0,458).
Besonders aufschlussreich ist die Kalibrierung: Der Multi-Agent fragt bei einfachen Tasks in 62% der Faelle nach, bei schwierigen Tasks in 79%. Er erkennt also, wann er mehr Kontext braucht. Der Einzelagent zeigt diese Differenzierung kaum (2,4% Unterschied vs. 9,3% beim Multi-Agent). Zudem fragt der Multi-Agent frueh im Prozess (42% der Anfragen im ersten Drittel), waehrend der Einzelagent oft erst spaet bemerkt, dass Informationen fehlen.
Methodik
Die Autoren erstellen eine unterspezifizierte Variante von SWE-bench Verified mit 500 Tasks. Aus den Original-Issues werden kritische Kontextinformationen entfernt -- etwa erwartetes Verhalten, Fehlermeldungen oder Randbedingungen. Der Agent kann diese Informationen durch Nachfragen abrufen; ein Orakel (das originale Issue) liefert die Antworten.
Beide Agenten basieren auf Claude Sonnet 4.5 im OpenHands-Framework. Der Intent Agent erhaelt Zustandszusammenfassungen und gibt strukturierte Entscheidungen aus. Bei erkannter Unterspezifikation wird der Main Agent angewiesen, das Clarify-Tool aufzurufen. Pro Task sind bis zu 100 Iterationen und im Schnitt 3,06 Nachfragen moeglich.
Die Kosten liegen bei 3,50 Dollar pro Task fuer den Multi-Agent-Ansatz gegenueber 1,63 Dollar fuer den autonomen Einzelagenten. Angesichts der 8,2 Prozentpunkte Verbesserung und der eingesparten Debugging-Zeit der Entwickler ein vertretbarer Aufpreis.
Relevanz fuer die Praxis
Dieses Paper veraendert, wie wir ueber Coding-Agenten nachdenken sollten:
Agenten als Kollaborateure statt Automaten. Die Ergebnisse zeigen, dass die beste Strategie nicht maximale Autonomie ist, sondern gezielte Interaktion. Wer heute Coding-Agenten in Workflows einbindet, sollte explizite Rueckfrage-Mechanismen einbauen statt den Agenten alles allein entscheiden zu lassen.
Trennung von Erkennung und Ausfuehrung. Die Architektur-Lektion ist klar: Ein separater Agent fuer Unsicherheitserkennung funktioniert besser als ein Einzelagent, der beides gleichzeitig tun muss. Dieses Muster -- spezialisierte Agenten fuer orthogonale Aufgaben -- ist direkt auf andere Multi-Agent-Architekturen uebertragbar.
Frontier-Modelle koennen Unsicherheit bereits erkennen. Die Faehigkeit zur Selbstkalibrierung ist in aktuellen Modellen vorhanden. Sie wird nur durch die Einzelagent-Architektur unterdrueckt, weil Ausfuehrungslogik und Unsicherheitserkennung um Aufmerksamkeit konkurrieren. Das Multi-Agent-Scaffold gibt der Unsicherheitserkennung den noetigem Raum.