Es gibt diesen Moment am Anfang eines neuen Features, wo alles noch offen ist. Kein Legacy-Code, keine Constraints, keine unerwarteten Abhängigkeiten. Nur du, ein leeres Verzeichnis und ein AI-Tool, das dir verspricht, in Minuten Ergebnisse zu liefern.
In solchen Momenten ist Vibe Coding unglaublich verführerisch. Einfach anfangen. Prompt rein, Code raus, nächster Prompt. Kein Planen, kein Spezifizieren, kein Nachdenken über Architektur. Einfach machen.
Ich habe das gemacht. Ich habe dafür bezahlt.
Was Vibe Coding wirklich bedeutet
Der Begriff "Vibe Coding" – geprägt von Andrej Karpathy – beschreibt einen Ansatz, bei dem man AI-Tools nutzt, ohne vorher klar definiert zu haben, was man eigentlich baut. Kein Schema, kein Design System, keine expliziten Regeln. Man "vibed" sich durch das Feature.
Das ist nicht grundsätzlich falsch. Für einen schnellen Prototyp, eine Wegwerf-Demo, eine erste Machbarkeitsprüfung funktioniert es gut. Man hat in einer Stunde etwas Laufendes auf dem Bildschirm. Das Gefühl ist großartig.
Das Problem kommt später.
Die Rechnung
In den vergangenen Monaten habe ich Projekte gesehen – eigene und fremde – die mit Vibe Coding gestartet wurden. Das Muster ist immer ähnlich: Der erste Sprint läuft erstaunlich flüssig. Dann kommen Sprint zwei und drei. Und plötzlich kämpft man mit Code, der technisch funktioniert, aber architektonisch ein Chaos ist.
Konkret: Komponenten, die zu viel wissen. Zustandsverwaltung, die sich über drei verschiedene Ansätze verteilt, weil die AI bei jedem Prompt einen anderen Weg gewählt hat. Inkonsistente Benennung. Duplizierter Code, weil die AI beim zweiten Prompt nicht wusste, dass sie beim ersten schon etwas Ähnliches gebaut hat.
Und das Schlimmste: Wenn man versucht, das nachträglich zu reparieren, kämpft man nicht gegen die AI – man kämpft gegen die kumulierten Entscheidungen von zwanzig vorherigen Prompts, die alle lokal sinnvoll, aber global inkonsistent waren.
Wer als Senior-Entwickler oder Freelancer mit echtem Architektur-Einfluss arbeitet, merkt das besonders schnell. Man hat die Erfahrung, um zu sehen, wo es hinläuft. Und diese Erfahrung sagt einem: Das wird teuer.
Der Unterschied, den Spezifikation macht
Wer Kontext-Engineering: Warum dein Prompt das kleinste Problem ist und Das Ticket als Denkwerkzeug – bevor die erste Zeile Code entsteht aus dieser Serie kennt, wird das Muster erkennen: CLAUDE.md für den Gesamtkontext, Ticket für den Task-Kontext. Spec-Driven Development ist die Anwendung desselben Gedankens auf Architektur-Ebene.
Das Prinzip ist simpel: Bevor ich die AI auch nur einen Prompt schreiben lasse, habe ich definiert, was ich baue, wie es aufgebaut sein soll und nach welchen Regeln der Code geschrieben wird. Nicht als hundert Seiten Pflichtenheft, sondern als lebendiges Dokument – eine CLAUDE.md, eine Komponenten-Bibliothek, ein explizites Design System.
Was sich dadurch ändert: Die AI trifft keine Architektur-Entscheidungen mehr. Die habe ich vorher getroffen. Sie setzt sie um.
Das ist der entscheidende Shift. Vibe Coding lässt die AI entscheiden, welchen Weg sie nimmt. Spec-Driven Development sagt ihr, welchen Weg sie nehmen soll.
Wie das in der Praxis aussieht
Ein konkretes Beispiel aus meiner eigenen Website. Als ich den Blog-Bereich gebaut habe, hatte ich zwei Optionen:
Option A – Vibe: Claude Code sagen "bau mir einen Blog" und schauen, was kommt.
Option B – Spec: Zuerst definieren, welche Frontmatter-Felder ein Blog-Post braucht, welche Komponenten verwendet werden, wie das Routing aussieht, wie i18n integriert wird – und dann Claude Code die Implementierung überlassen.
Ich habe Option B gewählt. Das Ergebnis war konsistenter Code, weniger Überarbeitungen, und ich musste nie erklären "nein, nicht so" – weil "so" von Anfang an klar war.
Die Spezifikation als Single Source of Truth
# CLAUDE.md
## Frontmatter-Schema
title, slug, translationSlug, date, category, description, readingTime, tags, featured, draft
## Komponenten
- GbCard: default / project / highlight variants
- GbButton: primary / ghost / cta-inverted variants
- Kein neues Markup, bevor bestehende Komponenten geprüft wurden
## Coding Rules
- Composition API only
- Tailwind only
- Keine hardcodierten Texte
Das klingt nach Bürokratie. Aber es ist das Gegenteil davon: Es ist die Grundlage, auf der ich schnell arbeiten kann, ohne ständig zurückzuschauen.
Was das für Senior-Entwickler und Freelancer bedeutet
Ich glaube, Vibe Coding ist besonders dann ein Problem, wenn man – wie ich – als Freelancer arbeitet und die volle Architektur-Verantwortung trägt. Als Junior-Entwickler in einem großen Team gibt es Leitplanken: bestehende Codebasen, Teamkonventionen, Architekten, die Entscheidungen treffen. Die Struktur ist bereits da – man arbeitet einfach darin.
Als Freelancer bist du selbst der Architekt. Wenn du die Struktur nicht definierst, definiert sie niemand – und dann "definiert" die AI sie implizit, Prompt für Prompt. Das klingt effizienter als es ist.
Die eigentliche Stärke von AI-Tools liegt nicht darin, dass sie schnell Code schreiben können. Sie liegt darin, dass sie innerhalb klarer Grenzen konsistent und zuverlässig arbeiten. Diese Grenzen muss ein Mensch ziehen.
Der Kompromiss, den ich gefunden habe
Ich schreibe das nicht, weil ich Vibe Coding für grundsätzlich falsch halte. Manchmal ist ein schneller Prototyp genau das Richtige. Ein Wegwerf-Experiment, ein Proof of Concept für einen Kunden, eine Feature-Demo – da kann man vibed.
Aber sobald etwas in Production geht, sobald andere Entwickler daran weiterarbeiten sollen, sobald Wartbarkeit eine Rolle spielt: dann brauche ich die Spezifikation zuerst.
Der Unterschied in meinem Alltag: Prototypen vibe ich manchmal. Projekte spec ich immer.
Was passiert, wenn auch mit guter Spezifikation Fehler auftauchen – weil der Kontext zwar dokumentiert, aber falsch ist, oder weil die AI trotzdem einen impliziten Annahme verletzt – das schaue ich mir im nächsten Post an.
Vibe Coding gibt dir schnell etwas Laufendes. Spec-Driven Development gibt dir etwas, das läuft – und das auch noch in sechs Monaten jemand versteht.