Unser Entwicklungstempo hat sich verändert. Seit wir massiv auf KI setzen, läuft die Umsetzung spürbar schneller – und ich merke, dass wir im Produktmanagement anfangen, hinterher zu hecheln. Anforderungen, die früher erst für den nächsten Sprint klar sein mussten, brauchen jetzt oft eine Klärung gestern. User Research, das Ausarbeiten der richtigen Requirements, Abstimmungen mit Stakeholdern: All das kostet Zeit, die wir gefühlt nicht mehr haben.
In diesem Kontext hat mich einer unserer Entwickler kürzlich auf Thema aufmerksam gemacht, welches in der AI-Coding-Community gerade heiß diskutiert wird: Spec-Driven Development. Meine erste Reaktion war ehrlich gesagt zweigeteilt.
Die Kernthese: Vibecoding funktioniert nur bis zu einem gewissen Punkt, auf der grünen Wiese und für überschaubare Aufgaben. Aber sobald man etwas anpassen muss oder ein Feature komplexer wird, werden die Iterationsschleifen mit dem KI-Agenten länger und mühsamer. Irgendwann ist das Kontextfenster voll und es kommt nur noch Quatsch dabei heraus.
Die Lösung: Statt mit einem vagen Prompt loszulegen und zu hoffen, dass schon irgendwas Brauchbares rauskommt, sollen vor der Implementierung saubere Anforderungen beschrieben werden – eine Spec.
Ehrlich gesagt wusste ich in dem Moment nicht, ob ich lachen oder weinen sollte… Lachen, weil der Entwickler-Community offenbar gerade (neu) aufgeht, dass man für gute Software gute Anforderungen braucht. Weinen, weil die Product- und UX-Community genau das seit Jahren predigt – unter dem Begriff „Product Discovery“ – aber dies scheinbar immer noch nicht überall angekommen ist. Wir haben Bücher darüber geschrieben, Konferenzen damit gefüllt, endlose Diskussionen über den Wert von Discovery geführt… Und jetzt heißt es halt Spec.
Doch nachdem ich mich etwas weiter in das Thema eingelesen hatte, wurde mir klar: Dieser Moment ist keine Niederlage für Product und UX, er ist eine Einladung.
Darum möchte ich Spec-Driven Development (kurz SDD) in diesem Beitrag etwas tiefer beleuchten. Was steckt hinter SDD? Und warum ist es mehr als ein Entwickler-Trend? Welche Rolle können Product und UX dabei spielen? Und wie verändert das die Zusammenarbeit zwischen Product, UX und Engineering?
Was Spec-Driven Development eigentlich ist
SDD beschreibt einen Ansatz, bei dem vor dem Schreiben von Code eine strukturierte Beschreibung – die Spec – erstellt wird. Diese dient dann als Leitplanke für KI-Coding-Agenten. Der Agent erstellt daraus zunächst einen Umsetzungsplan, leitet Aufgaben ab und implementiert diese.
The Four Phases of Spec-Driven Development (aus Zencoder – A Practical Guide to Spec-Driven Development)
Die Grundidee: Je präziser zu Beginn das Ziel (der Intent) formuliert ist, desto weniger läuft ein Agent in die falsche Richtung.
Birgitta Böckeler von Thoughtworks, die sich intensiv mit SDD-Tools wie Kiro, spec-kit und Tessl auseinandergesetzt hat, unterscheidet dabei drei Ausprägungen:
- Spec-first: Vor dem Coding wird eine durchdachte Spec geschrieben, die dem Agenten als Kontext dient. Nach der Implementierung verschwindet sie wieder und beim nächsten Feature fängt man von vorne an. Der Wert liegt rein im besseren Upfront-Kontext.
- Spec-anchored: Die Spec bleibt nach der Implementierung erhalten und wird weiterentwickelt. Sie wird zum lebenden Dokument, zur dauerhaften Beschreibung dessen, was ein Feature tun soll.
- Spec-as-source: Die radikalste Form. Die Spec ist das einzige Artefakt, das Menschen noch anfassen. Code wird ausschließlich daraus generiert – niemand editiert ihn direkt. Taucht ein Bug auf oder wird eine Feature-Änderung nötig, wird nicht der Code angepasst, sondern die Spec präzisiert und der Code neu generiert.
Die meisten Teams – und Tools – nutzen laut ihr den Spec-first-Ansatz.
Was eine Spec konkret enthält? User Stories im „As a…“-Format, Akzeptanzkriterien im „GIVEN… WHEN… THEN…“-Format, Beschreibungen von Datenmodellen, technischen Abhängigkeiten und Business Context. Wer das liest und sich dabei denkt: „Das klingt nach einem guten alten Product Requirement Document“ – der liegt richtig.
Das strukturelle Missverhältnis
KI-gestützte Entwicklung beschleunigt die Umsetzung dramatisch. Was früher Tage dauerte, dauert heute Stunden. Das klingt gut – und ist es auch. Doch es erzeugt ein strukturelles Missverhältnis, das viele Produktteams gerade spüren: Der Entwicklungszug fährt schneller, aber die Gleisbauarbeiten (also Discovery, Anforderungsdefinition, Stakeholder-Abstimmung) sind noch nicht abgeschlossen.
Product und UX können in diesem Tempo kaum mithalten. Nicht weil sie zu langsam sind, sondern weil die Kapazität für gute Anforderungsarbeit schlicht nicht mit der gestiegenen Umsetzungsgeschwindigkeit skaliert. Das Ergebnis: Entweder wartet die Entwicklung – oder sie fängt mit unklaren Anforderungen an. Beides ist teuer.
Und genau hier schließt sich der Kreis zu SDD. Denn das Problem, das SDD lösen soll, kennen Produktmanager*innen seit Jahren: Ohne klaren Intent – egal ob Spec oder Requirement – wird das Falsche umgesetzt, die Umsetzung dauert zu lange (weil man nochmal Änderungsschleifen drehen muss), oder beides.
Discovery unter neuem Namen
SDD ist im Kern Product Discovery – nur endlich in einem Format, mit dem auch Entwicklungsteams etwas anfangen können.
Das ist keine Kritik. Das ist eine Beobachtung, die ich konstruktiv meine. Wir als Product & UX Community haben lange darum gekämpft, dass Discovery nicht als Overhead gesehen wird, sondern als integraler Bestandteil der Produktentwicklung. Dieser Kampf war und ist mühsam. Und wenn derselbe Gedanke jetzt aus der Entwickler-Richtung kommt – neu verpackt und mit Tools und Workflows hinterlegt – dann sollten wir das nicht belächeln, sondern nutzen.
Der typische SDD-Workflow gliedert sich in vier Phasen:
- Discover (Was ist der Business Context? Was braucht der Nutzer?)
- Design (Wie wird das technisch umgesetzt?)
- Tasks (Was sind die konkreten Implementierungsschritte?)
- Implement (Wie sieht der konkrete Code aus?)
Der Spec-Driven Development Workflow (nach Spec-Driven Development von Hari Krishnan)
Die erste Phase – Discover oder Specify – ist buchstäblich Product Discovery. User Stories, Acceptance Criteria, Klärung von Nutzerbedürfnissen und Business Value: Das ist das tägliche Handwerk von Product und UX.
Der Unterschied zur bisherigen Praxis: Diese Beschreibungen landen jetzt nicht mehr nur in Confluence-Seiten, Miro-Boards, Figma-Designs oder in Jira-Tickets, sondern als Markdown-Files direkt im Coding-Kontext der KI-Agenten. Sie werden zum funktionalen Input für die Umsetzung – mit direkter Wirkung.
Die eigentliche Chance
Hari Krishnan beschreibt in seinem Artikel Spec-Driven Development – Adoption at Enterprise Scale den kulturellen Kern von SDD treffend: Wer SDD als rein technisches Rollout behandelt, verschenkt den größten Teil des Potenzials. Teams, die Specs gemeinsam entwickeln, seien strukturell überlegen gegenüber Einzelpersonen, die ihre Prompts optimieren.
Das klingt abstrakt – ist es aber nicht. Was Krishnan beschreibt, ist eine Rollenverteilung, die Produktmanager*innen kennen sollten: Product definiert das Was, uX und Architektur das Wie, Engineering strukturiert die Tasks und setzt diese um.
Produktmanager*innen, die diesen Moment aktiv (mit-)gestalten, stärken ihren Einfluss in der KI-getriebenen Produktentwicklung.
Wer die Spec schreibt (oder zumindest die Discovery-Phase aktiv befüllt), bestimmt, was gebaut wird. Das war schon immer so. Nur war es nie so direkt sichtbar wie jetzt.
Gleichzeitig beschreibt Krishnan auch ein Risiko, das er „SpecFall“ nennt – in Anlehnung an Scrumfall. SDD ohne echte cross-funktionale Zusammenarbeit wird zum Markdown-Friedhof.
Specs, die Produktmanager*innen alleine schreiben und Entwickler*innen ignorieren, helfen niemanden. Specs, die Entwickler*innen alleine schreiben, weil Product & UX nicht eingebunden werden, auch nicht.
Was das konkret bedeutet
Den SDD-Workflow aktiv mitgestalten
Product und UX sollten nicht warten, bis Entwickler*innen die Discover-Phase im SDD selbst befüllen, sondern diese Phase aktiv führen. Das ist kein Einmischen in technische Prozesse – das ist die originäre Aufgabe von Product Management und UX Research & Design.
Discovery-Outputs spec-kompatibel aufbereiten
User Stories mit sauberen Akzeptanzkriterien im GIVEN/WHEN/THEN-Format sind keine neue Erfindung. Aber viele Teams pflegen sie halbherzig. Wenn diese Artefakte jetzt direkt in den Coding-Kontext von KI-Agenten fließen, lohnt es sich, sie ernst zunehmen – und entsprechend Zeit und Aufmerksamkeit hinein zu investieren.
Den Wert von Research explizit einbringen
Eine Spec beschreibt Intent. Aber woher kommt Intent? Aus Nutzerforschung, aus Feedback-Auswertung, aus dem Verständnis des Problems. Das ist die Domäne von Product und UX – und sie sollte in keiner Spec fehlen.
Stakeholder-Alignment nicht als Bremse, sondern als Qualitätssicherung gestalten
Stakeholder-Alignment kostet Zeit. Doch eine Spec, die an den Anforderungen der Stakeholder vorbei geschrieben wurde, erzeugt Nacharbeit – und die ist teurer und sorgt für Verzögerungen. Dieses Argument hat jetzt mehr Gewicht – weil eine fehlerhafte Spec direkt in schlechtem Code landet, nicht erst Sprints später.
Spec-Reviews als gemeinsames Ritual etablieren
Eine Spec, die Product alleine schreibt und dann über den Zaun wirft, ist keine Zusammenarbeit – es ist digitaler Wasserfall. Der eigentliche Wert von SDD entsteht, wenn Product, UX und Engineering die Spec gemeinsam durchgehen, bevor der Agent loslegt. Nicht als formales Approval-Gate, sondern als kurzes, strukturiertes Review: Stimmt der Intent? Sind die Akzeptanzkriterien vollständig? Fehlt technischer Kontext, den nur Engineering kennt?
Das klingt nach Mehraufwand. In der Praxis ist es das Gegenteil – weil Missverständnisse vor der Implementierung geklärt werden, nicht danach.
Fazit
Spec-Driven Development löst nicht das Geschwindigkeitsproblem von Product und UX. Research, Anforderungsanalyse, Stakeholder-Abstimmung, Approval-Prozesse werden durch SDD nicht schneller. Aber es verändert die Richtung des Drucks: Gute Anforderungen werden zur Voraussetzung für funktionierende KI-Entwicklung.
Und das ist die eigentliche Chance: Nicht dass Product und UX plötzlich schneller werden. Sondern dass unser Beitrag – fundierter Research, saubere Anforderungen, klarer Intent – endlich als das sichtbar wird, was er schon immer war: die Voraussetzung für alles, was danach kommt.
Die Frage ist, ob wir diesen Moment aktiv nutzen und SDD aktiv mitgestalten – oder zusehen, wie Entwickler*innen die Discovery-Phase selbst befüllen (mit allem, was das an Qualitätsverlusten mit sich bringt).
Ich bin gespannt, wie ihr das erlebt. Haben eure Entwicklungsteams SDD schon eingeführt – und wenn ja, welche Rolle spielen Product und UX dabei? Schreibt es in die Kommentare.
