Ich habe per Vibe Coding eine funktionierende App in 40 Minuten gebaut — und es war großartig. Dann versuchte ich, ein zweites Feature hinzuzufügen, und das Ganze fiel wie ein Jenga-Turm zusammen. Wenn du jemals mit einem KI-Agenten etwas Echtes geliefert hast, kennst du dieses Gefühl. Vibe Coding ist in den ersten 80% fantastisch und in dem Teil, auf den es wirklich ankommt, ein Alptraum.
Lass mich den Begriff definieren, damit wir nicht aneinander vorbeisprechen. Vibe Coding ist, wenn du in normaler Sprache beschreibst, was du willst, den Agenten es schreiben lässt, das Ergebnis kurz anschaust und auf Gefühl weitermachst — ohne echte Review, ohne Architektur, nur Vibes und Momentum. Es ist schnell. Es macht Spaß. Und es funktioniert nicht über die Demo hinaus. Das ist meine provokante These, und ich werde sie verteidigen.
Warum sich die erste Stunde wie Magie anfühlt
Die frühe Phase jedes Projekts hat keine Einschränkungen. Es gibt keinen bestehenden Code, den man kaputtmachen kann, keine Konventionen, die zu beachten sind, keine Nutzer, die auf das Verhalten von gestern angewiesen sind. Der Agent bekommt eine leere Leinwand und füllt sie. Natürlich ist das schnell. Du bittest ihn nicht um Vorsicht, du bittest ihn um Generierung — und Generierung ist das, was diese Modelle am besten können.
Das hat übrigens echten Wert. Für einen Prototypen, einen Spike, einen wegwerfbaren Proof-of-Concept ist Vibe Coding das richtige Werkzeug. Bring die Idee auf den Bildschirm, schau ob sie es wert ist gebaut zu werden, wirf sie weg. Das mache ich jede Woche. Keine Notizen.
Der Fehler ist zu glauben, dass die Prototypen-Geschwindigkeit anhält. Tut sie nicht.
Wo alles auseinanderfällt
In dem Moment, in dem die Codebasis Zustand hat — bestehende Muster, echte Daten, ein Feature, auf das jemand verlässt — kippt das Kalkül. Jetzt muss jede Änderung konsistent mit dem sein, was bereits da ist. Und Vibe Coding hat keinen Mechanismus für Konsistenz, weil du nie genau genug hingeschaut hast, um zu wissen, was "konsistent" bedeutet.
Ich habe einen Agenten gesehen, der — drei Features tief — seine dritte unterschiedliche Art erfand, API-Fehler zu behandeln. Nicht weil er dumm ist. Sondern weil niemand ihm von den anderen beiden gesagt hat, und beim Vibe-Coding merkst du es nicht, bis etwas auf eine Weise kaputtgeht, die mühsam zu verfolgen ist. Die Codebasis wird zu einer archäologischen Ausgrabung — sechs Stile, vier State-Management-Ansätze, zwei Datum-Bibliotheken und eine Funktion namens handleStuff, die Authentication macht.
Die Bugs sind das Schlimmste. Vibe-gekodete Bugs verstecken sich. Der Code sieht richtig aus — das Modell schreibt plausiblen, selbstsicheren Code — also überfliegt man ihn, er kompiliert, der Happy Path funktioniert, man macht weiter. Der Bug taucht drei Features später auf, wenn der Edge Case endlich ausgelöst wird, und jetzt debuggt man Code, den man nie wirklich gelesen hat. Man hat nicht mal den Kontext, ihn geschrieben zu haben.
Das Review, das du übersprungen hast, ist die Rechnung, die du bezahlst
Hier ist etwas, das niemand hören möchte: Die Geschwindigkeit von Vibe Coding ist teilweise aus der Zukunft geliehen. Du übersprings die Review-Arbeit nicht. Du verschiebst sie, mit Zinsen. Jedes nicht reviewte Diff ist ein kleiner Kredit. Die Demo wird schnell geliefert, weil du viele Kredite aufgenommen hast. Das Produkt kommt ins Stocken, weil die Zahlungen alle auf einmal fällig werden, meist zum ungünstigsten Zeitpunkt.
Deshalb stoßen Teams in der dritten Woche eines Vibe-gekodeten Projekts gegen eine Wand. Die ersten Features flogen herein. Jetzt sinkt die Velocity und niemand weiß warum. Es sind die Zinsen. Die Codebasis hat keine Form, und formlose Codebasen werden immer schwieriger zu ändern, nicht leichter.
Was ich stattdessen mache, sobald es ernst wird
Ich benutze den Agenten immer noch für fast alles. Ich höre nur auf zu viben in dem Moment, in dem die Sache ein Produkt wird. Die Umstellung sieht so aus:
- Ich lese jedes Diff bevor es landet. Nicht überfliegen. Lesen. Wenn ich es nicht verstehe, wird es nicht geliefert.
- Ich führe eine
CLAUDE.mdoder Ähnliches, die die Konventionen festhält — wie wir Fehler behandeln, wie wir State verwalten, welche Bibliotheken genehmigt sind. Der Agent liest sie. Konsistenz ist kein Glücksspiel mehr. - Ich lasse den Agenten Tests für alles Nicht-Triviale schreiben, und ich führe sie aus. Ein bestandener Test ist der Unterschied zwischen "sieht richtig aus" und "ist richtig".
- Ich arbeite in kleinen, überprüfbaren Stücken. Ein Feature, ein klares Diff, ein Review. Nicht "bau das gesamte Dashboard" in einem einzigen fieberhaften Prompt.
Nichts davon ist langsam, genau genommen. Es ist bedacht. Der Agent schreibt immer noch den Code. Ich bin nur wieder in der Schleife als die Person, die wirklich weiß, was gerade passiert.
Das ehrliche Framing
Hier ist ein Befehl, den ich ständig ausführe, wenn ich ein vibe-gekodetes Chaos übernehme:
git log --oneline -20 && git diff HEAD~5 --stat
Ich muss sehen, was sich geändert hat und wie viel, denn beim Vibe-Coding hat das niemand verfolgt. Das Erste, was ich bei einem Vibe-Coding-Projekt tue, ist Verantwortlichkeit wieder einzuführen — gegenüber dem Diff, gegenüber den Tests, gegenüber den Konventionen.
Vibe Coding ist nicht schlecht. Es ist eine Phase. Es ist das Brainstorming, nicht das Manuskript. Die Builder, die sich verbrennen, sind diejenigen, die nie aufhören — die den Prototypen-Workflow als Produktions-Workflow behandeln und sich wundern, warum ihre App zu Brei geworden ist.
Nutze die Vibes, um herauszufinden, was du bauen willst. Dann lege die Hände wieder ans Steuer, um es wirklich zu bauen. Die Demo wird dich so oder so lieben. Das Produkt liebt dich nur, wenn du den Code liest.