Spec-Driven Development vs. Vibe Coding: Wasserfall?

Spezifikationen als Single Source of Truth oder langsame Zeremonie?

Inhaltsverzeichnis

Spec-Driven Development trat 2026 als die ernsthafte Antwort der Entwickler auf die Abweichungen beim Vibe Coding auf.

Das Argument ist einfach: KI-Agenten produzieren bessere und konsistentere Ergebnisse, wenn sie gegen eine überprüfte Spezifikation implementieren, anstatt auf einem ad-hoc Prompt zu basieren. Theoretisch schwer widerlegbar.

In der Praxis nannte Hacker News dies „Waterfall Strikes Back“ (Der Wasserfall-Ansatz schlägt zurück).

Beide Seiten haben ihre Berechtigung.

Spec-Driven Development versus Vibe Coding

Der Fall für SDD in einer Vibe-Coding-Welt

Vibe Coding – die Praxis, einen losen Prompt zu schreiben und iterativ auf das zu reagieren, was der KI-Agent produziert – funktioniert für kleine, explorative und entsorgbare Arbeiten bemerkenswert gut. In den ersten sechs Monaten des Jahres 2025 war es das dominierende Muster im KI-gestützten Programmieren. Entwickler lieferten Skripte, Prototypen und einfache Tools schneller aus als je zuvor.

Dann wuchsen die Projekte. Multi-File-Features begannten zu driftieren. In Session 1 etablierte Einschränkungen wurden in Session 3 vergessen. Sicherheitsannahmen wurden aufgegeben. Architektur Entscheidungen verschoben sich mitten im Feature, weil der Agent kein dauerhaftes Gedächtnis für die Absicht hatte.

Spec-Driven Development (SDD) erschien als die disziplinierte Antwort. Die Kernbehauptung: Machen Sie die Spezifikation zum zentralen Artefakt, nicht den Prompt. Schreiben Sie zuerst Anforderungen, ein Design und einen Aufgabenplan. Lassen Sie den Agenten diese Artefakte schrittweise implementieren. Halten Sie die Spezifikation versioniert und aktualisiert.

KI-Programmierwerkzeuge – GitHub Spec Kit, Kiro, BMAD und eine wachsende Reihe von benutzerdefinierten Claude Code-Workflows – sind allesamt Umsetzungen dieser Idee. Die Werkzeuge sind real. Das Interesse ist real. Der Widerstand ist es ebenfalls.

Wofür Vibe Coding gut ist

Bevor man Vibe Coding abschlägt, lohnt es sich, präzise zu sein, wofür es sich eignet.

Explorative Prototypen. Wenn Sie nicht sicher sind, was Sie bauen möchten, ist der schnellste Weg, etwas Grobes zu bauen und darauf zu reagieren. SDD erfordert das Wissen, was spezifiziert werden soll. Wenn Sie es noch nicht wissen, sind Spezifikationen vorzeitig.

UI-Experimente. Visuelle Layouts und das Gefühl von Interaktionen sind schwer im Voraus zu spezifizieren. Vibe Coding lässt Sie Optionen schnell sehen, die meisten verwerfen und sich auf etwas konvergieren, das tatsächlich richtig funktioniert. Ein Anforderungsdokument hilft Ihnen hier nicht.

Entsorgbare Automatisierung. Einmalige Skripte, Datenextraktionsjobs, Migrationshilfen – diese benötigen selten ein Design-Dokument. Die Kosten, sie leicht falsch zu machen, sind gering. Die Kosten für einen langsamen, zeremoniellen Prozess sind real.

Schnelles Feedback. Wenn Sie etwas schnell lernen müssen – funktioniert diese API so, wie ich es denke? – verkürzt Vibe Coding den Lernzyklus auf Minuten. SDD würde dies ohne Nutzen verlangsamen.

Der Fehler besteht darin, die Erfolgsmuster aus diesen Kontexten auf Produktionsfeatures mit echten Einschränkungen, echten Nutzern und echten Konsequenzen bei Fehlern anzuwenden.

Wo Vibe Coding versagt

Vibe Coding verschlechtert sich vorhersagbar, wenn Umfang und Bedeutung zunehmen.

