Vibe Coding ist nicht tot. Du hast es nur wie das erste kleine Schweinchen gebaut.

6 min read

Die Geschichte von den drei kleinen Schweinchen bringt mich immer zum Schmunzeln. Leute, die null Ahnung haben, erzählen ständig die falsche Geschichte. Ich habe mein eigenes Strohballenhaus gebaut, und es ist gemütlicher und angenehmer als alle Betonklotzhäuser, in denen ich je gewohnt habe.

Genauso ist es mit Vibe Coding.

TLDR: Alle beerdigen Vibe Coding im April 2026. Karpathy hat es als "agentic engineering" umbenannt. 70% aller Builds bleiben beim Demo stecken – eine Zahl, die jetzt überall nachgeplappert wird, ohne dass sich jemand die Mühe macht, die Quelle zu nennen. Die gängige Diagnose: Die Methode taugt nichts. Ich musste 1.880 Strohballen in meinem eigenen Haus verlegen, um zu kapieren, dass alle die falsche Diagnose stellen.

Entwickler präsentiert stolz ein wackeliges Kartenhaus-Framework, während ein Kollege lässig an einer soliden Holzstruktur lehnt und wissend grinst, im 90er-Jahre-Büro-Comic-Stil
Dein Vibe-Coding-Framework hat gerade den bösen Wolf getroffen.

Als ich meinen Nachbarn erzählte, dass ich mein Haus aus Stroh baue, bekam ich exakt dieselbe Leier zu hören, die ich heute über Vibe Coding höre. Das brennt ab. Das hält nicht. Du bist naiv. Fünf Jahre später steht das Haus noch, und dieselben Stimmen haben sich ein Jahrzehnt weiter zu KI-generiertem Code verschoben. Dieselben Sätze, anderes Material. Und derselbe Denkfehler dahinter.

Was die Leute sagten, als sie die Ballen aufgestapelt sahen

Ein Nachbar hielt seinen Truck auf der Straße an, schaute auf die unter der Plane gestapelten Ballen und fragte mich aus heiterem Himmel, ob ich wüsste, dass Mäuse Stroh fressen und Feuer Stroh noch schneller. Er war nicht böswillig. Er war sich sicher. Dieselbe Energie wie jeder Kommentator auf dieser Seite, der sich sicher ist, dass KI nichts ausliefern kann.

Das brennt ab. Das hält nicht. Du bist naiv.

Ich gab dieselbe Antwort, die ich heute in Medium-Kommentaren gebe. Das ist kein Glaubensargument, das ist Physik. Gepresster Stroh ist so dicht, dass Feuer keinen Sauerstoff im Ballen findet. Der Kalk-Lehm-Putz, der die Wand umhüllt, versiegelt die wenige Luft, die noch bleibt. Das Holzgerüst trägt die Last. Ein falsch verlegter Ballen brennt. Ein richtig verlegter Ballen überlebt dich.

Falls du ein Datum willst: Das erste europäische Strohballenhaus, die Maison Feuillette, wurde 1920 in Montargis, Frankreich gebaut. Steht noch. Ist noch bewohnt. Älter als mein Großvater und in besserem Zustand als seine letzte Wohnung.

Das Haus ist in Ordnung. Die Methode ist in Ordnung. Was in der Diskussion fehlt, ist jemand, der tatsächlich eins gebaut hat.

Fünf Jahre später höre ich dasselbe Drehbuch über Vibe Coding.

Was die Leute sagen, wenn ich ihnen erzähle, dass ich 2026 noch Vibe Code

Es ist tot. Es liefert nicht aus. Die ernsthaften Leute sind zu "agentic engineering" gewechselt (dasselbe, längerer Name). 70% aller vibe-gecodeten Apps bleiben beim Demo stecken – eine Branchenstatistik, die jetzt in jedem Think-Piece auftaucht, ohne je auf die Umfrage zu verweisen, aus der sie stammt. Es gibt einen viralen Medium-Artikel, der den Lesern gerade erzählt, dass alles vorbei ist. Bloomberg hat einen Artikel über KI-Coding-Tools und eine Produktivitätspanik gebracht und dabei die völlig falsche Krankheit diagnostiziert.

