Spec-getriebene Entwicklung vs. Vibe Coding: Wasserfall?

Spezifikationen als Single Source of Truth oder langsame Zeremonie?

Inhaltsverzeichnis

Spec-getriebene Entwicklung (Spec-Driven Development, SDD) trat 2026 als die ernsthafte Antwort der Entwickler auf die Abweichung beim Vibe Coding auf.

Die Argumentation ist einfach: KI-Agenten produzieren bessere und konsistentere Ergebnisse, wenn sie gegen eine überprüfte Spezifikation implementieren, anstatt gegen einen ad-hoc-Prompt. Theoretisch schwer zu widerlegen.

In der Praxis nannte Hacker News dies „Waterfall Strikes Back“ (Der Wasserfall kehrt 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 auf alles zu iterieren, was der KI-Agent produziert – funktioniert für kleine, explorative und wegwerfbare Arbeiten bemerkenswert gut. In den ersten sechs Monaten des Jahres 2025 war es das vorherrschende Muster für KI-gestütztes Programmieren. Entwickler lieferten Skripte, Prototypen und einfache Tools schneller als je zuvor.

Dann wuchsen die Projekte. Mehrdatei-Features begannen zu driftieren. In Sitzung eins festgelegte Einschränkungen wurden in Sitzung drei vergessen. Sicherheitsannahmen wurden fallen gelassen. Architekturentscheidungen 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 gegen diese Artefakte Slice für Slice implementieren. Halten Sie die Spezifikation versioniert und aktualisiert.

GitHub Spec Kit, Kiro, Claude Code SDD-Workflows und BMAD, sowie andere community-basierte Gerüste, sind allesamt Implementierungen dieser Idee. Die Werkzeuge sind real. Das Interesse ist real. Auch die Gegenbewegung ist real.

Worin Vibe Coding gut ist

Bevor man Vibe Coding abschlägt, lohnt es sich, genau zu sein darüber, was es gut kann.

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 zu wissen, was spezifiziert werden soll. Wenn Sie es noch nicht wissen, sind Spezifikationen vorzeitg.

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

Wegwerf-Automatisierung. Einmal-Skripte, Datenextraktionsjobs, Migrationshilfen – 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 Sie etwas schnell lernen müssen – funktioniert diese API so, wie ich denke? – kürzt Vibe Coding den Lernzyklus auf Minuten. SDD würde das ohne Nutzen verlangsamen.

Der Fehler besteht darin, die Erfolgsmuster aus diesen Kontexten zu nehmen und sie auf Produktionsfeatures mit echten Einschränkungen, echten Nutzern und echten Konsequenzen für Fehler anzuwenden.

Wo Vibe Coding zusammenbricht

Vibe Coding verschlechtert sich vorhersehbar, wenn Umfang und Risiken steigen.

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

Architektonische Drift. Ohne explizite Nicht-Ziele implementieren Agents Dinge. Der Agent fügt eine Cache-Schicht hinzu, weil das vernünftig erscheint. Drei Sitzungen später ist die Cache-Annahme im Datenmodell verankert und ihr Entfernen 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 Sie in Sitzung einmal erwähnt haben und das der Agent in Sitzung vier nicht mehr erinnert, wenn er den neuen Endpunkt schreibt.

Verborgene Sicherheitsannahmen. Autorisierungsregeln, Eingabevalidierungsgrenzen, Handhabung von Secrets – dies sind genau die Art impliziter Anforderungen, die übersehen werden, wenn der Agent nach plausiblen, funktionierenden Code optimiert, anstatt nach korrektem, eingeschränktem Code.

Team-Übergabe. Wenn Sie es durch iteratives Prompting gebaut haben, ist das Artefakt, das aufzeichnet, 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, 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 auf Code zu iterieren und Absicht aus Diffs abzuleiten, iterieren Sie auf der Spec und implementieren dann. Die Spec wird zum Artefakt, das aufzeichnet, was entschieden wurde, warum und was außerhalb des Scopes liegt – und erfüllt eine ähnliche Funktion wie Architektur-Entscheidungsprotokolle aber orientiert an Feature-Absicht statt an systemweiten Entscheidungen. Der Code implementiert diese Absicht.

SDD läuft durch fünf Phasen – spezifizieren, planen, Aufgaben, implementieren, validieren – mit einer menschlichen Review-Schleuse bei jedem Schritt. Siehe Spec-Driven Development Workflow von Anforderungen zu Code für den vollständigen Prozess, Vorlagen und Kontrollpunkte. Der Agent beteiligt sich an den meisten Phasen, 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 zielt nur auf schlechtes SDD, nicht auf SDD selbst.

Das spezifische Versagensmuster ist lange Vorausplanung. Das definierende Merkmal von Waterfall ist eine Feedback-Schleife, die sich über Wochen oder Monate erstreckt: Anforderungsphase, Designphase, Bauphase, Testphase, Veröffentlichung. Feedback kommt spät an. Bis Sie entdecken, dass die Designannahme falsch war, haben Sie Wochenlang 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 irgendetwas berührt, ist das Waterfall. Es ist Waterfall mit Markdown statt UML, aber das Versagensmuster ist identisch.

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

Die nützliche Kritik ist nicht „Specs sind schlecht“. Es ist „Lange Vorausplanung vor Feedback ist schlecht.“ Das sind unterschiedliche Behauptungen.

Der nützliche Mittelweg

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

Kleine Specs. Ein Anforderungsdokument für ein einzelnes Feature sollte auf einen Bildschirm passen. Wenn die Spec zehn Seiten lang ist, ist es entweder ein Plattform-Design oder es muss in kleinere Features zerlegt werden. Specs, die zu groß sind, brauchen zu lange zur Überprüfung und werden schnell veraltet.

Kurze Aufgaben-Slices. Jede Aufgabe sollte in einer einzigen Agent-Sitzung implementierbar, als kleiner Diff überprüfbar und isoliert testbar sein. Wenn Aufgaben zu groß sind, dehnt sich der Implementierungszyklus und die Zuordnung von Spec 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. Spezifizieren Sie nicht alles, bevor Sie irgendetwas implementieren. Die erste Implementierung wird Dinge aufdecken, die Ihre Spec falsch hatte. Aktualisieren Sie die Spec, bevor Sie fortfahren.

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

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

Dieser Hybrid – kleine Specs, 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 schlägt

Verwenden Sie SDD – sogar leichtgewichtiges SDD – wenn die Kosten für Fehler real sind.

Risikoreiche Geschäftslogik. Abrechnung, Berechtigungen, Datenmigrationen, Idempotenz – jede Logik, bei der inkorrektes Verhalten teuer oder schwer umkehrbar 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 Aufrufe bricht.

Multi-Agent-Workflows. Wenn mehrere Agenten verschiedene Teile eines Features implementieren, ist die Spec die gemeinsame Single Source of Truth. Ohne sie optimieren die Agenten 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 Spec 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 das kann der Agent Verträge brechen, die Sie als erhalten dachten.

Wann Vibe Coding immer noch besser ist

SDD ist Overhead. Manchmal ist Overhead es nicht wert.

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.

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

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

Wegwerf-Automatisierung. Einmal-Skripte, Datenimports, Migrationshilfen – die Kosten eines leicht falschen Ergebnisses sind normalerweise gering, und das Artefakt wird nach der Verwendung sowieso gelöscht.

Solo-Prototypen. Wenn Sie die einzige Person sind, 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 ist nicht „SDD oder Vibe Coding?“. Es ist „wie viel Spec 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 wegwerfbar oder von geringer Bedeutung 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
  • Explizite Sicherheits- oder Korrektheitsanforderungen bestehen
  • 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 die Anwendung von vollem SDD auf Aufgaben, die nur leichtgewichtiges SDD benötigen, und die Anwendung von keiner Spec auf Aufgaben, die mindestens eine leichtgewichtige benötigen. Welches Level Sie auch wählen, die Spec bleibt nur nützlich, wenn etwas sie ständig gegen den Code überprüft; Specs, Tests und Code in der KI-Entwicklung synchron halten deckt die Nachverfolgungsprüfungen ab, die eine leise veraltende Spec einfangen.

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 Unterscheidung zu kennen, ist die Fähigkeit.

Abonnieren

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