Von Vibe Coding zu Spec-Driven Design: Warum Ihre KI-Projekte Besseres verdienen

«Vibe Coding hat uns begeistert. Spec-Driven Design bringt uns in die Produktion.»

Wer KI-Coding-Assistenten ernsthaft einsetzt, kennt die wiederkehrenden Frustrationen: Die KI erfindet Anforderungen, die niemand gestellt hat, überschreibt funktionierenden Code, den sie nicht anfassen sollte, oder passt Test-Assertions an, damit sie grün werden — anstatt die eigentliche Implementierung zu reparieren. Das sind keine Randphänomene. Das sind strukturelle Probleme — und sie haben dieselbe Wurzel: Es gibt keine Source of Truth, die die Arbeit zur Verantwortung ziehen kann.

Am Anfang steht die Einschränkung

Andrej Karpathy prägte 2025 den Begriff «Vibe Coding» für eine Art KI-gestützter Entwicklung, bei der man locker promptet, Vorschläge grosszügig annimmt und schnell iteriert — grossartig für Prototypen, wirklich aufregend, aber strukturell fragil für alles, was Produktion überleben muss.

Die Probleme verstärken sich mit der Komplexität:

Erfundene Anforderungen. Man fragt nach einem Login-Formular und bekommt Passwort-Stärke-Anzeigen, Kontowiederherstellungsflüsse und E-Mail-Verifikation — alles plausibel, nichts davon verlangt. Bis man es bemerkt, ist der Code bereits in den Rest des Features verwoben.

Instabiler Code. Zwischen Sessions hat die KI keine Erinnerung daran, was schon fertig ist. Sie überschreibt abgeschlossene Features nicht aus Böswilligkeit, sondern aus Unwissenheit — sie hat keine Möglichkeit zu wissen, dass die frühere Arbeit erledigt und funktionsfähig war.

Korrumpierte Tests. Wenn ein Test fehlschlägt, hat die KI zwei gleichwertige Optionen: die Implementierung reparieren oder die Assertion anpassen. Ohne eine Spec, die die Intention verankert, nimmt sie oft den Weg des geringsten Widerstands — und man verliert das Sicherheitsnetz, ohne es zu merken.

Verlorener Kontext. In einem mehrwöchigen Projekt werden früh etablierte Einschränkungen in späteren Sessions leise neu interpretiert. Die Abweichung ist subtil genug, um sie zu übersehen — bis es teuer wird.

Specs als Context Engineering

Die produktivste Verschiebung ist, Spezifikationen nicht als bürokratischen Overhead zu verstehen, sondern als Context Engineering — die bewusste Arbeit, strukturierte, persistente Artefakte zu schaffen, die die Qualität des Inputs für den KI-Assistenten verbessern.

Eine Spec muss kein formales Dokument sein. Es kann ein PRD sein, eine Menge User Stories, ein Architecture Decision Record, ein API-Vertrag oder eine einfache Markdown-Datei, die definiert, wie «fertig» für ein Feature aussieht. Das Format ist weniger wichtig als die Disziplin: Intention so festhalten, dass sie die aktuelle Konversation überdauert.

Wenn man Was und Warum schreibt, bevor man nach dem Wie fragt, ist der Output der KI im ersten Anlauf konsistent besser. Und wenn er es nicht ist, geben die Akzeptanzkriterien etwas Konkretes, auf das man zeigen kann — «Das entspricht nicht der Spec» ist eine viel wirkungsvollere Korrektur als «Das ist irgendwie nicht ganz richtig.»

So sieht das in der Praxis aus

Statt fünf Korrekturschleifen verbringt man eine Stunde damit, ein fokussiertes Dokument zu schreiben: Was das Feature tut, was es explizit nicht tut, welche Einschränkungen gelten und wie korrektes Verhalten aussieht. Dieses Dokument übergibt man der KI, bevor eine einzige Zeile Code geschrieben wird.

Der Aufwand vorab ist real — etwa eine Stunde pro substanziellem Feature. Aber er ersetzt drei bis vier Stunden Korrekturschleifen und produziert ein Artefakt, das weiterverwendet werden kann: für Onboarding, für Code Reviews, für die nächste KI-Session, die sonst von vorne anfangen würde.

Werkzeuge für Spec-Driven Development

Mehrere Frameworks haben sich herausgebildet, um diesen Ansatz zu formalisieren:

• Taproot — repository-basierte Anforderungen mit strukturierter Hierarchie und Rückverfolgbarkeit von der Intention bis zur Implementierung
• BMAD — Multi-Agent-Framework mit spezialisierten Personas für verschiedene Phasen
• GitHub Spec Kit — CLI mit einer Projekt-«Verfassung»
• Amazon Kiro — VS-Code-Extension mit nativem Spec-Modus
• Tessl — Spec als gepflegtes Artefakt mit vollständiger Code-Generierung

Man braucht keines davon, um anzufangen. Eine persistente Kontextdatei — CLAUDE.md für Claude, ein System-Prompt für andere — die Projekt-Constraints und Konventionen festhält, bringt einen bereits den grössten Teil des Weges dorthin.

Das ist kein Wasserfall

Der häufigste Einwand: «Ist das nicht einfach Wasserfall?» Nein — und der Unterschied ist wichtig.

Wasserfall setzt voraus, dass man alles korrekt vorab spezifizieren kann. Spec-Driven Development setzt voraus, dass man das nicht kann — Specs entwickeln sich, und das ist in Ordnung. Der Unterschied: Änderungen werden bewusst nachverfolgt und weitergegeben, anstatt im Chat-Verlauf verloren zu gehen. Das ist näher am ursprünglichen Geist von Agile: Specs als lebende Verträge zwischen Stakeholdern und Entwicklern — jetzt erweitert um die KI als dritten Vertragspartner.

Ein Einstiegspunkt

Wer noch nicht bereit ist, ein Framework zu adoptieren, sollte zuerst das Prinzip testen. Ein Feature auswählen, das momentan mehrere Korrekturschleifen benötigt. Dreissig Minuten aufwenden, um aufzuschreiben: Was gebaut wird, was explizit nicht gebaut wird, welche Einschränkungen gelten und wie «fertig» aussieht. Dann dieses Dokument der KI übergeben — vor allem anderen.

Die Ergebnisse sind meist aufschlussreich.

Die besten KI-Ingenieure des Jahres 2026 werden nicht die besten Prompter sein. Es werden diejenigen sein, die begriffen haben, dass eine gute Spec der wirkungsvollste Input ist, den man einer KI geben kann.