Spezifikationsgetriebene Entwicklung vs. Vibe Coding: Waterfall?

Spezifikationen als Single Source of Truth oder langsame Zeremonie?

Inhaltsverzeichnis

Spec-Driven Development trat 2026 als die ernsthafte Antwort der Entwickler auf den Drift des Vibe Codings in Erscheinung.

Das Argument ist einfach: KI-Agenten liefern bessere und konsistentere Ergebnisse, wenn sie anhand einer geprüften Spezifikation implementieren, anstatt sich auf einen ad-hoc-Prompt zu stützen. Theoretisch schwer zu widerlegen.

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

Beide Seiten haben einen Punkt.

Spec-Driven Development versus Vibe Coding

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

Vibe Coding – die Praxis, einen lockeren Prompt zu schreiben und mit dem zu iterieren, was der KI-Agent produziert – funktioniert erstaunlich gut für kleine, explorative und Wegwerf-Projekte. In den ersten sechs Monaten des Jahres 2025 war es das dominante KI-Coding-Muster. Entwickler lieferten Skripte, Prototypen und einfache Tools schneller denn je.

Dann wuchsen die Projekte. Mehrdatei-Funktionen begannen zu driften. In der ersten Sitzung festgelegte Einschränkungen wurden in der dritten Sitzung vergessen. Sicherheitsannahmen gingen verloren. Architektonische Entscheidungen verschoben sich mitten in einer Funktionalität, weil der Agent kein dauerhaftes Gedächtnis für die Absicht hatte.

Spec-Driven Development (SDD) erschien als die disziplinierte Antwort. Die zentrale These: 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 aktuell.

GitHub Spec Kit, Kiro, Claude Code SDD-Workflows und BMAD, sowie andere Community-Gerüste wie Superpowers, sind allesamt Implementierungen dieser Idee. Die Tooling-Landschaft ist real. Das Interesse ist real. Der Backlash ist es auch.

Wofür Vibe Coding gut ist

Bevor man Vibe Coding abschafft, lohnt es sich, präzise zu sein, was es gut kann.

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

UI-Experimente. Visuelles Layout und das Gefühl von Interaktionen sind schwer im Voraus zu spezifizieren. Vibe Coding erlaubt es, Optionen schnell zu sehen, die meisten davon zu verwerfen und sich auf etwas zu einigen, das sich tatsächlich richtig anfühlt. Ein Anforderungsdokument hilft hier nicht.

Wegwerf-Automatisierung. Einmalige Skripte, Datenextraktions-Jobs, Migrationshelfer – diese benötigen selten ein Design-Dokument. Die Kosten, es leicht falsch zu machen, sind gering. Die Kosten eines langsamen, zeremoniellen Prozesses sind real.

Schnelles Feedback. Wenn man etwas schnell lernen muss – funktioniert diese API so, wie ich denke? – reduziert Vibe Coding den Lernzyklus auf Minuten. SDD würde das ohne Nutzen verlangsamen.

Der Fehler besteht darin, die Erfolgsmuster aus diesen Kontexten zu übernehmen und sie auf Produktions-Funktionalitäten mit echten Einschränkungen, echten Nutzern und echten Konsequenzen bei Fehlern anzuwenden.

Wo Vibe Coding scheitert

Vibe Coding degradiert vorhersehbar, wenn Umfang und Einsatz steigen.

Mehrdatei-Änderungen. Sobald eine Funktionalität fünf oder mehr Dateien berührt, verliert das Kontextfenster des Agenten den Überblick über Invarianten. Ohne ein Design-Dokument muss jeder Prompt den Kontext neu herstellen, der in einer vorherigen Sitzung etabliert und vergessen wurde.

Architektonischer Drift. Ohne explizite Nicht-Ziele implementieren Agenten Dinge. Der Agent fügt eine Caching-Schicht hinzu, weil sie vernünftig erscheint. Drei Sitzungen später ist die Caching-Annahme im Datendmodell verankert und ihre Entfernung ist kostspielig.

