Nein. Spec-driven Development wird erst dann zum Wasserfall, wenn du die Spec am ersten Tag einfrierst. Das Wasserfallmodell war riskant, weil Winston W. Royces Modell von 1970 das echte Testen ans Ende schob. Moderne, KI-gestützte Spec-Loops wollen dagegen das, was früher Monate dauerte, auf Minuten schrumpfen lassen – oft passt ein kompletter Zyklus aus Spec, Build, Bewertung und Überarbeitung in einen Nachmittag.
Deshalb ist der Spruch vom „Wasserfall mit Markdown“ zwar eingängig, aber schludrig. Er beschreibt einen echten Fehlermodus. Aufgeblähte Docs, eingefrorene Anforderungen, Spec Drift, Zeremonien, die Tokens verbrennen. Alles real. Aber das ist schlechte Praxis, nicht die Grundidee. Gutes SDD behandelt die Spec wie Code: versioniert, überarbeitet, umstritten, nachgeschärft und gegen Akzeptanzkriterien getestet.
Du willst keine Anforderungsabteilung in einer .md-Datei nachbauen. Du willst dir und deinem Coding-Agent ein bewegliches Ziel geben, das schnell schärfer wird.
| Ansatz | Verhalten der Spec | Zeitpunkt des Feedbacks | Was meistens passiert |
|---|---|---|---|
| Klassisches Wasserfallmodell | Vorab festgelegt und fix | Spät | Nacharbeit zeigt sich, wenn sie teuer ist |
| Schlechtes SDD | Markdown-Doc, zu früh eingefroren | Immer noch spät | Du bekommst Zeremonie plus Drift |
| Echtes SDD | Lebendes, versioniertes Artefakt | Früh und laufend | Du korrigierst die Richtung, bevor der Code ausufert |
Inhalt
- Die kurze Antwort lautet Nein – wenn du es richtig machst
- Der Fehlermodus „Wasserfall mit Markdown“
- Was echtes SDD anders macht: lebende Specs und schnelle Loops
- Ein praktischer SDD-Workflow für Solo Builder
Die kurze Antwort lautet Nein – wenn du es richtig machst
Die Gegenreaktion reagiert auf etwas Reales. Viele schreiben riesige Specs, geben sie an Cursor oder Claude Code weiter und wundern sich dann über langsame Zyklen und veraltete Docs. Genau das ist Wasserfall mit Markdown.
Aber echtes SDD ist kein einmaliges Übergabedokument. Es ist ein lebendes, versioniertes Artefakt, das der Implementierung vorausgeht und sich ändert, während du dazulernst. Dieser Unterschied ist wichtig. Er ist der ganze Punkt. Die Analyse der Debatte von Gigi Labs sagt das direkt in ihrer Aufschlüsselung, was Spec-driven Development eigentlich ist, und Marc Brookers Beitrag von 2026 argumentiert genauso: Der Loop ist weiterhin iterativ, nur viel schneller, weil KI den Abstand zwischen Spec und Code verkürzt – nachzulesen in seinem Vergleich von Wasserfallmodell und Spec-driven Development.
Faustregel: Wenn sich die Spec nach dem ersten Kontakt mit der Realität nicht mehr ändern darf, machst du kein SDD. Du machst Papierkram.
In der Kritik steckt außerdem ein Kategorienfehler. Reihenfolge ist nicht dasselbe wie Prozess. Ja, du denkst nach, bevor du codest. Das allein macht noch keinen Wasserfall.
Der Fehlermodus „Wasserfall mit Markdown“
Der Fehlermodus ist leicht zu erkennen. Du schreibst ein großes Markdown-Doc. Du spezifizierst Edge Cases bis ins Letzte. Du fütterst es einem Agent. Der Code driftet trotzdem ab. Jetzt pflegst du zwei Dinge: die App und die Fiktion, dass die Spec noch zu ihr passt.
Deshalb sind manche Devs genervt. In einer Diskussion über Vorgehensmodelle in der Softwareentwicklung landet dieses Muster genau dort, wo man es erwartet: zu viel Zeremonie, zu wenig Lernen. Dieselbe Klage taucht in aktuellen Community-Threads auf. Der Thread in r/agile darüber, was Spec-driven Development falsch macht, betont stark, dass SDD zur Produktivitätsfalle werden kann, wenn Docs zu Schranken statt zu Werkzeugen werden. Ein Thread in r/brdev darüber, wie man den KI-Einsatz in Dev-Teams vereinheitlicht, zeigt denselben Schmerz von einer anderen Seite: Eingefrorene Specs machen Teams langsamer, nicht klarer.
Was schiefgeht
- Die Spec wird wie ein Vertrag behandelt. Dann will niemand sie mehr anfassen.
- Der Agent schreibt Code gegen veraltete Absichten. Dann beginnt der Drift.
- Das Review kommt zu spät. Dann war die „Klarheit“ nur gespielt.
Beim Anti-Pattern hat die Kritik recht. Falsch liegt sie, wenn sie das Anti-Pattern für die Methode selbst hält.
Deshalb wird „Spec-first“ auch zu Unrecht mit „Spec-as-Source“ in einen Topf geworfen. Das ist nicht dasselbe. Ein schlanker Planungsdurchgang ist das eine. Ein starres Pseudo-BRD, das niemand überarbeitet, ist etwas ganz anderes.
Was echtes SDD anders macht: lebende Specs und schnelle Loops
Der entscheidende Unterschied ist die Geschwindigkeit des Feedbacks. Das Wasserfallmodell scheiterte, weil die Validierung am Ende stattfand. Royce hat das 1970 klar gesagt. Seine Warnung: Die Testphase am Ende des Zyklus war das erste Mal, dass kritisches Verhalten systematisch geprüft wurde. Genau diese späte Validierung machte das Wasserfallmodell gefährlich. François Zaninottos Kritik von 2025 ist hier nützlich, weil sie, obwohl sie SDD kritisiert, das historische Kernproblem herausstellt und festhält, dass SDD heute mit dem Versprechen antritt, KI könne einen kompletten Loop, der früher Monate dauerte, auf Minuten verdichten, oft auf einen Nachmittag – nachzulesen in seinem Essay darüber, ob das Wasserfallmodell über Specs zurückkehrt.
Wie lebende Specs tatsächlich aussehen
Workflows im Stil von GitHub behandeln die Spec als Source of Truth, nicht als toten Anhang. Roger Wongs Analyse von 2026 beschreibt Specs, die in Markdown geschrieben sind, mit Abschnitten, Beispielen, Payloads und Akzeptanzkriterien, und die dann in einem Loop direkt im Repo generiert, getestet und überarbeitet werden – nachzulesen in seinem Text über Muster im Spec-driven Development. Er unterscheidet außerdem drei Muster: Spec-first, Spec-anchored und Spec-as-Source.
Diese Einteilung ist wichtig, weil viele aneinander vorbeireden. Sie sagen „SDD“, meinen aber eine einzige enge, ungeschickte Umsetzung.
Der Maßstab, auf den es ankommt
Simon Willisons Test taugt mehr als die meisten Prozessdebatten: Wenn ein LLM jede Zeile deines Codes geschrieben hat, du aber alles reviewt, getestet und verstanden hast, ist das kein Vibe Coding. Derselbe Maßstab gilt für Specs. Wenn du die Spec nicht reviewt, getestet und verstanden hast, ist sie nur generierte Prosa.
Ein nützliches Denkmodell kommt aus Content-Systemen. Gute Specs brauchen dieselbe Disziplin wie Content, der von der Erstellung bis zur Ausmusterung gepflegt wird. Du erstellst sie, aktualisierst sie, dünnst sie aus und musterst aus, was nicht mehr zur Realität passt.
Eine lebende Spec ist nicht länger. Sie ist frischer.
Ein praktischer SDD-Workflow für Solo Builder
Als Solo Builder hältst du es schlank. Du brauchst keinen Stapel an Zeremonien. Du brauchst einen engen Loop, klare Akzeptanzkriterien und die Gewohnheit, die Spec neu zu schreiben, wenn sich die Realität ändert.
Nutze diesen Workflow
- Fang beim Problem an, nicht bei der Feature-Liste. Schreib auf, was Nutzende stört, welche Rahmenbedingungen gelten und was „fertig“ bedeutet.
- Entwirf eine kleine, strukturierte Spec. Halte Scope-Grenzen, Annahmen und Akzeptanzkriterien sichtbar. Wenn du einen Ausgangspunkt brauchst, nimm ein Template für ein Product Requirements Document.
- Gib die Spec von Hand an deinen Coding-Agent. Cursor, Claude Code, Codex, Gemini. Deine Wahl. Am Steuer sitzt weiterhin du.
- Prüf das Ergebnis sofort. Schau, ob Code und Spec noch übereinstimmen.
- Überarbeite die Spec nach jeder wichtigen Erkenntnis. Nicht wöchentlich. Nicht „später“. Sofort.
Der typische Fehler: so zu tun, als verdiene der erste Entwurf Gehorsam. Tut er nicht. Er verdient Druck.
Hier ist eine Schritt-für-Schritt-Demo, falls du diese Art von Prozess in Aktion sehen willst:
Was du vermeiden solltest
- Riesige Specs vorab
- Akzeptanzkriterien, die niemand prüft
- Specs außerhalb der Versionskontrolle
- Output des Agents, den du nicht sorgfältig gelesen hast
Wenn deine Spec lange unverändert bleibt, war die Aufgabe entweder trivial oder du hast aufgehört zu lernen.
Das ist die Antwort auf die Frage „Ist Spec-driven Development nur Wasserfall mit Markdown?“ Manchmal ja, wenn es schlecht gemacht wird. Gut gemacht ist es aber das Gegenteil. Es holt das Feedback nach vorn, hält die Absicht sichtbar und gibt Solo Buildern eine Möglichkeit, klar zu denken, bevor sie Zeit im Code verbrennen.
Specs von Hand zu schreiben ist der manuelle Weg. Die Loops von Tekk.coach schreiben sie für dich, ausgehend von dem, was sich in deinem Code geändert hat: dasselbe Board, dieselben Akzeptanzkriterien, geschlossen, sobald der PR gemergt ist.
Teil des Leitfadens zu Spec-driven Development – ein ehrliches Playbook dafür, mit KI-Coding-Agents auszuliefern. Die andere Hälfte ist Loop Engineering: An der Spec erkennt ein Loop, dass er fertig ist.