Ich bin Ralf Enderle und kümmere mich bei eXXcellent solutions um die Rolle von KI in unserem Engineering. Wir stecken gerade mitten in einem Entwicklungsschub, bei dem die Wahrheit von heute übermorgen schon wieder anders aussehen kann. Was ich hier aufschreibe, ist deshalb kein abgeschlossenes Fazit, sondern eine Art Tagebuch: Themen, die mir in unserer Projektpraxis begegnen, und die Gedanken, die ich mir dabei mache. Heut: Unklare Anforderungen gab es schon immer. Neu ist, dass unterwegs immer seltener jemand sitzt, der sie auffängt. Worauf es beim einzelnen Ticket ankommt, wenn Agenten es möglichst autonom umsetzen sollen.
Ein Ticket, wie es in jedem Backlog stehen könnte: „Wird ein Auftrag storniert, bekommt der Kunde eine Benachrichtigung. "Ein Entwickler stutzt hier vermutlich kurz. Welcher Auftrag, die Bestellung oder der Versandauftrag? Welcher Kunde, der Besteller oder der Rechnungsempfänger? Er fragt nach, im Daily oder in der Kaffeeküche, und fünf Minuten später ist die Sache klar.
Ein Agent stutzt nicht. Er nimmt die plausibelste Lesart, setzt sie um, schreibt Tests dazu und meldet das Ticket als erledigt. Die Tests sind grün, prüfen aber genau die Lesart, die der Agent gewählt hat. Ob es die richtige war, zeigt sich erst, wenn jemand mit fachlichem Blick auf das Ergebnis schaut. Im ungünstigen Fall ist das der Kunde. Ein Mensch fragt nach. Ein Agent entscheidet selbst.
Dass Anforderungen früh und klar formuliert sein sollten, ist keine neue Erkenntnis. Bisher gab es allerdings einen Puffer, über den selten gesprochen wird. Zwischen Requirements und Release saßen Menschen. Die Architektin, die im Design merkt, dass zwei Anforderungen nicht zusammenpassen. Der Entwickler, der im Develop hängen bleibt und nachfragt. Die Kollegin im Review, die sagt: „So war das aber nicht gemeint." Unklarheit wurde unterwegs erkannt und aufgelöst, meist ganz nebenbei.
Je autonomer Agenten diese Schritte übernehmen, desto dünner wird der Puffer. Natürlich muss ein agentischer Ablauf mit Unklarheit umgehen können. Ein gut gebauter Agent entscheidet nur in einem gewissen Rahmen selbst und eskaliert an einen Menschen, wenn es darüber hinausgeht. Nur hält jede Eskalation den Ablauf an. Je seltener das nötig ist, desto autonomer kann er laufen, und genau das ist ja das Ziel.
Dazu kommt: Schon die Grenze selbst lässt sich kaum sauber beschreiben. Welche Unklarheit ist eine Rückfrage wert, welche darf der Agent selbst auflösen? Da bleibt immer ein Rest Unsicherheit. Und wo der Agent selbst entscheidet, wählt ein Sprachmodell die statistisch naheliegende Lösung. Die ist schlüssig und sauber umgesetzt, passt aber nicht zwingend zu dem, was gemeint war.
Je mehr Unsicherheit wir vorne ausräumen, desto besser funktioniert alles, was danach kommt.
Das heißt übrigens nicht, dass wir vorne sauber spezifizieren und hinten nur noch abnicken. Die Verantwortung für die Software, die da entsteht, tragen weiterhin wir. Damit tragen wir auch die Verantwortung für den Ablauf, in dem sie gebaut wird. Ihn so gut wie möglich aufzusetzen, gehört dazu, und am Anfang ist der Hebel am größten.
Wie sieht das in der Praxis aus? Ziemlich vertraut, wenn man ehrlich ist.
Manchmal merkt man es rechtzeitig. Der Agent stolpert im Develop über eine Stelle, die er nicht auflösen kann, und fragt nach. Oder man schaut auf den Fortschritt und denkt: Moment, da wollten wir doch gar nicht hin. Dann wird ein Stück zurückgerollt und neu angesetzt. Ein Weltuntergang ist das nicht. Unnötige Arbeit war es trotzdem.
Manchmal merkt man es erst später. Das Ergebnis läuft, die Tests sind grün, das Problem ist gelöst... nur eben anders, als wir es uns vorgestellt hatten. Technisch falsch ist daran nichts. Der Agent ist schlicht an einer anderen Stelle abgebogen als der, die wir im Kopf hatten.
Und dann kommt der Moment, in dem man sich das Ticket noch einmal anschaut. Woran man die gewünschte Lösung erkannt hätte, stand da gar nicht drin (ertappt). Der Agent hatte keinen Grund, anders abzubiegen.
Jeder dieser Fälle ist für sich verkraftbar. Aber jeder, den wir vorne im Ticket verhindern, erspart uns später im Ablauf eine Schleife.
Dieselbe Person kann im Vertrieb Interessent heißen, in der Auftragsabwicklung Besteller, im Lager Warenempfänger und in der Buchhaltung Debitor. Synonyme sind das nicht. Jeder Begriff bringt eigene Attribute, Zustände und Regeln mit. Ein Debitor hat offene Posten, ein Interessent noch nicht.
Wer das Projekt kennt, erschließt die Bedeutung aus dem Zusammenhang. Ein Agent hat diesen Zusammenhang nur, wenn er aufgeschrieben ist. Steht in einem Ticket „Kunde", im nächsten „Nutzer" und in der Fachspezifikation „Vertragspartner", behandelt er das als drei verschiedene Dinge oder wirft alles in einen Topf. Beides kann falsch sein, und nachfragen wird er in aller Regel nicht.
Begriffe im Ticket kommen bei uns deshalb aus dem Glossar des Projekts und nicht aus dem Sprachgefühl des Tages.
Ein Agent verstärkt, was er bekommt: Gemischte Sprache wird zu Code, in dem sich die Verwirrung wiederfindet.
Ein gutes Ticket beschreibt, welches fachliche Verhalten sich nach der Umsetzung ändern soll. Die technische Lösung ist damit nicht egal. Sie wird nur in einem eigenen Schritt erarbeitet, im Design, gemeinsam von Mensch und AI und eingebettet in die bestehende Architektur. In der Anforderung hat sie noch nichts verloren, zumindest dort nicht, wo die Fachlichkeit sie nicht selbst vorgibt. Trotzdem enthalten viele User Stories schon die halbe Lösung, und ein Agent nimmt diese Vorgabe ernster als jeder Entwickler, der sie früher stillschweigend übergangen hätte.
Am häufigsten fehlen die Nicht-Ziele. Vieles davon lässt sich allgemein regeln, etwa dass keine ungefragten Refactorings stattfinden. Das gehört in Regeldateien und Skill-Definitionen, einmal formuliert und für jede Aufgabe gültig. Harte Grenzen wie kein Zugriff auf Produktionsdaten liegen noch eine Ebene tiefer, in Umgebung und Pipeline (mehr dazu im -> GUARDRAILS-Artikel).
Was sich nicht allgemein formulieren lässt, muss ins Ticket. Welche angrenzende Baustelle ist hier verlockend, gehört aber nicht dazu? Welche Variante haben wir verworfen? Welches Verhalten muss in genau diesem Fall unverändert bleiben? Diese Zeilen sind oft die wertvollsten im Ticket, weil sie Entscheidungen festhalten, die sonst nur in Köpfen existieren. Fehlen sie, räumt der Agent unterwegs gut gemeint auf... und im Review liegt plötzlich der doppelte Diff.
Die Guardrails legen fest, was ein Agent überhaupt tun kann. Das Ticket legt fest, was er in dieser Aufgabe tun soll.
An den Akzeptanzkriterien entscheidet sich, ob ein Ticket erledigt ist. Ein einfacher Test hat sich bewährt: Könnten zwei Menschen, oder zwei Agenten, uneinig sein, ob dieses Kriterium erfüllt ist? Wenn ja, ist es nicht fertig.
„Die Seite soll schnell laden" hat die Form eines Akzeptanzkriteriums, aber keinen Inhalt. Ein Agent wird es als erfüllt betrachten, denn schnell genug ist die Seite aus seiner Sicht fast immer. Prüfbar wird es erst mit Grenzwert, Messmethode und Bedingung. Dasselbe gilt für „Fehler sollen sauber behandelt werden":
Vorher: Der Login soll sauber funktionieren und Fehler abfangen.
Nachher: Gibt eine Nutzerin eine E-Mail-Adresse ohne @-Zeichen ein und klickt auf „Anmelden", erscheint direkt am Eingabefeld der Hinweis „Bitte gültige E-Mail-Adresse eingeben". Es wird keine Anfrage an den Server gesendet. Nach fünf fehlgeschlagenen Anmeldeversuchen innerhalb von zehn Minuten wird das Konto für fünf Minuten gesperrt.
Die zweite Fassung ist länger, lässt aber keinen Raum für Interpretation.
Ebenso wichtig ist Widerspruchsfreiheit. Kriterien, die sich gegenseitig ausschließen, fallen einem Menschen beim Lesen meist auf. Ein Agent entscheidet sich still für eines und erfüllt das andere halb.
Hier liegt für uns der eigentliche Hebel.
Ein Agent meldet ein Ticket als erledigt, weil er davon überzeugt ist. In der Einschätzung der eigenen Arbeit sind Sprachmodelle bemerkenswert selbstbewusst. „Alle Akzeptanzkriterien sind erfüllt" ist ein Satz, der sich sehr leicht erzeugen lässt.
Ist ein Kriterium prüfbar formuliert, kann der Agent es nicht mehr nur abhaken. Er muss zeigen, dass es erfüllt ist: mit einem Test, der vorher rot war und jetzt grün ist, mit einem Log-Auszug, einem Screenshot oder einer Messung. Und, das wird oft übersehen, er kann es dann auch. Erst ein prüfbares Kriterium gibt ihm die Möglichkeit, einen Nachweis zu erbringen statt einer Behauptung.
Dasselbe gilt für alles, was danach kommt. Ein Review-Agent sollte bewusst nicht auf dem Kontext des Agenten aufbauen, der das Feature gebaut hat. Sonst übernimmt er dessen Lesart gleich mit und bestätigt, was er eigentlich prüfen soll. Prüfbare Kriterien geben ihm einen eigenen Maßstab, an dem er das Ergebnis unabhängig challengen kann.
Eine ehrliche Grenze gehört dazu. Akzeptanzkriterien prüfen, ob umgesetzt wurde, was im Ticket steht, nicht ob das Ticket richtig ist. Wer präzise das Falsche beschreibt, bekommt präzise das Falsche, sauber nachgewiesen. Vor der Freigabe lesen wir ein Ticket deshalb mit zwei Fragen: Kann ein Agent daraus etwas anderes bauen als gemeint? Und, die wird gerne vergessen: Ist das überhaupt das, was wir wollen?
Wer das alles ernst nimmt, landet schnell beim anderen Extrem. Wir haben Tickets gesehen, nicht selten von Agenten selbst erzeugt, in denen für eine kleine Korrektur gleich mehrere User Stories mit langen Kriterienlisten standen. Darunter Sätze wie „Das System soll Randfälle robust und elegant behandeln". Das ist viel Text und genauso vage wie das knappe Original. Irgendwann ist der Code schneller geprüft als die Anforderung dazu.
Unsere Faustregel: Jeder Satz muss beeinflussen, was gebaut wird, oder wie geprüft wird, ob es richtig gebaut wurde. Die Tiefe des Tickets folgt der Tiefe der Aufgabe und nicht einer Vorlage.
Ein Ticket, das all das enthält, wird trotzdem länger. Der Agent braucht diese Tiefe, und auch ein Mensch muss sie bei der Freigabe einmal vollständig gelesen haben. Sonst hat niemand die Anforderung validiert.
Danach schauen Menschen oft auf ein Ticket und brauchen dabei fast nie die volle Tiefe. Wer Agenten begleitet, muss wissen, wo sie unterwegs sind und ob die Richtung stimmt, nicht jedes Detail jedes Schritts.
Wir teilen Anforderungen deshalb in zwei Teile:
Wo die beiden Teile liegen, klingt nach einer operativen Randnotiz. Ist es eigentlich auch. Trotzdem hat kaum ein kleines Detail bei uns so viel bewirkt. Die Zusammenfassung steht im Ticketsystem, die ausführliche Fassung liegt fast immer als Markdown im Repository, direkt im zugehörigen Branch. Das Ticketsystem bleibt schlank, und wer dort nachschaut, woran gerade gearbeitet wird, muss sich nicht erst durch Seiten voller Detailbeschreibungen und Akzeptanzkriterien scrollen. Der kognitive Overload bedankt sich. Und der Agent findet seine Anforderung genau dort, wo er ohnehin arbeitet, versioniert neben dem Code, ohne erst über einen MCP-Server ins Ticketsystem greifen zu müssen.
Nicht verhandelbar ist dabei, dass beide Teile dasselbe sagen: dieselben Begriffe, dieselben Nicht-Ziele, dieselbe Vorstellung davon, was fertig bedeutet. Sonst arbeiten Mensch und Agent mit zwei Versionen derselben Aufgabe, und genau das wollten wir vermeiden.
Der Kern
Klare Anforderungen waren schon immer eine gute Idee. Solange Menschen jeden Schritt im Ablauf begleitet haben, war es trotzdem verzeihlich, wenn am Anfang etwas offen blieb. Irgendwer hat es unterwegs gemerkt.
Je autonomer der Ablauf wird, desto weniger gilt das. Was im Ticket unklar ist, wird bestenfalls zur Eskalation und schlimmstenfalls zur plausiblen Lösung am Ziel vorbei. Die Klärung, die früher verteilt über Design, Develop und Review passiert ist, gehört deshalb nach vorne in die Requirements. Das fühlt sich zunächst langsamer an. Aufs Ganze gerechnet ist es das nach unserer Erfahrung nicht.
Ein Mensch fragt nach. Ein Agent entscheidet selbst. Im Ticket nehmen wir ihm so viele dieser Entscheidungen ab wie möglich.
eXXcellent solutions steht für individuelle Software, die mitdenkt, statt begrenzt. Seit 25 Jahren verbinden wir technologische Exzellenz mit Innovationskraft – für Lösungen, die wirken und Unternehmen, die über den Standard hinaus wollen. Dabei decken wir das gesamte Spektrum der Softwareentwicklung ab.