Vibe-Coding vs. Spec-driven Development: Was funktioniert besser?

Vibe-Coding und Spec-driven Development sind gerade die zwei dominierenden Philosophien beim KI-gestützten Programmieren – und sie könnten kaum unterschiedlicher sein. Hier lernst du, was hinter beiden Ansätzen steckt, welche Tools du kennst und wann du welchen Ansatz wählen solltest.

Was ist Vibe-Coding?

Den Begriff hat Andrej Karpathy (Ex-Tesla-KI-Chef, Ex-OpenAI) Anfang 2025 geprägt: Du beschreibst einer KI auf natürliche Sprache, was du bauen willst – und lässt sie einfach machen. Kein Spec, kein Architecture-Review, kein langer Planungsprozess. Du „vibrierst“ mit der KI auf einer Idee und schaust, was rauskommt.

Das klingt nach Chaos, funktioniert aber erstaunlich gut für:

• Prototypen und MVP-Builds, die schnell fertig sein müssen
• Persönliche Projekte ohne Team und ohne Deadline
• Nicht-Entwickler, die eine Idee in Code umsetzen wollen
• Experimente, bei denen das Ergebnis erst die Richtung klärt

Das Schlagwort „Vibe-Coding“ beschreibt also kein spezifisches Tool, sondern eine Haltung: Vertrauen in die KI, wenig Vorab-Planung, iteratives Vorgehen. Ein Paradebeispiel dafür, wie das in der Praxis aussieht, zeigt unser Artikel Vibe-Coding im Einsatz: WordPress mit Telex bauen.

Eine der beliebtesten Vibe Coding Umgebungen ist Lovable. Man beschreibt der KI einfach, was man erstellen will. Lovable erstellt und mit wenigen Klicks kann die Anwendung live gestellt und genutzt werden.

Was ist Spec-driven Development?

Spec-driven Development (oder Spec-driven Design) dreht den Prozess um: Zuerst wird eine präzise Spezifikation geschrieben – eine Art technischer Blueprint – und erst danach übernimmt die KI die Implementierung. Die KI arbeitet also nicht ins Blaue, sondern gegen eine klare Anforderung.

Eine Spec enthält typischerweise:

• Das genaue Ziel und den Scope des Features
• Inputs, Outputs, Datenstrukturen
• Edge Cases und Fehlerzustände
• Akzeptanzkriterien (wann gilt das Feature als fertig?)
• Abhängigkeiten zu anderen Systemteilen

So sieht eine typische Spec in der Praxis aus – in diesem Fall für einen Newsletter-Signup-Endpunkt:

# Spec: Newsletter-Signup Endpoint

## Ziel
POST /api/subscribe – nimmt eine E-Mail-Adresse entgegen
und speichert sie in der Datenbank.

## Inputs
- email (string, required) – muss valides E-Mail-Format haben
- source (string, optional) – woher kommt der Signup?
  Werte: "footer" | "popup" | "artikel"

## Outputs
- 200 OK  → { success: true, message: "Danke fuer dein Signup!" }
- 400 Bad Request → { error: "Ungueltige E-Mail-Adresse" }
- 409 Conflict   → { error: "E-Mail bereits registriert" }

## Datenbank
Tabelle: subscribers
Felder:  id, email, source, created_at, confirmed (boolean, default: false)

## Edge Cases
- Leere E-Mail        → 400
- Doppelte E-Mail     → 409, kein Duplikat anlegen
- Kein @-Zeichen      → 400
- source fehlt        → als NULL speichern, kein Fehler

## Akzeptanzkriterien
- [ ] Neue E-Mail wird korrekt in DB gespeichert
- [ ] Doppelte E-Mails werden mit 409 abgelehnt
- [ ] Alle Fehlerfaelle liefern strukturiertes JSON
- [ ] Unit-Tests fuer alle Edge Cases vorhanden

Das ist eine Spec, die jeder KI-Coding-Agent – ob Claude Code, Codex oder Devin – direkt umsetzen kann, ohne rückfragen zu müssen. Vergleich das mit dem Vibe-Coding-Äquivalent: „Bau mir einen Newsletter-Signup.“ – was gut starten kann, aber oft zu Rückfragen, falschem Scope oder fehlenden Edge Cases führt.

Das ist näher an klassischer Software-Entwicklung – nur dass statt eines menschlichen Entwicklers eine KI nach der Spec implementiert. Gutes Prompt-Engineering ist dabei entscheidend: Je präziser die Spec, desto besser der Output. Unser Prompt Engineering Guide hilft dir dabei, klare Spezifikationen zu formulieren.