Vergessene Einschränkungen. „Nur authentifizierte Benutzer können dies auslösen“ ist ein Satz in einem Anforderungsdokument. In einer Vibe-Coding-Sitzung ist es etwas, das man einmal in der ersten Sitzung erwähnt hat und das der Agent in der vierten Sitzung nicht mehr erinnert, wenn er den neuen Endpunkt schreibt.

Versteckte Sicherheitsannahmen. Autorisierungsregeln, Grenzen der Eingabevalidierung, Geheimnisverwaltung – genau diese Art impliziter Anforderungen wird übersehen, wenn der Agent auf plausiblen, funktionierenden Code optimiert, anstatt auf korrekten, eingeschränkten Code.

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

Was Spec-Driven Development ändert

SDD behauptet nicht, Iteration zu eliminieren. Die guten Versionen von SDD sind explizit iterativ. Was sie ändern, ist der Ort, an dem 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 auf Code zu iterieren und Absicht aus Diffs abzuleiten, iteriert man auf der Spezifikation und implementiert dann. Die Spezifikation wird zum Artefakt, das festhält, was entschieden wurde, warum und was außerhalb des Geltungsbereichs liegt – erfüllt eine ähnliche Funktion wie Architektur-Entscheidungsprotokolle , ist aber auf die Intention der Funktionalität ausgerichtet, nicht auf systemweite Entscheidungen. Der Code implementiert diese Intention.

SDD durchläuft fünf Phasen – spezifizieren, planen, Aufgaben, implementieren, validieren – mit einem menschlichen Prüfpunkt an jedem Schritt. Siehe Spec-Driven Development Workflow Von Anforderungen zu Code für den vollständigen Prozess, Vorlagen und Prüfpunkte. Der Agent beteiligt sich an den meisten Phasen, aber Menschen prüfen die Artefakte, bevor die Implementierung beginnt. Dieser Prüfungsschritt ist der zentrale Unterschied zwischen SDD und Vibe Coding.

Warum Entwickler es Wasserfall nennen

Die Wasserfall-Kritik ist nicht falsch. Sie richtet sich nur gegen schlechtes SDD, nicht gegen SDD selbst.

Das spezifische Versagensmuster ist die lange Vorab-Planung. Das definierende Merkmal von Wasserfall ist eine Feedback-Schleife, die sich über Wochen oder Monate erstreckt: Anforderungsphase, Designphase, Build-Phase, Testphase, Auslieferung. Feedback kommt spät. Wenn man entdeckt, dass die Design-Annahme falsch war, hat man wochenlang darauf aufgebaut.

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

Ein HN-Kommentar beschrieb die Verwendung von Spec Kit für ein kleines CLI-Tool und stellte fest, dass es „zu langsam, zu viel Feinjustierung, bevor man Code sieht“ sei. Das ist die schlechte Version. Dieser Nutzer hatte recht, es für diese Aufgabe abzulehnen.

Die nützliche Kritik lautet nicht „Spezifikationen sind schlecht“. Sie lautet „lange Vorab-Planung vor Feedback ist schlecht“. Das sind unterschiedliche Behauptungen.

Der nützliche Mittelweg

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

Kleine Spezifikationen. Ein Anforderungsdokument für eine einzelne Funktionalität sollte auf einen Bildschirm passen. Wenn die Spezifikation zehn Seiten umfasst, handelt es sich entweder um ein Plattform-Design oder sie muss in kleinere Funktionalitäten aufgeteilt werden. Zu große Spezifikationen dauern zu lange zu prüfen und werden schnell veraltet.

Kurze Aufgaben-Slices. Jede Aufgabe sollte in einer einzelnen Agent-Sitzung implementierbar, als kleiner Diff prü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. Spezifiziere die erste Aufgabe, implementiere sie, validiere sie, und gehe dann zur nächsten Aufgabe über. Spezifiziere nicht alles, bevor du irgendetwas implementierst. Die erste Implementierung wird Dinge aufdecken, die deine Spezifikation falsch hatte. Aktualisiere die Spezifikation, bevor du weitermachst.

Lebende Spezifikation. Wenn die Realität vom Design abweicht – und sie wird – aktualisiere die Spezifikation, nicht nur den Code. Die Spezifikation ist nur nützlich, wenn sie widergibt, was tatsächlich gebaut wurde.

