Der Build ist grün, alle Tests laufen durch — und das Feature ist trotzdem falsch. Nicht kaputt: falsch. Es tut präzise das, was niemand gebraucht hat.
Der Ablauf davor ist in fast jedem Haus derselbe. Zwei Wochen Arbeit, ein sauberer Pull Request, vierzig grüne Tests, Review von zwei Kollegen, Merge am Donnerstag. In der Demo am Freitag sagt jemand aus dem Fachbereich einen einzigen Satz: „Ach so — so war das nicht gemeint.“ Danach diskutieren fünf Leute vierzig Minuten lang, wer schuld ist. Niemand ist schuld. Der Code tut exakt das, was im Ticket stand. Im Ticket stand etwas, das der Kunde nicht gemeint hat.
Das Unangenehme daran ist nicht der Fehler. Es ist die Stimmung im Raum danach: zwei Wochen Arbeit, niemand hat geschlampt, und trotzdem muss jemand sagen, dass es so nicht bleiben kann. Diese Sorte Gespräch hinterlässt mehr Schaden als der Code.
Grün ist kein Urteil über Richtigkeit. Grün heißt: Der Code stimmt mit der Erwartung überein, die jemand aufgeschrieben hat. Ist die Erwartung falsch, ist Grün nur die schnellere Art, sich zu irren — und je besser deine Testabdeckung, desto zuverlässiger zementierst du den Irrtum. Genau hier setzt VSDD an: Verified Spec-Driven Development. Keine weitere Teststufe. Eine zweite Frage.
Die Spezifikation ist die Entwurfsarbeit
Die übliche Vorstellung von einer Spezifikation ist die eines Begleitdokuments: Man weiß, was zu bauen ist, und schreibt es auf, damit ein anderer es umsetzen kann. In dieser Reihenfolge ist das Dokument tatsächlich Ballast. Es wiederholt, was ohnehin klar war, und veraltet in dem Moment, in dem jemand anfängt zu tippen.
Nur stimmt die Reihenfolge nicht. Beim Schreiben der Spezifikation entsteht der Entwurf. Jede Unschärfe, die dir beim Formulieren auffällt, ist eine Entscheidung, die sonst niemand bewusst trifft — sie fällt dann trotzdem, um 16 Uhr, in einer if-Bedingung, von der Person, die gerade am Cursor sitzt, ohne Protokoll und ohne Rückfrage.
Ein Satz wie „Der Nutzer wird benachrichtigt, wenn sich etwas Wichtiges ändert“ sieht harmlos aus und enthält drei offene Entscheidungen. Welcher Nutzer — der Ersteller, der Zuständige, alle Beteiligten? Was ist wichtig — jede Änderung, nur der Zustand, nur bestimmte Felder? Und was heißt benachrichtigt: ein Punkt in der Oberfläche, eine Mail, beides, sofort oder gesammelt? Drei Fragen, zehn Minuten. In der Umsetzung werden daraus drei Annahmen, und zwei davon sind falsch.
WIE ES ANKOMMT
„Das Rechnungsmodul muss flexibler werden.“
WIE ES BAUBAR WIRD
„Buchhaltung stellt für einen Kunden mit mehreren Projekten eine Sammelrechnung je Quartal, mit Einzelnachweis je Projekt.“
Eine gute Spezifikation erkennst du an einem einzigen Kriterium: Der Text ist für jemanden geschrieben, der nicht im Termin war. Gib sie einem Kollegen aus einem anderen Team. Fragt er, wie er es bauen soll, ist sie gut. Fragt er, was gemeint ist, hast du gerade zwei Tage gespart.
Und sie wird nicht einmal geschrieben und dann abgelegt. Die Spezifikation wird fortgeschrieben: Sobald die Umsetzung von ihr abweicht, ist eines von beiden falsch, und jemand muss entscheiden, welches. Wer diese Entscheidung dauerhaft vermeidet, hat am Ende beides — ein Dokument, dem niemand glaubt, und ein System, das niemand erklären kann.
Test zuerst — und ein Review, das wehtut
Wenn die Spezifikation der Entwurf ist, sind die Tests ihre Zähne. Ein Kriterium, das sich nicht in eine Prüfung übersetzen lässt, ist kein Kriterium, sondern eine Stimmung. „Der Export soll performant sein“ ist eine Stimmung. „5.000 Zeilen in unter zwei Sekunden, gemessen am 95. Perzentil“ ist ein Kriterium. Der Unterschied zwischen beiden Sätzen ist nicht Genauigkeit um ihrer selbst willen, sondern die Frage, ob am Ende jemand streiten muss.
Test zuerst heißt deshalb nicht Testabdeckung zuerst. Es heißt: Bevor Code entsteht, steht fest, woran man das Ergebnis erkennt. Wer den Test danach schreibt, schreibt ihn gegen das, was der Code tut. Das ist eine ehrliche Beschreibung der Umsetzung und ein wertloses Urteil über die Anforderung. Die grüne Suite über dem falschen Verhalten entsteht genau so — nicht aus Nachlässigkeit, sondern aus der falschen Reihenfolge.
Dann kommt der Teil, den die meisten Teams überspringen, weil er unangenehm ist: das gegnerische Review. Nicht das freundliche „sieht gut aus“ unter einem Pull Request, sondern ein Durchgang über die Spezifikation, bevor eine Zeile Code existiert, mit einem klaren Auftrag: sie auseinandernehmen. Drei Lesarten finden, die alle zu diesem Text passen und drei verschiedene Produkte ergeben. Den Fall nennen, der nicht darin vorkommt.
Eine Spezifikation, die niemand falsch verstehen kann, ist die halbe Implementierung.
Das kostet zwanzig Minuten und fühlt sich falsch an, weil es aussieht, als zerlege man mutwillig ein fertiges Dokument. Genau das ist der Punkt. Ein Missverständnis, das im Review über der Spezifikation auffällt, kostet einen Absatz. Dasselbe Missverständnis nach dem Merge kostet einen Sprint. Beim Kunden kostet es Vertrauen — die einzige Währung im Projekt, die sich nicht nachbestellen lässt.
Es hilft, das offen auszusprechen: Ein gegnerisches Review ist kein Misstrauen gegen die Person, die den Entwurf geschrieben hat. Es ist die letzte Gelegenheit, an der ein Irrtum nichts kostet außer zwanzig Minuten. Teams, die das einmal erlebt haben, verteidigen diese zwanzig Minuten später am härtesten.
Warum diese Reihenfolge in den letzten Jahren wichtiger geworden ist statt unwichtiger, lässt sich in einem Satz sagen: Ein Mensch, der eine lückenhafte Vorlage bekommt, fragt nach. Ein Agent fragt nicht. Er füllt die Lücke plausibel, schnell und mit vollem Selbstvertrauen — und liefert sauberen, getesteten Code für eine Anforderung, die so nie gestellt wurde.
Verifiziert heißt zwei Fragen
In den meisten Teams wird „fertig“ mit einer einzigen Frage beantwortet: Ist es so gebaut, wie es spezifiziert war? Diese Frage lässt sich beantworten, ohne den Raum zu verlassen — Code gegen Spezifikation, Tests grün, Haken dran; sie ist auch die einzige Frage, die eine Statusspalte je beantworten kann.
Die zweite Frage lässt sich von innen nicht beantworten: Liefert es das Ergebnis, für das wir es gebaut haben? Dieselbe Funktion kann die erste Frage mit Ja und die zweite mit Nein beantworten. Das ist der Fall vom Anfang dieses Textes, und er ist kein Sonderfall. Er ist der Normalfall überall dort, wo zwischen dem Wunsch und der Umsetzung mehr als zwei Weitergaben liegen.
Deshalb hat „verifiziert“ zwei Stufen und nicht eine. Die erste ist eine Behauptung: Die Umsetzung sagt, sie habe geliefert, was spezifiziert war. Die zweite ist eine Bestätigung: Jemand, der das Ergebnis braucht, sagt, dass es das Ergebnis ist. Zwei Absender, zwei Zeitpunkte. Wo beide in denselben Haken fallen, bedeutet der Haken nichts.
An einer Stelle trennt das Modell in angajuu diese beiden Enden schon heute: Der Umsetzungsstand einer Produktanforderung kennt vier Werte, und der letzte heißt verifiziert. Der Jira-Abgleich weigert sich ausdrücklich, irgendeinen Jira-Status darauf abzubilden — Verifikation ist ein menschliches Urteil und nichts, was von außen in eine Spalte hereinwandert.
Was diese Checkliste nicht ist: die Kriterien der Anforderung selbst. Die stehen heute, wenn sie überhaupt entstehen, als Fließtext in der Beschreibung — unter einer Zwischenüberschrift, die Claude beim Entwerfen setzen soll. Fließtext in einem Textfeld lässt sich lesen. Abfragen lässt er sich nicht, prüfen auch nicht, und ob er erfüllt ist, verfolgt niemand.
Im Bau In angajuu werden Abnahmekriterien zu eigenständigen Daten: Jede Anforderung trägt ihre Kriterien, und die Erfüllung wird zweistufig festgehalten — als Behauptung der Umsetzung und als bestätigte Abnahme.
Diese Trennung ist keine Buchhaltung; sie ist der Unterschied zwischen „wir haben geliefert“ und „es wirkt“ — und damit zwischen einem Statusbericht, den man vorliest, und einem, den man glaubt.
Womit du am Montag anfängst
Nicht mit einer Methode und schon gar nicht mit einer Vorlage. Nimm die nächste Anforderung, die ohnehin ansteht, und schreib drei Dinge auf, bevor jemand ein Ticket anlegt.
- Was gebraucht wird — in den Worten dessen, der es braucht, nicht in deinen.
- Woran man erkennen würde, dass es erfüllt ist. Eine Zahl, eine Bedingung, ein beobachtbares Verhalten.
- Was ausdrücklich nicht dazugehört. Das ist der Punkt, den alle weglassen, und der, der die meisten Diskussionen erspart.
Dann gib diese halbe Seite einer Person, die nicht dabei war, mit genau einem Auftrag: die Stelle finden, an der man raten müsste. Zwanzig Minuten. Was dabei herauskommt, ist keine Kritik an deiner Formulierung, sondern die Liste der Entscheidungen, die sonst in der Umsetzung gefallen wären — von jemand anderem, später und ohne Rückfrage.
Und halt am Ende fest, wer bestätigt, dass es wirkt, und woran er das festmacht. Fällt dir zu dieser Frage niemand ein, ist das die wichtigste Erkenntnis des Tages: Dann hast du eine Anforderung ohne Empfänger — und die wird auch mit grünen Tests nicht richtig.
Beim ersten Mal wird dir jemand einfallen. Beim zweiten Mal fällt dir auf, dass diese Person gar nicht mitbekommen würde, wenn das Feature still scheitert. Genau an dieser Stelle hört „fertig“ auf, eine Behauptung zu sein.
Wie sich dieselbe Disziplin verschiebt, wenn nicht ein Kollege, sondern ein Agent aus deiner Vorlage baut, steht in KI-getriebene Entwicklung beginnt vor dem Prompt — dort geht es um den Kontext, den ein Modell nicht erraten kann, und darum, warum er Produktarbeit ist. Und wenn du lieber sehen möchtest, wie sich eine belastbare Spezifikation im Alltag anfühlt, statt sie als Methode zu lesen: Ein Tag im Entwicklungsteam geht einen Sprint-Tag durch, vom Ticket am Morgen bis zur Frage, was die Umsetzung eigentlich abgedeckt hat.