Die wichtigsten Tools im Überblick

Beide Ansätze haben inzwischen ein breites Tool-Ökosystem. Hier eine Übersicht, damit du sofort weißt, wo du einsteigen kannst:

Vibe-Coding Tools

Diese Tools sind darauf ausgelegt, dass du einfach loslegst – keine Konfiguration, kein Spec-Dokument vorab:

• Bolt.new (StackBlitz) – Browser-basiert, kein Setup nötig. Prompt eingeben, App läuft sofort im Browser. Ideal für Web-Apps und schnelle Prototypen.
• Lovable – Prompt-to-App-Plattform. Beschreibe deine App in natürlicher Sprache, Lovable baut sie – inklusive Supabase-Backend und Deployment.
• v0 (Vercel) – Spezialisiert auf UI-Komponenten. Perfekt um schnell React-Komponenten aus einer Beschreibung zu generieren, direkt deploybar auf Vercel.
• Replit Agent – Browser-IDE mit eingebettetem KI-Agenten. Gut für einfache Web-Projekte ohne lokales Setup, direkt im Browser ausführbar.
• Cursor / Windsurf – KI-IDEs, die beide Stile unterstützen. Im Vibe-Modus: einfach im Chat beschreiben, die KI ändert direkt den Code im Editor.
• Claude Cowork (Anthropic) – Desktop-App für Nicht-Entwickler. Kombiniert File-Zugriff, Skills und KI-Agenten ohne Terminal – ideal für Content-Teams und Marketer.

Spec-driven Tools

Diese Tools arbeiten besser – oder ausschließlich – wenn du ihnen klare Anforderungen und Kontext mitgibst:

• GitHub Copilot Workspace – Wandelt GitHub Issues automatisch in Spec → Plan → Code → Pull Request um. Der sauberste Spec-driven-Workflow direkt in GitHub.
• Claude Code (Anthropic) – CLI-Tool mit CLAUDE.md als persistenter Projekt-Spec. Stark für komplexe, lokale Setups und Teams. Auch per Slack steuerbar.
• OpenAI Codex – Async Cloud-Agent. Bekommt eine Task-Beschreibung, klont das Repo, schreibt Code und erstellt einen Pull Request – ohne dass du dabei sein musst.
• Devin (Cognition AI) – Der erste „autonome Software-Ingenieur“. Plant selbständig Teilschritte, sucht Dokumentation, debuggt – braucht aber eine klare Aufgabenbeschreibung als Startpunkt.
• Jules (Google) – Async GitHub-Agent ähnlich wie Codex. Bekommt ein Issue, arbeitet es asynchron ab und erstellt einen PR – direkt integriert in Google-Workflows.
• Aider – Open-Source CLI-Tool. Liest gezielt einzelne Dateien als Kontext (deine De-facto-Spec) und ändert nur diese. Sehr präzise und kontrollierbar.
• Cline – VS-Code-Extension mit Agenten-Modus. Liest CLAUDE.md– und andere Spec-Dateien und arbeitet systematisch durch komplexe, mehrstufige Tasks.

Vibe-Coding vs. Spec-driven: Der direkte Vergleich

Kriterium	Vibe-Coding	Spec-driven Design
Geschwindigkeit (Start)	Sehr schnell – sofort loslegen	Langsamer – Spec-Writing braucht Zeit
Code-Qualität	Variabel, oft technische Schulden	Konsistenter, wartbarer
Geeignet für	Solo-Projekte, Prototypen, Experimente	Teams, Production-Code, komplexe Systeme
KI-Kontrolle	Niedrig – KI entscheidet viel selbst	Hoch – KI arbeitet im definierten Rahmen
Lernkurve	Minimal	Mittel – Spec-Writing ist eine Skill
Typische Tools	Bolt.new, Lovable, v0, Replit, Cursor, Windsurf, Claude Cowork	GitHub Copilot Workspace, Claude Code, Codex, Devin, Jules, Aider, Cline

Wann solltest du welchen Ansatz wählen?

Wähl Vibe-Coding wenn:

• Du eine Idee schnell validieren willst (weniger als 1-2 Tage)
• Du alleine arbeitest und der Code nur für dich ist
• Das Projekt weggeworfen werden kann, wenn es nicht funktioniert
• Du kein Entwickler bist und einfach etwas zum Laufen bringen willst

Wähl Spec-driven Development wenn:

• Mehrere Personen (oder mehrere KI-Agenten) am gleichen Projekt arbeiten
• Der Code in Produktion geht und gewartet werden muss
• Du Features in ein bestehendes System integrierst
• Nachvollziehbarkeit und Reviews wichtig sind (z.B. für Kunden)

