Was ist Vibe Coding wirklich?

Der Begriff "Vibe Coding" verbreitete sich 2024-2025 schnell, weil er etwas benennt, das viele Entwickler bereits stillschweigend taten: ihre Absicht auf Englisch einem Modell wie GPT-4, Claude oder einem Tool wie Cursor oder GitHub Copilot beschreiben und es den größten Teil des tatsächlichen Codes generieren lassen. Der Programmierer bleibt in der Schleife, aber die Schleife sieht anders aus als beim traditionellen Programmieren.

Die tatsächliche Definition

Andrej Karpathy prägte den Begriff und beschrieb einen Workflow, bei dem man "sich vollständig den Vibes ergibt" — man promptet, akzeptiert Vorschläge, führt den Code aus, sieht, was kaputtgeht, und promptet erneut. Man liest nicht jede Diff Zeile für Zeile. Man steuert nach Ergebnis: funktioniert die App, besteht der Test, rendert die Seite korrekt. Die Fähigkeit verschiebt sich vom Schreiben von Syntax zur klaren Beschreibung von Absichten und zur Erkennung, wenn die Ausgabe falsch ist.

Das unterscheidet sich von bloßer Verwendung von Autocomplete. Copilot-ähnliche Inline-Vorschläge gehen immer noch davon aus, dass du die Funktion selbst mit etwas Hilfe beim Fertigstellen von Zeilen schreibst. Vibe Coding setzt voraus, dass das Modell die Funktion, die Datei, manchmal das ganze Feature schreibt, und du reviewst und leitest um, anstatt von Grund auf zu verfassen.

Wie eine echte Sitzung aussieht

Eine typische Vibe-Coding-Schleife mit einem Tool wie Cursor oder Repits Agent-Modus sieht ungefähr so aus:

1. Prompt: "Füge diesem Express API einen Rate Limiter hinzu, 100 Anfragen pro 15 Minuten pro IP, gebe 429 mit einem JSON-Fehlertext zurück."
2. Das Modell bearbeitet middleware/rateLimit.js, verbindet es mit app.js, zieht vielleicht express-rate-limit ein.
3. Du führst npm test aus oder schlägst mit curl in einer Schleife auf den Endpoint, um zu prüfen, dass die 429 tatsächlich feuert.
4. Etwas stimmt nicht — der Limiter setzt sich bei jedem Deploy zurück, weil er im Speicher ist. Du sagst das.
5. Das Modell wechselt zu einem Redis-gestützten Store, fügt die ioredis-Abhängigkeit hinzu, aktualisiert die docker-compose-Datei.
6. Du testest erneut, es funktioniert, du committest.

Keine Zeile dieser Middleware wurde von Hand getippt. Aber sechs oder sieben Urteile wurden von einem Menschen gefällt: wie hoch das Limit sein sollte, dass In-Memory-Speicher für die Produktion falsch war, dass auch die docker-compose-Datei aktualisiert werden musste.

Wo es gut funktioniert

Vibe Coding ist stark bei boilerplate-lastiger Arbeit: CRUD-Endpoints, Formularvalidierung, Test-Gerüste, Config-Dateien, Glue Code zwischen zwei APIs, die du bereits verstehst. Es ist auch gut zum Prototyping — in einer Stunde statt eines Tages ein funktionierendes Demo einer Idee hochfahren, dann entscheiden, ob es sich lohnt, es richtig zu bauen.

Es ist genuinely schnell für Solo-Entwickler und kleine Teams, die interne Tools oder MVPs versenden, wo die Kosten eines Bugs niedrig sind und Iterationsgeschwindigkeit mehr zählt als architektonische Reinheit.

Wo es zusammenbricht

Der Fehlermodus, den die Leute nicht genug thematisieren: Modelle produzieren Code, der läuft, aber auf subtile Weise falsch ist, auf Wegen, die erst später auftauchen. Eine generierte SQL-Abfrage könnte für den Happy Path funktionieren, aber anfällig für Injection sein, weil Stringverkettung dem Modell in Ordnung aussah. Eine generierte Auth-Prüfung könnte Tests bestehen, aber eine Rollen-Prüfung auf einer Route überspringen. Wenn du den Code nicht liest, wirst du das nicht fangen — du wirst nur sehen, dass die Tests bestanden, und es versenden.

Das zählt mehr in sicherheitssensitivem Code als fast überall sonst. Simon Willison und andere haben darauf hingewiesen, dass Vibe-Coding-Projekte mit echten Nutzerdaten die gleiche Review-Strenge brauchen wie jeder andere Code, vermutlich mehr, weil die Person, die ihn "geschrieben" hat, vielleicht nicht erklären kann, was er Zeile für Zeile tut.

Komplexe Systeme mit viel implizitem State — Concurrency, verteilte Transaktionen, alles mit subtilen Timing-Bugs — sind auch ein schlechtes Match. Modelle neigen dazu, plausibel aussehenden Code für diese Fälle zu generieren, der auf Wegen scheitert, die schwer zu debuggen sind, genau weil niemand, weder Mensch noch Modell, die Edge Cases von Anfang an vollständig modelliert hat.

Die Fähigkeit, die jetzt wirklich zählt

Wenn du Vibe Coding machst, ist die wertvolle Fähigkeit nicht Tippgeschwindigkeit, sondern Spezifizierung. Vage Prompts bekommen vagen, buggy Code. Spezifische Prompts — mit exakten Bibliotheknamen, Error-Handling-Erwartungen und ausgerufenen Edge Cases — bekommen viel bessere Ausgabe. Die zweitwichtigste Fähigkeit ist, Code schnell genug zu lesen, um zu erkennen, was falsch ist, was bedeutet, dass du die Sprache und die Domain immer noch verstehen musst, auch wenn du nicht jeden Buchstaben tippst.

Behandle KI-generierten Code wie einen Pull Request von einem Junior-Dev, der schnell ist aber gelegentlich zu selbstsicher: nützlich, oft korrekt, aber ein echtes Review wert, bevor es Production berührt.

Möchtest du tiefer einsteigen, wie man Code mit KI-Tools schreibt, ohne die Kontrolle über die Qualität zu verlieren? Schau dir die AI and Python Segmente von Korra Studio für praktische Walkthroughs an.