Vibe Coding beschreibt eine Arbeitsweise, bei der Software überwiegend durch Beschreiben in natürlicher Sprache entsteht: Man formuliert, was das Programm tun soll, ein Sprachmodell schreibt den Code, man schaut sich das Ergebnis an und beschreibt die nächste Änderung. Der Quelltext wird dabei nicht Zeile für Zeile gelesen und verstanden, sondern am Verhalten beurteilt. Geprägt hat den Begriff der KI-Forscher Andrej Karpathy Anfang 2025, halb ernst gemeint, für ein Vorgehen, bei dem man sich “dem Vibe hingibt” und vergisst, dass da überhaupt Code liegt.
Aus dem Scherz ist innerhalb eines Jahres ein Begriff geworden, den Entwicklerinnen, Gründer und Fachabteilungen gleichermaßen benutzen. Was er genau meint, hängt allerdings stark davon ab, wer ihn verwendet.
Woher der Begriff kommt
Karpathy beschrieb im Februar 2025 auf X, wie er kleine Wegwerf-Projekte baut: reden statt tippen, Fehlermeldungen ungelesen zurück ins Modell kippen, Vorschläge annehmen, ohne den Diff zu prüfen. Für ein Wochenendprojekt sei das großartig. Genau diese Einschränkung ging in der anschließenden Verbreitung des Begriffs meistens verloren.
Heute wird “Vibe Coding” in mindestens drei Bedeutungen benutzt:
| Verwendung | Was gemeint ist | Trägt das? |
|---|---|---|
| Wörtlich nach Karpathy | Code entsteht, ohne dass ihn jemand liest | Für Wegwerf-Projekte ja, sonst nein |
| Als Synonym für KI-gestützte Entwicklung | Entwickler arbeiten mit Assistenten, prüfen aber jede Änderung | Ja, das ist heute Alltag |
| Als Marketingbegriff | “Software ohne Entwickler” | Nein |
Diese Unschärfe erklärt, warum über die Methode so unterschiedlich geurteilt wird. Die Beteiligten reden oft über verschiedene Dinge.
Wie das in der Praxis abläuft
Der Ablauf ähnelt einem Gespräch. Man beschreibt ein Ziel, bekommt eine lauffähige Fassung, probiert sie aus und beschreibt die Abweichung. Statt einer Spezifikation vorab entsteht die Klarheit unterwegs.
Ein typischer Durchgang
- Anforderung in ein, zwei Sätzen formulieren, etwa “eine Seite, auf der Kundinnen Termine buchen und wieder absagen können”.
- Das Modell erzeugt Datenmodell, Oberfläche und Grundfunktionen.
- Man klickt sich durch und findet die Stellen, die nicht passen.
- Man beschreibt die Änderung, nicht die Lösung: “Absagen sollen nur bis 24 Stunden vorher möglich sein.”
- Wiederholen, bis das Verhalten stimmt.
Der entscheidende Unterschied zum klassischen Vorgehen liegt im vierten Schritt. Wer die Lösung diktiert, benutzt das Modell als Schreibkraft. Wer das gewünschte Verhalten beschreibt, lässt es die Lösung suchen.
Womit gearbeitet wird
Verbreitet sind Editoren mit eingebautem Modellzugriff wie Cursor, Kommandozeilen-Werkzeuge wie Claude Code sowie Baukästen, die aus einer Beschreibung eine ganze Anwendung erzeugen. Die Werkzeuge unterscheiden sich weniger im Modell als darin, wie viel Zusammenhang sie selbst aus dem Projekt lesen können.
Wo die Methode trägt
Vibe Coding ist stark, wenn Geschwindigkeit mehr zählt als Dauerhaftigkeit.
- Prototypen: Aus einer Idee wird in Stunden etwas Klickbares. Über eine Skizze lässt sich schlecht streiten, über eine bedienbare Oberfläche sehr gut.
- Interne Werkzeuge: Ein kleines Auswertungsskript, ein Formular für zwölf Kolleginnen, ein Importhelfer. Wenn ein Fehler ärgerlich, aber nicht gefährlich ist, passt die Methode.
- Unbekanntes Terrain: Eine fremde Schnittstelle ausprobieren, eine Bibliothek kennenlernen, eine Idee auf Machbarkeit prüfen.
- Vorlagen für die Fachabteilung: Wer eine Anforderung nicht aufschreiben kann, kann sie oft zeigen. Ein grober Klickdummy ersetzt viele Abstimmungsrunden.
Wo sie kippt
Die Grenze verläuft nicht zwischen groß und klein, sondern zwischen wegwerfbar und dauerhaft.
Sobald echte Daten, echte Nutzerinnen oder echte Haftung im Spiel sind, ändert sich die Rechnung. Generierter Code sieht ordentlich aus, auch wenn er einen Denkfehler enthält: sauber formatiert, sinnvoll benannt, ordentlich kommentiert. Genau das macht ihn schwerer zu prüfen als schlecht geschriebenen Code, dem man das Problem ansieht.
Dazu kommen drei Punkte, die in der Begeisterung oft untergehen:
- Sicherheit: Zugangsdaten im Quelltext, fehlende Rechteprüfung, ungefilterte Eingaben. Ein Modell erzeugt, was üblich aussieht, nicht was sicher ist.
- Wartbarkeit: Wer den Code nie gelesen hat, kann ihn im Fehlerfall auch nicht reparieren. Ein Prototyp, den niemand mehr durchdringt, ist eine Hypothek.
- Datenschutz: Was an ein fremdes Modell geschickt wird, verlässt das Haus. Bei Kundendaten ist das eine Frage für den Anfang des Projekts, nicht für die Abnahme.
Für diese Fälle gilt weiterhin, was für jede Software gilt: lesen, testen, verstehen. Die KI schreibt dann zwar große Teile, aber jemand trägt die Verantwortung dafür.
Vibe Coding und Prototyping
Beide Begriffe werden oft vermischt, meinen aber Verschiedenes. Prototyping ist ein Projektschritt mit einem Zweck, nämlich eine Annahme zu prüfen. Vibe Coding ist eine Arbeitsweise, mit der sich dieser Schritt heute deutlich schneller erledigen lässt.
Praktisch heißt das: Ein Prototyp entsteht per Vibe Coding in Stunden statt Tagen. Was danach in den Betrieb geht, wird auf dieser Grundlage neu und sauber gebaut. Der Prototyp ist die Antwort auf eine Frage, nicht der Anfang des Produkts.
Genau darauf ist unser MVP-Workshop gebaut: An einem Tag entsteht gemeinsam mit dir ein klickbarer Prototyp, und die Grenze zum Produktionscode steht vorher fest statt hinterher zur Debatte.
Häufige Fragen zu Vibe Coding
Ersetzt Vibe Coding Entwickler? Nein, es verschiebt ihre Arbeit. Das Schreiben von Code verliert an Gewicht, das Beschreiben von Anforderungen und das Prüfen von Ergebnissen gewinnen. Beides erfordert genau das Verständnis, das man beim reinen Tippen aufbaut.
Kann ich damit als Nicht-Entwickler eine App bauen? Etwas Lauffähiges zu bekommen, ist realistisch. Es sicher zu betreiben, zu warten und bei Fehlern zu reparieren, ist es nicht. Für den internen Gebrauch mit unkritischen Daten kann das trotzdem reichen.
Wie erkenne ich, ob generierter Code taugt? Am zuverlässigsten über Tests, die das gewünschte Verhalten beschreiben, und über einen Blick auf die kritischen Stellen: Wer darf was, was passiert bei fehlerhaften Eingaben, wo liegen Zugangsdaten. Wer das nicht beurteilen kann, sollte jemanden fragen, der es kann.
Ist der Begriff seriös oder ein Modewort? Beides. Die beschriebene Arbeitsweise ist real und verbreitet. Der Begriff selbst ist unscharf und wird im Marketing gern gedehnt. Im Zweifel lohnt die Rückfrage, was genau gemeint ist.
Fazit
Vibe Coding hat die frühe Phase von Softwareprojekten verändert. Was früher als Wireframe diskutiert wurde, lässt sich heute in Stunden ausprobieren, und das macht Missverständnisse früher sichtbar. Die Methode ersetzt aber weder Architektur noch Prüfung noch Verantwortung: Zwischen “läuft im Termin” und “läuft im Betrieb” liegt weiterhin der größere Teil der Arbeit. Wie wir Software entwickeln und wo wir KI dabei einsetzen, steht auf unserer Seite zur Custom-Software-Entwicklung, und wie wir die Methode im Kundentermin nutzen, im MVP-Workshop. Ausführlicher haben wir das im Artikel KI in der Softwareentwicklung beschrieben, und für alles Weitere gibt es das unverbindliche Beratungsgespräch.