Von Vibe Coding zu Spec-Driven Development
Vier Wege, Software zu bauen – und was dabei vergessen wird.

Warum das Thema jetzt relevant ist

Die Tool-Landschaft hat sich in 18 Monaten komplett gedreht. Cursor, GitHub Copilot, Windsurf, Antigravity – jede Woche eine neue IDE, die verspricht, Code auf Zuruf zu liefern. Und sie liefern. Das ist nicht das Problem.

Das Problem ist, was danach passiert. Oder genauer: was nicht passiert. Wer in 20 Minuten ein Feature promptet, hat selten Lust, danach noch 2 Stunden Tests zu schreiben, Edge Cases zu prüfen und die Deployment-Pipeline zu pflegen. Die Geschwindigkeit der Code-Generierung hat eine gefährliche Asymmetrie geschaffen: Code entsteht in Minuten. Qualität entsteht in Stunden. Und diese Stunden werden gerade systematisch wegrationalisiert.

Grund genug, die vier gängigen Entwicklungsmethoden nebeneinander zu stellen – mit ihren Stärken, ihren blinden Flecken und der Frage, wo der SDLC auf der Strecke bleibt.

1. Traditional Development – Code First

Der Klassiker. Ein Entwickler hat eine Vorstellung im Kopf, öffnet die IDE und fängt an zu coden. Dokumentation kommt danach. Tests kommen, wenn noch Zeit ist. Die Reihenfolge ist linear und ehrlich: Intuition → Code → (hoffentlich) Docs → (irgendwann) Tests.

Das funktioniert, solange ein erfahrener Entwickler allein ein überschaubares Problem löst. Die Architektur lebt in seinem Kopf. Die Qualität hängt an seiner Disziplin.

Wo es bricht: Sobald Teams wachsen, wird implizites Wissen zum Risiko. Die Dokumentation hinkt der Realität hinterher. Tests decken den Happy Path ab, aber nicht die Randfälle. Und wenn der Entwickler das Projekt verlässt, geht die Architektur mit. Trotzdem: Traditional Development hat einen oft unterschätzten Vorteil – der Entwickler durchläuft den SDLC bewusst, auch wenn er Phasen abkürzt. Er weiß, dass er Testing schuldig bleibt. Bei KI-gestützten Methoden verschwindet dieses Bewusstsein.

2. Test-Driven Development – Tests First

TDD dreht die Reihenfolge: Erst definierst du als ausführbaren Test, was das System tun soll. Dann schreibst du den minimalen Code, der diesen Test bestehen lässt. Dann refactorst du. Red → Green → Refactor.

TDD erzwingt, dass du vor der Implementierung über Verhalten nachdenkst. Das allein ist wertvoll. Jede Zeile Code existiert, weil ein Test sie verlangt. Kein Bloat, keine toten Features.

Wo es bricht: TDD erfordert die Fähigkeit, testbar zu designen – eine Kompetenz, die Junior-Entwickler oft nicht mitbringen. In der Praxis scheitert TDD selten an der Idee, sondern am Alltag: Zeitdruck, Legacy-Code ohne Testinfrastruktur, Management, das Tests als „Overhead" abtut. Außerdem: TDD sagt dir, ob etwas funktioniert. Es sagt dir nicht, ob du das Richtige baust. Anforderungen, Architekturentscheidungen und Deployment – alles außerhalb des TDD-Zyklus.

3. Vibe Coding – Prompt, Ship, Repeat

Seit Andrej Karpathy den Begriff geprägt hat, ist Vibe Coding der Default-Modus im KI-Zeitalter: Du beschreibst, was du willst. Das LLM generiert Code. Du korrigierst per Follow-up-Prompt. Fertig. Oder eben nicht fertig – dann nochmal.

Für Prototypen, Exploration und Proof of Concepts ist das unschlagbar. Du weißt in 30 Minuten, ob eine Idee trägt. Dafür nutze ich es selbst ständig.

Wo es bricht: An allem, was nach dem ersten „Es funktioniert!" kommt. Vibe Coding hat keinen eingebauten Moment, in dem du über Edge Cases nachdenkst. Keinen Schritt, der dich zwingt, die Deployment-Strategie zu klären. Keinen Trigger für Security-Reviews, Performance-Tests oder Monitoring.

Und hier liegt die eigentliche Gefahr: Vibe Coding fühlt sich produktiv an, weil Code entsteht. Aber Code ist nicht das Produkt. Ein laufendes, getestetes, deploytes, wartbares System ist das Produkt. Zwischen „Code, der auf meinem Rechner funktioniert" und „System, das in Produktion zuverlässig läuft" liegen die Phasen, die beim Vibe Coding unter den Tisch fallen: QA, Staging, Rollback-Strategie, Observability. Cedric Clyburn (Red Hat) formuliert es trocken: „Vibe Coding überspringt den gesamten SDLC, den wir aus dem Engineering kennen."