Tests als ausführbares Feedback. Jedes Akzeptanzkriterium sollte mindestens einem Test entsprechen. Die Test-Suite ist die maschinenlesbare Version der Spezifikation. Wenn die Spezifikation sagt „nur authentifizierte Benutzer können dies auslösen“, sollte es einen Test geben, der überprüft, dass nicht authentifizierte Anfragen abgelehnt werden.

Dieses Hybridmodell – kleine Spezifikationen, kurze Aufgaben, frühe Implementierung, lebende Dokumente – ist das, was tatsächlich funktioniert. Es ist weder Vibe Coding noch Wasserfall. Es ist kontrollierte Iteration mit dauerhaften Artefakten.

Wann SDD Vibe Coding schlägt

Verwenden Sie SDD – sogar leichtes SDD – wenn die Kosten, es falsch zu machen, real sind.

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

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

Multi-Agent-Workflows. Wenn mehrere Agenten verschiedene Teile einer Funktionalität implementieren, ist die Spezifikation die gemeinsame Single Source of Truth. Ohne sie optimieren 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 Refactors. Refactors, die Kernabstraktionen berühren, benötigen eine explizite Aussage darüber, was gleich bleiben muss (Verhalten) und was sich ändern darf (Struktur). Ohne das kann der Agent Verträge brechen, die man für erhalten hielt.

Wann Vibe Coding immer noch besser ist

SDD ist Overhead. Manchmal lohnt sich Overhead nicht.

Schnelle Skripte. Ein 50-Zeilen-Skript, um Dateien umzubenennen oder JSON zu transformieren, benötigt kein Anforderungsdokument. Schreibe den Prompt, prüfe die Ausgabe, liefere es aus.

Experimente. Wenn man lernt, ob ein Ansatz machbar ist – eine API erkunden, eine Bibliothek testen, eine Hypothese validieren – braucht man Geschwindigkeit, nicht Struktur. Experimentiere zuerst, spezifiziere, wenn das Experiment erfolgreich ist.

UI-Skizzen. Interaktionsdesign profitiert vom Sehen, nicht vom Spezifizieren. Baue schnell mehrere grobe Variationen, reagiere auf das, was du siehst, und spezifiziere nur das, was du tatsächlich ausliefern wirst.

Verfügbare Automatisierung. Einmalige Skripte, Datenimporte, Migrationshelfer – die Kosten eines leicht falschen Ergebnisses sind in der Regel gering, und das Artefakt wird nach der Nutzung ohnehin gelöscht.

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

Ein einfaches Entscheidungsframework

Die praktische Frage lautet nicht „SDD oder Vibe Coding?“. Sie lautet „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 Wegwerf oder niedrig riskant ist
  • Sie die einzige Person sind, die dies anfassen wird
  • Feedback-Geschwindigkeit wichtiger ist als Korrektheit

Verwenden Sie leichtes SDD, wenn:

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

Verwenden Sie volles SDD, wenn:

  • Die Funktionalität eine öffentliche Schnittstelle oder einen Datenvertrag berührt
  • Mehrere Agenten oder Teammitglieder beteiligt sind
  • Die Organisation eine Designprüfung vor der Implementierung erfordert
  • Compliance- oder Audit-Trails erforderlich sind

Der häufigste Fehler besteht darin, volles SDD auf Aufgaben anzuwenden, die nur leichtes SDD benötigen, und überhaupt keine Spezifikation auf Aufgaben anzuwenden, die zumindest ein leichtes benötigen. Welches Level Sie auch wählen, die Spezifikation bleibt nur nützlich, wenn etwas sie kontinuierlich mit dem Code abgleicht; Spezifikationen, Tests und Code in der KI-Entwicklung synchron halten deckt die Nachvollziehbarkeitsprüfungen ab, die erkennen, wenn eine Spezifikation stillschweigend veraltet.

Schlechtes SDD ist Wasserfall 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. Das Erkennen des Unterschieds ist die Fähigkeit.

Abonnieren

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