Die erste Version funktioniert fast immer. Das ist der Teil, der alle überrascht, wenn sie mit Vibe Coding anfangen. Du beschreibst in einem Satz, was du brauchst, und nach zwei Minuten läuft ein kleines Tool im Browser. Dieser Moment fühlt sich wie Magie an.

Der zweite Moment fühlt sich anders an. Du willst eine Kleinigkeit ändern, das Modell schreibt großzügig die halbe Datei um, und plötzlich funktioniert die Stelle nicht mehr, die vorher lief. Genau hier trennt sich brauchbares Vibe Coding von Wegwerf-Code.

Ich baue seit über einem Jahr kleine bis mittlere Anwendungen größtenteils über natürliche Sprache, meistens auf Next.js mit Supabase im Hintergrund. Was ich in dieser Zeit gelernt habe, lässt sich in einem Satz zusammenfassen: Der Engpass ist nicht mehr das Tippen von Code. Der Engpass ist, wie präzise du beschreibst und wie gründlich du gegenliest. Wer das verinnerlicht, bekommt Ergebnisse, die ein halbes Jahr später noch wartbar sind. Wer es ignoriert, produziert in Rekordzeit genau die Art von System, die später niemand mehr anfassen will.
Spezifikation schlägt Stimmung
Der Begriff "Vibe Coding" ist irreführend, weil er nahelegt, dass man einfach drauflos vibt. In der Praxis ist das Gegenteil der Fall. Je klarer der erste Prompt, desto weniger Runden brauchst du danach.

Spezifikation schlägt Stimmung

Der Begriff "Vibe Coding" ist irreführend, weil er nahelegt, dass man einfach drauflos vibt. In der Praxis ist das Gegenteil der Fall. Je klarer der erste Prompt, desto weniger Runden brauchst du danach.

Ein schlechter Start sieht so aus:
Bau mir ein Dashboard für unsere Verkaufszahlen.

Ein guter Start liefert dem Modell Kontext, den es sonst raten müsste:
Bau eine Seite unter /dashboard in unserem bestehenden Next.js App Router Projekt. Die Daten kommen aus einer Supabase Tabelle "sales" mit den Spalten date, region, amount. Zeige eine Summe pro Region als Balkendiagramm und darunter eine sortierbare Tabelle. Nutze die Komponenten aus unserem bestehenden ui Ordner. Keine neuen Abhängigkeiten ohne Rückfrage.

Der Unterschied ist nicht Höflichkeit gegenüber der Maschine. Der Unterschied ist, dass die zweite Variante eine Entscheidung trifft, statt sie dem Modell zu überlassen. Jede Entscheidung, die du nicht triffst, trifft das Modell für dich, und zwar bei jedem Lauf anders.
Der letzte Satz in dem Beispiel ist wichtiger, als er aussieht. "Keine neuen Abhängigkeiten ohne Rückfrage" verhindert, dass dir das Modell drei zusätzliche Pakete in die package.json schreibt, weil es gerade praktisch schien. Solche Leitplanken im Prompt sparen dir später Stunden.

Kleine Schritte, sonst Schmerz

Der häufigste Fehler ist, dem Modell zu viel auf einmal zu geben und dann eine große Änderung über bestehenden Code laufen zu lassen. Generative Modelle neigen dazu, mehr umzubauen als nötig. Wenn du sie auf eine 400 Zeilen lange Datei loslässt mit dem Auftrag "ändere das Datumsformat", bekommst du zurück eine 400 Zeilen lange Datei, in der das Datumsformat stimmt und drei andere Dinge subtil kaputt sind.

Was hilft, ist banal und wirkt trotzdem: Halte die Einheiten klein. Eine Funktion, eine Komponente, ein klar umrissener Auftrag pro Lauf. Und committe nach jedem funktionierenden Stand. Git ist beim Vibe Coding kein Nice to have, sondern dein Sicherheitsnetz. Wenn der nächste Lauf etwas zerbricht, machst du ihn in zwei Sekunden rückgängig, statt zu raten, was sich geändert hat.

Ich arbeite inzwischen fast immer so: funktionierender Stand, commit, eine Sache ändern, testen, commit. Das klingt nach mehr Aufwand, ist aber unterm Strich schneller, weil ich nie mehr in der Situation lande, einen Haufen vermischter Änderungen entwirren zu müssen.

Du besitzt den Code, also lies ihn

Der gefährlichste Satz beim Vibe Coding lautet "läuft ja". Ob etwas läuft, sagt nichts darüber aus, ob es das Richtige tut oder ob es sicher ist.

Ein konkretes Beispiel aus dem Alltag: Bittet man ein Modell, Daten aus Supabase zu laden, schreibt es oft den Zugriff direkt in eine Client Komponente, ohne Row Level Security zu erwähnen. Im Demo Betrieb mit Testdaten fällt das nie auf. Sobald echte Nutzer und echte Daten dazukommen, hast du ein Datenleck gebaut, ohne es zu merken. Das Modell hat nichts falsch gemacht im Sinne von "der Code kompiliert nicht". Es hat nur eine Annahme getroffen, die in deinem Kontext nicht stimmt.

Deshalb gilt: Generierter Code ist ein Entwurf, kein Endprodukt. Du musst ihn nicht Zeile für Zeile selbst hätten schreiben können, aber du musst ihn lesen und verstehen können. Wenn du an einer Stelle nicht weißt, was passiert, frag das Modell, es soll es erklären, bevor du es übernimmst. Diese fünf Minuten sind die beste Investition im ganzen Prozess.

Wo es sich lohnt und wo nicht

Nach genug Projekten zeichnet sich ein klares Muster ab, für welche Aufgaben Vibe Coding wirklich Zeit spart.

Es glänzt bei internen Werkzeugen mit überschaubarem Umfang: Konfiguratoren, Auswertungen, Prototypen, kleine Automatisierungen, Dinge mit klarer Aufgabe und begrenztem Schadensrisiko. Aus einem Projekt von zwei Wochen wird hier regelmäßig ein Nachmittag, und das ohne Qualitätsverlust, wenn man die Punkte oben beachtet.

Es wird mühsam, sobald ein System groß, stark vernetzt und geschäftskritisch ist. Je mehr bewegliche Teile, desto schwerer ist es, allein über Sprache die Kontrolle zu behalten. Das heißt nicht, dass man dort gar keine KI nutzt. Es heißt, dass man dort einen erfahrenen Entwickler im Loop braucht, der die generierten Vorschläge einordnet, statt sie blind zu übernehmen.

Diese Grenze ehrlich zu kennen, ist kein Eingeständnis von Schwäche. Es ist der Unterschied zwischen jemandem, der Vibe Coding produktiv einsetzt, und jemandem, der sich damit nur neue Probleme einkauft.

Der eigentliche Hebel

Wenn ich das Ganze auf eine Sache reduzieren müsste, dann diese: Vibe Coding macht nicht das Programmieren schneller, es verschiebt, wer überhaupt Software bauen kann. Eine Fachkraft, die ihr Problem genau kennt, aber nie programmieren gelernt hat, kann heute eine brauchbare Lösung bauen, vorausgesetzt, sie lernt die paar Disziplinen, die ich hier beschrieben habe.

Klar spezifizieren. In kleinen Schritten arbeiten. Den Code lesen, den man übernimmt. Wissen, wo die eigene Grenze liegt. Das ist kein großes Geheimnis, und es ist auch keine Magie. Es ist Handwerk, nur mit einem neuen Werkzeug. Und wie bei jedem Werkzeug entscheidet nicht das Werkzeug über das Ergebnis, sondern die Hand, die es führt.