Das wird solange kein Problem, wie man Wegwerf-Prototypen baut. Es wird dann zum Problem, wenn der Prototyp plötzlich in Produktion steht – und das passiert öfter, als irgendjemand zugibt.

4. Spec-Driven Development – Specs First, dann AI

Spec-Driven Development (SDD) versucht, den SDLC zurück in den KI-gestützten Workflow zu bringen. Die Idee: Man promptet keine Implementierung, sondern beschreibt Verhalten, Constraints und Akzeptanzkriterien. Daraus entsteht ein Anforderungsdokument. Aus dem Anforderungsdokument ein Design. Und erst nach bewusster Freigabe beginnt die Implementierung durch den KI-Agenten.

Der Vorteil gegenüber Vibe Coding: Reproduzierbarkeit. Die gleiche Spec liefert konsistente Ergebnisse. Und weil die Spec Testfälle enthält, entsteht die Qualitätssicherung nicht im Nachhinein, sondern als Teil der Definition.

Wo es bricht: SDD löst das Anforderungsproblem – aber auch nur das. Die Spezifikation deckt Planung und Design ab. Vielleicht noch Testing, wenn man Akzeptanztests mitdefiniert. Aber was ist mit Deployment? Monitoring? Rollback? Incident-Prozesse? Alles, was im SDLC nach der Implementierung kommt, liegt außerhalb der Spec. SDD verschiebt die Grenze dessen, was KI-gestützt sinnvoll abläuft – nach vorne, nicht aber nach hinten.

Außerdem: Der Upfront-Aufwand für eine gute Spezifikation ist real. Bei einem 2-Stunden-Feature lohnt sich das. Bei einer schnellen Bugfix-Session ist es Overhead, der die Geschwindigkeit zerstört, die KI-Agenten eigentlich bringen sollen.

Der blinde Fleck – und er betrifft alle vier

Software, die in Produktion läuft, verbringt 80 % ihres Lebens in der Maintenance-Phase. Keine der vier Methoden adressiert das systematisch.

KI beschleunigt die Code-Phase. Alles davor – Anforderungen, Design – erfordert weiterhin menschliches Denken. Alles danach – Deployment, Monitoring, Maintenance – erfordert weiterhin menschliche Sorgfalt. Beide Enden des SDLC werden gerade vergessen, weil die Mitte so aufregend schnell geworden ist.

Wann welcher Weg passt

Die ehrliche Antwort: Es kommt auf das Team, den Kontext und das Feature an.

Kleine Teams, die eng zusammenarbeiten, brauchen oft kein formales Spec-Dokument. Die Anforderungen leben in Gesprächen, die Architektur in den Köpfen der Beteiligten. Hier ist Traditional Development mit KI-Unterstützung häufig der effizienteste Weg: Ihr denkt nach, ihr wisst was ihr wollt, Cursor oder Copilot beschleunigen die Umsetzung. Vibe Coding ergänzt das für Exploration, Prototypen und schnelle Validierung – mit dem Bewusstsein, dass der Code danach bewusst gehärtet werden muss, wenn er in Produktion geht.

Spec-Driven Development entfaltet seinen Wert dort, wo implizites Wissen zum Risiko wird: In größeren Teams, bei der Übergabe komplexer Features an KI-Agenten, die autonom implementieren sollen, oder bei compliance-relevanten Anforderungen, die formal dokumentiert sein müssen. Wer einen Agenten ein Feature bauen lässt, ohne vorher zu definieren was genau entstehen soll, bekommt genau das: irgendetwas.

TDD bleibt der richtige Ansatz für kritische Business-Logik – dort, wo ein Bug Geld kostet oder Compliance-relevant ist.

Und der pragmatische Kern: Spec-Driven Development muss kein Zeremoniell sein. Kein 20-Seiten-Dokument, kein Enterprise-Prozess. Oft reichen 10 Zeilen in einer Markdown-Datei: Was soll passieren? Was sind die Edge Cases? Was ist das Akzeptanzkriterium? Der eigentliche Wert liegt nicht im Dokument, sondern im Moment des Nachdenkens vor dem ersten Prompt. Wer sich 5 Minuten Klarheit verschafft, bevor er eine Stunde promptet, spart am Ende drei Stunden Debugging.

Was dabei für alle Methoden gilt: Nach dem Merge ist vor der Arbeit. CI/CD, Staging, Smoke Tests, Monitoring, Alerting – das ist kein Overhead. Das ist der Unterschied zwischen Software und einem Skript auf dem Laptop.