Multi-File-Änderungen. Sobald ein Feature fünf oder mehr Dateien betrifft, verliert das Kontextfenster des Agents den Überblick über Invarianten. Ohne ein Design-Dokument muss jeder Prompt Kontext neu etablieren, der in einer früheren Session etabliert und vergessen wurde.

Architektonische Abweichung. Ohne explizite Nicht-Ziele implementieren Agenten Dinge. Der Agent fügt eine Caching-Schicht hinzu, weil sie vernünftig erscheint. Drei Sessions später ist die Caching-Annahme im Datenmodell verankert und ihr Entfernen ist kostspielig.

Vergessene Einschränkungen. „Nur authentifizierte Nutzer können dies auslösen“ ist ein Satz in einem Anforderungsdokument. In einer Vibe-Coding-Session ist es etwas, das Sie einmal in Session 1 erwähnt haben und das der Agent in Session 4 nicht mehr erinnert, wenn er den neuen Endpunkt schreibt.

Verborgene Sicherheitsannahmen. Autorisierungsregeln, Eingabegrenzen, Umgang mit Geheimnissen – dies sind genau die Art von impliziten Anforderungen, die übersehen werden, wenn der Agent nach plausiblem, funktionierendem Code optimiert, anstatt nach korrektem, eingeschränktem Code.

Team-Übergabe. Wenn Sie es durch iteratives Prompting gebaut haben, ist das Artefakt, das festhält, was entschieden wurde und warum… der Git-Log. Viel Glück damit.

Was Spec-Driven Development ändert

SDD beansprucht nicht, Iteration zu eliminieren. Die guten Versionen von SDD sind explizit iterativ. Was sie ändert, ist, wo die Iteration stattfindet. Für die vollständige Definition – einschließlich wie sich SDD von TDD, BDD und formalen Methoden unterscheidet – siehe Was ist Spec-Driven Development?

Anstatt am Code zu iterieren und die Absicht aus Diffs zu inferieren, iterieren Sie an der Spezifikation und implementieren dann. Die Spezifikation wird zum Artefakt, das festhält, was entschieden wurde, warum und was außerhalb des Umfangs liegt – und erfüllt eine ähnliche Funktion wie Architektur-Entscheidungsprotokolle ist jedoch auf Feature-Absicht ausgerichtet, anstatt auf systemweite Entscheidungen. Der Code implementiert diese Absicht.

Ein typischer SDD-Workflow durchläuft fünf Phasen:

Spezifizieren. Problemstellung, Nutzer, Ziele, Nicht-Ziele, Akzeptanzkriterien, offene Fragen.

Planen. Architektur-Entscheidungen, betroffene Module, Datenmodell, API-Verträge, Sicherheitsbedenken, Teststrategie.

Aufgabenzerlegung. Kleine Implementierungsschritte mit expliziten Validierungskriterien und menschlichen Review-Checkpoints.

Implementieren. Eine Aufgabe nach der anderen, mit Kontext-Reset zwischen den Aufgaben, unter Anwendung der Einschränkungen aus der Spezifikation und Aktualisierung des Plans, wenn die Realität vom Design abweicht.

Validieren. Tests, Linting, Typchecks, Akzeptanzkriterien, Spec-to-Code-Diff.

Der Agent beteiligt sich an den meisten Phasen – Entwurf der Spezifikation, Generierung des Designs, Vorschlag von Aufgaben – aber Menschen überprüfen die Artefakte, bevor die Implementierung beginnt. Dieser Review-Schritt ist der zentrale Unterschied zwischen SDD und Vibe Coding.

Warum Entwickler es Waterfall nennen

Die Waterfall-Kritik ist nicht falsch. Sie richtet sich einfach gegen schlechtes SDD, nicht gegen SDD selbst.

Das spezifische Versagensmuster ist lange Planung im Vorfeld. Das definierende Merkmal von Waterfall ist ein Feedback-Loop, der sich über Wochen oder Monate erstreckt: Anforderungsphase, Designphase, Build-Phase, Testphase, Veröffentlichung. Feedback kommt spät. Zum Zeitpunkt, an dem Sie entdecken, dass die Designannahme falsch war, haben Sie bereits Wochen darauf aufgebaut.

