„Wir brauchen sowas wie eine Warteliste.” Aus diesem Satz baut ein Coding Agent zuverlässig etwas. Ob es das ist, was gemeint war, entscheidet sich vorher — an einer Stelle, die die meisten Teams gar nicht schreiben.
Der Intent hat vier Teile, nicht einen
Ein Intent ist der beschriebene Zielzustand: was gelten soll, wenn die Arbeit fertig ist. Dazu gehören untrennbar die Gegenstücke:
- was das System danach beobachtbar kann
- was unverändert bleiben muss
- was ausdrücklich nicht zum Auftrag gehört
- welche Fragen noch offen sind
Die ersten drei schreiben die meisten irgendwann auf. Die vierte fehlt fast immer.
Offene Fragen verschwinden nicht, sie tarnen sich
Eine Frage, die niemand notiert, wird trotzdem beantwortet — vom Agenten, im Vorbeigehen, als plausible Annahme. „Wie lange gilt ein Nachrückangebot?” wird zu 48 Stunden, weil das vernünftig klingt. Nirgends steht, dass hier entschieden wurde, und im Review sieht der Diff schlüssig aus.
Das ist der Unterschied zwischen einer fehlenden Anforderung und einer verdeckten: Die fehlende merkt man. Die getarnte hat schon Code.
Wer entscheidet, gehört mit in die Spec
Deshalb steht in einer brauchbaren Spezifikation nicht nur was, sondern auch wer. Feldnamen darf der Agent vorschlagen. Die Frist eines Nachrückangebots ist Sache der Fachseite, eine zusätzliche Tabelle Sache der Architektur, das Stornorecht für fremde Buchungen Sache von Security und Fachseite gemeinsam. Ohne diese Zuordnung wird dieselbe Frage zweimal geklärt: leise beim Bauen, laut im Review.
Mehr dazu im Seminar
Wie aus einer vagen Anfrage ein prüfbarer Intent und daraus eine knappe Spezifikation wird, zeigt das Modul Von der Anforderung zur Spezifikation aus dem Seminar Spec-driven & Agentic Software Development — mit Video und Kapitelübersicht.