Coding Agents beseitigen keine unklaren Anforderungen. Sie beseitigen die Reibung, an der Unklarheit bisher sichtbar wurde.
„Der Vorgang soll automatisch abgeschlossen werden.“ Auf den ersten Blick ist das eine überschaubare Anforderung: ein paar Bedingungen prüfen, den Status ändern, Folgeprozesse auslösen. Doch wann genau ist ein Vorgang abgeschlossen? Sobald alle internen Schritte erledigt sind oder erst, wenn ein externes System bestätigt hat? Was geschieht, wenn diese Bestätigung ausbleibt, verspätet eintrifft oder einer bereits verarbeiteten Meldung widerspricht? Und darf ein abgeschlossener Vorgang später wieder geöffnet werden?
Ein Coding Agent kann auf all diese Fragen plausible Antworten finden und sie direkt im Code festschreiben. Er kann Zustände modellieren, Timeouts definieren, Fehlerfälle behandeln und passende Tests ergänzen. Kurze Zeit später liegt eine in sich schlüssige Implementierung vor – obwohl die entscheidenden Fragen nie fachlich beantwortet wurden.
Unklare Anforderungen gab es schon immer. Neu ist, dass sie die Umsetzung kaum noch aufhalten. In komplexen Softwaresystemen steckt die Unschärfe selten in komplizierten Sätzen, sondern in kleinen Wörtern wie „automatisch“, „gültig“, „storniert“ oder „abgeschlossen“. Hinter ihnen verbergen sich Zustände, Fristen, Berechtigungen und Folgeprozesse. Wer sie anders auslegt, verändert nicht nur einen Randfall, sondern das Verhalten des gesamten Systems.
Wo Unklarheit früher sichtbar wurde
Der klassische Weg einer Anforderung war lang. Sie wanderte vom Fachbereich über Business-Analyse und Product Owner ins Refinement und schließlich zur Entwicklung. Diese Kette war langsam, teuer und voller Übersetzungsverluste. Jeder Übergang konnte Bedeutung verfälschen – aber er bot zugleich die Chance, einen Widerspruch zu entdecken.
Irgendjemand fragte, was „abgeschlossen“ konkret bedeutet. Jemand anderes bemerkte, dass zwei Regeln nicht zusammenpassen oder dass für einen Ausfall keine Entscheidung existiert. Das geschah weder zuverlässig noch besonders elegant, aber oft früh genug, um die Umsetzung noch anzuhalten. Die vielen Übergaben waren damit nicht nur organisatorischer Ballast. Sie erzeugten Reibung, und an dieser Reibung konnte Unklarheit sichtbar werden.
Genau diese Reibung gerät unter Druck, sobald ein Coding Agent die Strecke vom unscharfen Satz zum funktionierenden Artefakt erheblich verkürzt. Die bestehende Organisation verschwindet dadurch nicht, doch aus einem Ticket wird eine Anweisung; kurze Zeit später stehen Implementierung, Tests und Dokumentation im Pull Request. Der Code wirkt sauber, die Pipeline ist grün und das Ergebnis sieht fertig aus. Dadurch entsteht leicht der Eindruck, die Anforderung müsse ebenso klar gewesen sein wie ihre Umsetzung.
Doch die ungeklärte Frage ist nicht verschwunden. Sie hat lediglich keine Gelegenheit mehr, den Prozess zu unterbrechen. Der Übersetzungsverlust konzentriert sich nun an der Stelle, an der aus dem Ticket eine ausführbare Anweisung wird.
Ein grüner Build beantwortet keine Fachfrage
Natürlich kann ein Agent Rückfragen stellen. Gefährlich wird es dort, wo er genügend Kontext findet, um auch ohne Rückfrage etwas Konsistentes zu bauen. Beim automatischen Abschluss könnte er beispielsweise prüfen, ob alle bekannten Teilschritte erledigt sind, nach einem definierten Timeout den Status ändern und anschließend die vorgesehenen Folgeprozesse starten. Technisch kann das eine saubere Lösung sein.
Offen bleibt trotzdem, wer entschieden hat, dass ein ausgebliebener Teilschritt nach diesem Timeout als erledigt gelten darf. Ebenso ungeklärt ist, wie ein verspätetes Ereignis behandelt wird, ob der Status zurückgesetzt werden darf und ob bereits gestartete Folgeprozesse dann kompensiert werden müssen. Spätestens wenn zwei Systeme unterschiedliche Zustände melden, reicht eine plausible Implementierung nicht mehr aus. Dann braucht es eine bewusste Entscheidung darüber, welches Verhalten gewollt und welches System maßgeblich ist.
In komplexen Systemen muss daher nicht nur das Ergebnis stimmen. Es muss auch nachvollziehbar sein, nach welcher Regel, mit welchem Datenstand und in wessen Verantwortung es entstanden ist. Ein Agent kann seine Annahmen jedoch in Code gießen und anschließend Tests schreiben, die genau diese Annahmen bestätigen. Die grüne Pipeline zeigt dann, dass Code und Tests zueinander passen. Ob beide auf der richtigen fachlichen Entscheidung beruhen, kann sie nicht beantworten.
Genau deshalb sind plausible Annahmen so schwer zu entdecken. Fehlerhafter Code fällt auf; eine falsche fachliche Annahme kann vollständig grün sein. Sie zeigt sich vielleicht erst im Betrieb, wenn ein Ereignis in einer unerwarteten Reihenfolge eintrifft oder ein Folgeprozess nicht mehr rückgängig gemacht werden kann.
Mehr Text ist noch keine Spezifikation
Die naheliegende Reaktion lautet, Entwickler müssten künftig einfach bessere Prompts schreiben. Das greift zu kurz, denn kein Prompt-Trick entscheidet, unter welchen Bedingungen ein Vorgang fachlich abgeschlossen ist.
Entscheidend ist vielmehr, drei unterschiedliche Arten von Lücken auseinanderzuhalten. Manchmal fehlt lediglich Kontext, der sich aus Code, Dokumentation oder Beispielen ergänzen lässt. Manchmal ist eine bestehende Regel mehrdeutig und muss geklärt werden. Und manchmal wurde die notwendige Entscheidung tatsächlich noch nicht getroffen. Dann braucht es jemanden, der dazu berechtigt ist und die Folgen verantwortet. Mehr Text hilft nur, wenn er fehlenden Kontext oder eine bereits getroffene Entscheidung enthält.
Genau darin liegt der bleibende Wert des Requirements Engineering: implizites Wissen sichtbar zu machen, Begriffe zu zerlegen, Widersprüche zu finden und Grenzen sowie Ausnahmen zu benennen. Diese Arbeit wandert nicht einfach vom Product Owner zum Entwickler. Sie rückt näher an den Code – und damit muss deutlicher werden, wer eine Entscheidung treffen darf, worauf sie beruht und wie ihre Wirkung überprüft wird.
Fachbereich, Product und technische Führung können sich deshalb nicht darauf verlassen, dass eine lange Prozesskette offene Fragen irgendwann schon entdecken wird. Wer ein Ticket unverändert in einen Agenten kopiert, hat die Kette nicht sinnvoll verkürzt. Er hat lediglich ihr letztes Missverständnis automatisiert.
Erst klären, dann beschleunigen
Eine gute Spezifikation schreibt dem Agenten nicht jede Klasse und jede Methode vor. Sie grenzt den Raum ab, in dem technische Freiheit erlaubt ist. Beim automatischen Abschluss müssen deshalb zunächst die relevanten Zustände und Ereignisse bekannt sein. Ebenso braucht es Klarheit darüber, welches System und welcher Zeitstand maßgeblich sind, wie widersprüchliche Daten behandelt werden, welche Regel niemals verletzt werden darf und wer die fachliche Entscheidung verantwortet. Erst dann lässt sich auch bestimmen, woran im Betrieb erkennbar ist, dass die Umsetzung tatsächlich trägt.
Die erste Ausgabe eines Coding Agents sollte deshalb häufig noch kein Code sein. Sinnvoller ist zunächst eine Übersicht der Annahmen, die er für die Umsetzung treffen müsste: Was lässt sich aus dem bestehenden System ableiten? Wo widersprechen sich Regeln? Welche Lücke erfordert eine Entscheidung? Und welche falsche Annahme wäre teuer oder nur schwer rückgängig zu machen? Auf diese Weise nutzt man den Agenten nicht nur als ausführendes Werkzeug, sondern auch als Instrument, um Unklarheit sichtbar zu machen, bevor sie sich in der Implementierung verfestigt.
Das ist keine zusätzliche Zeremonie. Für mich beginnt an dieser Stelle die eigentliche Arbeit eines Software Studios: Absicht, Architektur und Umsetzung so miteinander zu verbinden, dass Geschwindigkeit nicht zum Selbstzweck wird. Erst verstehen, dann entscheiden, dann bauen – und anschließend im laufenden System prüfen, ob die Entscheidung trägt.
Coding Agents verändern damit nicht nur, wie schnell Software entsteht. Sie verändern vor allem den Zeitpunkt, an dem eine fachliche Entscheidung sichtbar werden muss. Dafür braucht es keine längeren Prompts, sondern Menschen, die einen scheinbar einfachen Begriff in Zustände, Regeln, Berechtigungen, Ausnahmen und Nachweise zerlegen können, ohne die Verantwortung für das Ergebnis an ihre Formulierung zu delegieren.
In komplexen Systemen war das immer Teil guter Engineering-Arbeit. Neu ist nur der Preis des Weglassens: Was niemand entscheidet, bleibt nicht offen. Es landet als Annahme im Code. Verantworten muss es trotzdem jemand.