Wenn ein Entwickler Spec Kit verwendet und eine 200 Zeilen lange Aufgabenliste generiert, bevor er eine einzige Zeile Code schreibt, und dann zwei Tage damit verbringt, das Anforderungsdokument zu polieren, bevor der Agent etwas berührt, ist das Waterfall. Es ist Waterfall mit Markdown statt UML, aber das Versagensmuster ist identisch.

Ein HN-Kommentator beschrieb die Nutzung von Spec Kit für ein kleines CLI-Tool und fand es „zu langsam, zu viel Anpassen, bevor man Code sieht.“ Das ist die schlechte Version. Dieser Nutzer hatte recht, es für diese Aufgabe abzulehnen.

Die nützliche Kritik ist nicht „Spezifikationen sind schlecht“. Es ist „Lange Planung im Vorfeld vor Feedback ist schlecht.“ Das sind unterschiedliche Behauptungen.

Der nützliche Mittelweg

Gutes SDD vermeidet die Waterfall-Falle, indem es die Spezifikation klein hält und die Implementierung früh beginnt.

Kleine Spezifikationen. Ein Anforderungsdokument für ein einzelnes Feature sollte auf einen Bildschirm passen. Wenn die Spezifikation zehn Seiten lang ist, handelt es sich entweder um ein Plattform-Design oder es muss in kleinere Features aufgeteilt werden. Zu große Spezifikationen dauern zu lange in der Überprüfung und werden schnell veraltet.

Kurze Aufgaben-Slices. Jede Aufgabe sollte in einer einzigen Agent-Session implementierbar sein, als kleiner Diff überprüfbar und isoliert testbar sein. Wenn Aufgaben zu groß sind, dehnt sich der Implementierungszyklus aus und die Zuordnung von Spezifikation zu Code wird schwer zu verifizieren.

Frühe Implementierung. Spezifizieren Sie die erste Aufgabe, implementieren Sie sie, validieren Sie sie und gehen Sie dann zur nächsten Aufgabe über. Spezifizieren Sie nicht alles, bevor Sie irgendetwas implementieren. Die erste Implementierung wird Dinge aufdecken, bei denen Ihre Spezifikation falsch lag. Aktualisieren Sie die Spezifikation, bevor Sie fortfahren.

Lebendige Spezifikation. Wenn die Realität vom Design abweicht – und das wird sie tun – aktualisieren Sie die Spezifikation, nicht nur den Code. Die Spezifikation ist nur nützlich, wenn sie widerspiegelt, was tatsächlich gebaut wurde.

Tests als ausführbares Feedback. Jedes Akzeptanzkriterium sollte mindestens einem Test zugeordnet sein. Das Testsuite ist die maschinenlesbare Version der Spezifikation. Wenn die Spezifikation sagt: „Nur authentifizierte Nutzer können dies auslösen“, sollte es einen Test geben, der überprüft, dass nicht authentifizierte Anfragen abgelehnt werden.

Dieser Hybrid – kleine Spezifikationen, kurze Aufgaben, frühe Implementierung, lebendige Dokumente – ist das, was tatsächlich funktioniert. Es ist nicht Vibe Coding und es ist nicht Waterfall. Es ist kontrollierte Iteration mit dauerhaften Artefakten.

Wann SDD Vibe Coding übertrifft

Verwenden Sie SDD – auch leichtgewichtiges SDD – wenn die Kosten, es falsch zu machen, real sind.

Risikoreiche Geschäftslogik. Abrechnung, Berechtigungen, Datenmigrationen, Idempotenz – jede Logik, bei der inkorrektes Verhalten teuer oder schwer rückgängig zu machen ist. Vibe Coding lässt diese Art von Anforderungen implizit. SDD macht sie explizit und überprüfbar vor der Implementierung.

Produktions-API-Änderungen. Jede Änderung an einem öffentlichen oder internen API-Vertrag sollte ein Design-Dokument haben. Das Design-Dokument ist das, was Sie überprüfen, bevor der Agent Code schreibt, der Aufrufer bricht.