In der Praxis nutzen die besten Entwickler heute beide Ansätze kombiniert: Vibe-Coding für den ersten Entwurf, Spec-driven für die saubere Implementierung. Wie Cursor 2 zeigt, gehen moderne KI-IDEs bereits in diese Richtung – mit integrierten Agent-Modi für beide Workflows.

FAQ: Vibe-Coding & Spec-driven Development

Was bedeutet „Vibe-Coding“ konkret?

Du beschreibst einer KI in natürlicher Sprache, was du bauen willst – ohne vorab eine technische Spezifikation zu schreiben. Die KI iteriert mit dir, bis das Ergebnis stimmt. Der Begriff wurde 2025 von Andrej Karpathy geprägt und beschreibt eher eine Haltung als eine Methode.

Kostet Claude Code etwas?

Claude Code benötigt ein Anthropic-API-Konto. Die Kosten hängen vom genutzten Modell und der Menge der verarbeiteten Tokens ab. Es gibt keinen separaten Claude-Code-Preis – du zahlst für die API-Nutzung. Claude Cowork ist Teil der Claude-Desktop-App und wird über Claude-Abonnements abgedeckt.

Was ist der Unterschied zwischen Codex und Claude Code?

Beide sind KI-Coding-Agenten, die selbständig arbeiten können. OpenAI Codex läuft vollständig in der Cloud (kein lokales Setup nötig), arbeitet asynchron und ist tief in GitHub integriert. Claude Code läuft als CLI lokal bei dir und hat direkten Zugriff auf deine Dateien und dein Terminal – dadurch ist es flexibler bei komplexen, lokalen Setups.

Ist Spec-driven Development nur etwas für erfahrene Entwickler?

Nicht unbedingt. Eine gute Spec ist im Kern eine präzise Aufgabenbeschreibung – das können auch Nicht-Entwickler schreiben. Mit Tools wie GitHub Copilot Workspace oder Claude Code (plus CLAUDE.md) wird der Einstieg deutlich einfacher, weil die KI beim Strukturieren der Spec hilft.

Welcher Ansatz ist besser für Teams?

Für Teams ist Spec-driven Design fast immer die bessere Wahl. Specs sind dokumentierbar, reviewbar und ermöglichen paralleles Arbeiten – auch wenn mehrere KI-Agenten gleichzeitig an verschiedenen Features arbeiten. Vibe-Coding im Team führt schnell zu inkonsistentem Code und schwer nachvollziehbaren Entscheidungen.

Mehr erfahren: Vibe-Coding & Spec-driven Development

• Andrej Karpathy: Der Original-Tweet, der Vibe-Coding bekannt gemacht hat – Der Tweet vom Februar 2025, der alles auslöste. Karpathy beschreibt in wenigen Sätzen, was Vibe-Coding ist und warum es genau jetzt möglich wird.
• Simon Willison: Not all AI-assisted programming is vibe coding – Eine der besten Analysen zum Thema. Willison differenziert klar, wo Vibe-Coding aufhört und wo andere Formen des KI-gestützten Programmierens anfangen.
• Towards Data Science: From Vibe Coding to Spec-Driven Development – Der direkte Brückenartikel zwischen beiden Konzepten – erklärt, warum Vibe-Coding ein guter Einstieg ist, aber Spec-driven Development der logische nächste Schritt.
• Thoughtworks: Spec-driven Development – Unpacking one of 2025’s key practices – Thoughtworks beleuchtet SDD aus der Enterprise-Perspektive und zeigt, wie Teams die Methode in bestehende Agile-Prozesse integrieren können.
• Martin Fowler: Understanding Spec-Driven Development – Kiro, Spec-Kit und Tessl – Software-Architektur-Legende Martin Fowler analysiert die konkreten Tools hinter SDD – inklusive GitHub Spec Kit – und zeigt, wie sie sich voneinander unterscheiden.

Fazit

Vibe-Coding und Spec-driven Design sind keine Feinde – sie sind Werkzeuge für unterschiedliche Situationen. Für schnelle Ideen und Prototypen ist Vibe-Coding unschlagbar. Für alles, das längerfristig besteht und im Team weiterentwickelt wird, lohnt sich die Investition in eine saubere Spec.

Die gute Nachricht: Tools wie Claude Code, GitHub Copilot Workspace und Codex machen Spec-driven Development heute so zugänglich, dass der Mehraufwand immer kleiner wird. Der beste Workflow ist meistens ein Mix – und den kannst du schon heute ausprobieren.