Das brennt ab. Das hält nicht. Du bist naiv.

Dasselbe Drehbuch, zehn Jahre später, auf JSX statt Stroh angewendet. Und die Antwort ist dieselbe. Das ist auch kein Glaubensargument. Das ist ein Methoden-und-Wiederholungen-Argument.

Schlecht gemachtes Vibe Coding bricht in der Mitte durch. Das stimmt. Die 70%-Zahl ist nicht aus der Luft gegriffen. Leute stoßen an die Wand. Jede Menge tote Repos auf GitHub beweisen es.

Schlecht gemacht bedeutet: gemacht von jemandem, der drei Prompts in seinem Leben getippt und am Ende eine fertige SaaS erwartet hat. Von jemandem, der noch nie ein Feature schriftlich spezifiziert hat. Von jemandem, der noch nie gesehen hat, wie eine ungebrochene Schleife aus generieren-testen-reparieren-testen über zwölf Iterationen am selben Projekt aussieht.

Die Methode ist wichtig. Die Methode ohne Wiederholungen ist ein Stück Papier.

Das ist geklärt.

Drei Jahre Lesen. Zwei Jahre, 1.880 Ballen verlegen. Die Wand steht noch.

Straw bales stacked between wooden frame during mid-construction of load-bearing wall, showing proper building technique and
Strohballen während des Baus, ordentlich zwischen der Holzrahmenstruktur gestapelt.

Ich habe drei Jahre über Strohballenbau gelesen, bevor ich einen Ballen angefasst habe. Darauf bin ich nicht stolz. Ich hätte schneller gelernt, wenn ich zehn davon schlecht verlegt hätte. Aber ich hatte ein Kind, einen Job, ein Budget, das noch nicht bereit war, und ich brauchte die Theorie, bevor ich den Landkauf rechtfertigen konnte. Drei Jahre Bücher, Wochenend-Workshops, zwei Monate auf der Baustelle eines Freundes in der Ardèche, wo ich hauptsächlich Sachen getragen und zugeschaut habe. Lange Phasen ohne etwas zu verlegen. Ich habe nie aufgegeben. Ich konnte nur nicht anfangen.

Dann kaufte ich das Land und fing an.

Zwei Jahre auf der Baustelle. 1.880 Ballen zwischen den tragenden Wänden und den Trennwänden. Der erste Ballen war schief und ich musste ihn zweimal neu machen. Der fünfzigste war beim ersten Versuch gerade. Um den sechshundertsten herum merkte ich, dass ich beim Verputzen nicht mehr schwitzte. Um den zwölfhundertsten herum kannten meine Hände den Schnittwinkel, ohne hinzuschauen. Der 1.880ste Ballen ging so rein, wie der erste hätte reingehen sollen, nur dass ich da nicht mal mehr darüber nachdachte.

Die Methode, die ich bei Ballen 1 verwendet habe, und die Methode bei Ballen 1.880 war dieselbe Methode. Das Buch, das ich 2018 gelesen habe, hat sich nicht geändert. Das Video, das ich 2019 geschaut habe, hat sich nicht geändert. Was sich geändert hat: Meine Hände hatten es 1.880 Mal am selben Haus gemacht.

Das ist der Teil, den niemand durchlebt hat, der dir erzählt, dass Vibe Coding tot ist.

Dein erstes Feature ist schief. Dein fünfzigstes ist gerade. Wenn das Model zum ersten Mal Code generiert, den du nicht sofort wegwerfen willst, hast du schon mehr ausgeliefert, als du dich erinnerst. Wenn du zum ersten Mal aufhörst, die Architektur zu hinterfragen, hast du aufgehört zu zählen. Wenn du zum ersten Mal ein Feature in zwei Stunden auslieferst, das früher zwei Tage gedauert hat, merkst du nicht, dass es passiert. Jemand anders weist dich darauf hin. 😅