Multi-Agent-Workflows. Wenn mehrere Agenten verschiedene Teile eines Features implementieren, ist die Spezifikation die gemeinsame Single Source of Truth. Ohne sie optimiert jeder Agent lokal und die Teile passen möglicherweise nicht zusammen.

Team-Übergabe. Wenn ein anderer Entwickler oder ein anderer Agent diese Arbeit fortsetzen wird, ist die Spezifikation das Übergabe-Artefakt. Ein Git-Log und ein README reichen nicht aus.

Signifikante Refaktorisierungen. Refaktorisierungen, die Kernabstraktionen berühren, benötigen eine explizite Aussage darüber, was gleich bleiben muss (Verhalten) und was sich ändern darf (Struktur). Ohne dies kann der Agent Verträge brechen, die Sie als erhalten dachten.

Wann Vibe Coding immer noch besser ist

SDD ist Overhead. Manchmal lohnt sich Overhead nicht.

Schnelle Skripte. Ein 50-Zeilen-Skript zum Umbenennen von Dateien oder Transformieren von JSON benötigt kein Anforderungsdokument. Schreiben Sie den Prompt, prüfen Sie die Ausgabe, liefern Sie es aus.

Experimente. Wenn Sie lernen, ob ein Ansatz machbar ist – eine API erkunden, eine Bibliothek testen, eine Hypothese validieren – benötigen Sie Geschwindigkeit, nicht Struktur. Experimentieren Sie zuerst, spezifizieren Sie, wenn das Experiment erfolgreich ist.

UI-Skizzen. Interaktionsdesign profitiert vom Sehen statt vom Spezifizieren. Bauen Sie schnell mehrere grobe Variationen, reagieren Sie auf das, was Sie sehen, und spezifizieren Sie nur das, was Sie tatsächlich ausliefern werden.

Entsorgbare Automatisierung. Einmalige Skripte, Datenimports, Migrationshilfen – die Kosten für ein leicht falsches Ergebnis sind normalerweise gering, und das Artefakt wird nach der Nutzung ohnehin gelöscht.

Solo-Prototypen. Wenn Sie die einzige Person sind, die diesen Code jemals sehen wird und das Ziel Lernen statt Produktion ist, ist Vibe Coding schneller und die Nachteile sind begrenzt.

Ein einfaches Entscheidungsframework

Die praktische Frage ist nicht „SDD oder Vibe Coding?“ Es ist „Wie viel Spezifikation brauche ich für diese spezifische Aufgabe?“

Verwenden Sie Vibe Coding, wenn:

  • Die Aufgabe weniger als einen Tag dauert
  • Sie erkunden oder lernen
  • Das Artefakt entsorgbar oder wenig bedeutsam ist
  • Sie die einzige Person sind, die dies berühren wird
  • Feedback-Geschwindigkeit wichtiger ist als Korrektheit

Verwenden Sie leichtgewichtiges SDD, wenn:

  • Die Aufgabe zwei oder mehr Tage dauert
  • Mehrere Dateien betroffen sind
  • Es explizite Sicherheits- oder Korrektheitsanforderungen gibt
  • Eine andere Person oder ein anderer Agent die Arbeit fortsetzen wird
  • Sie Tests schreiben müssen, die auf Anforderungen abbilden

Verwenden Sie volles SDD, wenn:

  • Das Feature eine öffentliche Schnittstelle oder einen Datenvertrag berührt
  • Mehrere Agenten oder Teammitglieder beteiligt sind
  • Die Organisation eine Design-Review vor der Implementierung erfordert
  • Compliance- oder Audit-Trails erforderlich sind

Der häufigste Fehler ist, volles SDD auf Aufgaben anzuwenden, die nur leichtgewichtiges SDD benötigen, und überhaupt keine Spezifikation auf Aufgaben anzuwenden, die mindestens eine leichtgewichtige benötigen.

Schlechtes SDD ist Waterfall mit Markdown. Gutes SDD ist kontrollierte Iteration mit dauerhaften Artefakten. Vibe Coding ist das richtige Werkzeug für die richtigen Aufgaben – und das falsche Werkzeug für die falschen. Die Kenntnis des Unterschieds ist die Fähigkeit.

Abonnieren

Neue Beiträge zu Systemen, Infrastruktur und KI-Engineering.