Die Methode ändert sich nicht zwischen Wiederholung 1 und Wiederholung 1.880. Deine Hände ändern sich.

Aber niemand hat fünf Jahre Zeit, um eine SaaS auszuliefern. Das ist das eigentliche Problem.

Wie man es in 12 statt 1.880 Wiederholungen schafft

Ich habe ein Buch geschrieben, um diese Kurve zu komprimieren.

Kein Theoriebuch. Davon gibt es schon ein gutes. Gene Kim und Steve Yegge haben dieses Jahr Vibe Coding: Building Production-Grade Software veröffentlicht, und das ist die richtige Referenz, wenn du ein Senior Dev bist, der die Patterns formalisiert haben will. Lies es danach.

Dieses hier ist anders. Es führt den Leser durch 12 Wiederholungen am exakt selben Projekt. Ein kleines CRM für Handwerker, Klempner, Elektriker, Zimmerer. Nicht 12 verschiedene Tutorials zu 12 unverwandten Themen. Zwölf Durchgänge an derselben Codebasis. Jedes Kapitel bringt das CRM weiter. Auth in Kapitel eins. CRUD in zwei. Suche in drei. Benachrichtigungen in vier. Und so weiter, in derselben Reihenfolge, wie du ein Haus bauen würdest: Fundament, Rahmen, Dach, Wände, Putz, Feinarbeiten.

Die Methode selbst steht im Buch, die achtstufige Blueprint Method, dieselbe, die ich bei jedem Projekt verwende, das ich ausliefere. Sie passt in vielleicht zwanzig Seiten. Die anderen 270 Seiten sind Wiederholungen. Weil die Methode ohne Wiederholungen das Stück Papier ist, von dem ich gerade gesprochen habe.

Einschränkung, die ich nicht beschönigen werde: Das funktioniert nur, wenn du alle zwölf Wiederholungen machst. Vier Kapitel machen und aufhören wird nichts ausliefern. Du wirst etwas gelernt haben, aber du wirst den Muskel nicht aufgebaut haben. (Genauso wie fünfzig Ballen verlegen und aufhören. Das Haus ist immer noch ein Loch im Boden.)

Es gibt ein privates Begleit-Repo für Leser, wo der CRM-Zustand am Ende jedes Kapitels committed ist. Wenn du ein Kapitel überspringst oder stecken bleibst, klonst du den Snapshot und machst weiter. Diesen Trick habe ich auch vom Stroh gelernt: Jeder Workshop, an dem ich je teilgenommen habe, beendete eine Phase mit einer Wand, die jeder anfassen konnte. Du gehst nicht von der Theorie weiter. Du gehst von einer Wand weiter.

Wenn du schon auslieferst, brauchst du dieses Buch nicht. Geh weiter mit dem Prompt Contracts Framework, das ich nach genug Katastrophen gebaut habe. Das ist die nächste Ebene. Vibe Coding, For Real: From Demo to Live App ist für das Fundament. Prompt Contracts ist für die oberen Stockwerke.

Das Buch gibt es auf Amazon: https://amzn.eu/d/04X9k88d

Die meisten Leute, die dir erzählen, dass Vibe Coding nicht funktioniert, haben ein Feature geschrieben, zugeschaut, wie Lovable kaputtes JSX ausgespuckt hat, und den Tab geschlossen. Ein Ballen. Eine Wand. Faule Schlussfolgerung.

Mit Methode baust du Strohhäuser. Mit Methode baust du vibe-gecodete Apps. Solide. Gemütlich. Für die Ewigkeit gebaut. 🏠

Quellen

  • Vibe Coding: Building Production-Grade Software von Gene Kim und Steve Yegge (IT Revolution, 2026)
  • Maison Feuillette, Montargis, Frankreich (1920)
  • Vibe Coding, For Real: From Demo to Live App (April 2026): https://amzn.eu/d/04X9k88d