Vibe-Coding-Falle:Warum KI-Projekte in Monat 3 sterben

Vibe Coding – Software bauen, indem du einer KI beschreibst, was du willst, ohne die darunterliegende Architektur zu verstehen – funktioniert etwa drei Monate lang brillant. Dann brechen neue Features alte, und die meisten Projekte sterben in der Vibe-Coding-Falle. Die Falle ist nicht die KI. Es ist, wer die Architekturentscheidungen trifft: niemand.

Ich sehe jede Woche denselben Zyklus. Woche 1: „Ich habe mein SaaS-MVP an einem Wochenende gebaut, KI ist Magie!“ Woche 4: „Diese Woche 10 neue Features hinzugefügt.“ Woche 12: „Alles geht kaputt. Jedes neue Feature zerschießt 3 alte. Ich glaube, ich muss von vorn anfangen.“ Woche 16: „Vibe Coding ist Blödsinn. Ich gehe zurück zur klassischen Entwicklung.“

Kluge, fähige Menschen. Unglaublicher Schwung. Dann eine Wand, so hart, dass sie komplett aufgeben. Hier erfährst du, warum – und wie du die Ausnahme wirst.

Was ist Vibe Coding?

Vibe Coding heißt, eine KI Features bauen zu lassen, ohne selbst eine einzige Architekturentscheidung zu treffen. „Bau mir ein Nutzer-Dashboard.“ Ausliefern. „Jetzt füge Teams hinzu.“ Ausliefern. „Füge Abrechnung hinzu.“ Ausliefern. Jeder Prompt funktioniert. Jedes Feature erscheint. Du hast kein einziges Mal entschieden, wie die Daten strukturiert sind, wie Berechtigungen funktionieren oder wie irgendetwas zusammenhängt.

Und die anfängliche Erfahrung ist aus echten Gründen berauschend: funktionierender Code in Minuten statt Tagen, keine Lernkurve, greifbarer Fortschritt, den du zeigen kannst. Das Dopamin ist real. Die Features funktionieren tatsächlich.

Bis sie es nicht mehr tun. Denn die unbequeme Wahrheit ist: Vibe Coding fühlt sich produktiv an, weil du Aktivität mit Fortschritt verwechselst. Features auszuliefern ist Aktivität. Eine Architektur zu bauen, die Feature 20 überlebt, ist Fortschritt.

Die Vibe-Coding-Falle: die 3-Monats-Klippe, an der KI-Projekte sterben

Der Zusammenbruch folgt einer vorhersehbaren mechanischen Abfolge:

Woche 1–4: die Flitterwochen. Du baust isolierte Features. Jedes funktioniert für sich, weil noch nichts verbunden ist. Die KI erzeugt vernünftigen Code, weil jeder Prompt einfach und in sich geschlossen ist.

Woche 5–8: die Risse. Neue Features interagieren jetzt mit alten – und die KI erinnert sich nicht an die Architekturentscheidungen, die sie vor vier Wochen getroffen hat. Verschiedene Sessions treffen verschiedene Entscheidungen. Mal verknüpft sie Daten sauber über Fremdschlüssel, mal dupliziert sie sie. Eines Tages merkst du, dass der Name des Nutzers in fünf verschiedenen Tabellen gespeichert ist. Änderst du ihn an einer Stelle, ist er in den anderen vier veraltet.

Woche 9–12: die Todesspirale. Jedes neue Feature erbt die Inkonsistenzen, bringt eigene Annahmen mit und zerstört etwas, das funktioniert hat. Du promptest: „Behebe den Bug, bei dem sich Nutzernamen nicht überall aktualisieren.“ Die KI antwortet: „Ich aktualisiere die 6 Stellen, an denen wir Nutzernamen speichern.“ Du fragst, warum es sechs Stellen gibt. Sie bietet an, sie zusammenzuführen – aber das würde 15 Features kaputt machen. Game over.

Die Diskrepanz, die Leute täuscht: KI ist wirklich hervorragend darin, korrekten Code für isolierte Features zu erzeugen. Sie ist nicht gut darin, sich über Sessions hinweg an Entscheidungen zu erinnern, Konflikte mit bestehenden Mustern zu erkennen oder strategische Architekturentscheidungen zu treffen. Und sie antwortet in beiden Fällen mit totaler Überzeugung – „der Einfachheit halber empfehle ich hier eine Denormalisierung“ klingt klug, und du kannst guten Rat nicht von schlechtem unterscheiden, wenn du die Architektur nicht verstehst.

Das BuchThe Solopreneur RevolutionLuis Gonçalves darüber, wie du neben dem Job mit KI ein Solopreneur-Business aufbaust.Zum Buch →

Du bist der Architekt. Die KI ist der Bauarbeiter.

Das ist der Paradigmenwechsel, der alles verändert. Nicht „KI ist mein Entwickler und ich bin der Product Manager“. Nicht „wir programmieren gemeinsam als Partner“. Du entwirfst. Die KI baut.

Denk an den Hausbau. Der Architekt entscheidet über das Fundament, die tragenden Wände, den Verlauf der Rohre – Entscheidungen, die sich nach Baubeginn nicht mehr ändern lassen. Der Bauarbeiter setzt diesen Plan mit echtem Können um, erschafft ihn aber nicht. Sagst du einem Bauarbeiter „bau mir ein Haus“, ohne Bauplan, bekommst du etwas, das steht – bis du ein zweites Stockwerk willst und feststellst, dass das Fundament es nicht trägt.

In der Software sind die Entscheidungen des Architekten deine: welche Entitäten es gibt und wie sie zusammenhängen, ob das System mandantenfähig ist, wie Berechtigungen durchgesetzt werden, was normalisiert wird, welchen Mustern jeder Service folgt. Die Aufgabe der KI ist die Ausführung: die Komponenten, der Boilerplate, die Migrationen, die dein Schema exakt umsetzen.

Und zum Job gehört, dagegenzuhalten. Sagt die KI „der Einfachheit halber speichern wir den Namen des Nutzers auch in der Bestelltabelle“ – nein, normalisieren. Sagt sie „aus Performance-Gründen denormalisieren wir“ – zeig mir erst das Performance-Problem. Schlägt sie einen schnellen Fix vor – keine Hacks, finde die Ursache. KI optimiert auf schnell funktionierenden Code. Du brauchst Produktionscode, der nie neu gebaut werden muss.

Die Architektur-zuerst-Alternative (mit Beweis)

Ich habe diesen Ansatz nicht entwickelt, weil ich clever bin. Ich habe ihn entwickelt, weil ich keine Wahl hatte. Nachdem ich bei einem gescheiterten Unternehmen alles verloren hatte, baute ich bei meinen Eltern neu auf – meine 83-jährigen Eltern bezahlten mein Claude-Abo, weil ich es mir nicht leisten konnte. Ich hatte Monate an Spielraum, nicht Jahre. Hätte ich per Vibe Coding gebaut und wäre in Monat 3 gegen die Wand gelaufen, hätte es keinen zweiten Versuch gegeben.

Also habe ich, bevor ich auch nur eine Zeile UI schrieb, 2 Wochen lang das komplette Datenbankschema für FIKR Space entworfen: jede Beziehung abgebildet, Mandantenfähigkeit ab Tag 1 auf jeder Tabelle, Row-Level-Security auf Datenbankebene durchgesetzt, über 90 % der Daten auf eine einzige Wahrheitsquelle normalisiert. Dann gab ich der KI diesen Bauplan und ließ sie bauen – und kämpfte täglich dagegen, wenn sie Abkürzungen vorschlug.

Das Ergebnis nach 11 Monaten: 8–12 integrierte Produkte, produktionsreif, null Neubauten. Als das Fundament stand, flogen die Features – ein komplettes OKR-System in 3 Tagen, Cap-Table-Verwaltung in 4. Wenn Leute es testeten, lautete die Frage immer gleich: „Wie konntest du das allein bauen?“ Das klassische Angebot für diese Plattform lautet 10–15 Entwickler über 2 Jahre – 1,6–2,4 Mio. € allein an Entwicklergehältern, voll gerechnet locker über 2 Mio. €. Mich hat es im ersten Jahr weniger als 3.250 € gekostet. (Die vollständige Aufschlüsselung der Tool-Kosten ist ein eigener Beitrag.)

Die Wahl, vor der du stehst, ist einfach formuliert: jetzt schnell und später langsam, oder jetzt langsam und für immer schnell. Vibe Coding liefert 20 Features im ersten Monat aus und verbringt Monat 3 damit, zu reparieren, was Monat 1 gebaut hat. Architektur zuerst verbringt 2 Wochen mit dem Bauplan und liefert dann Features, die funktionieren bleiben.

12 WochenDeine Konzernkarriere war nie der PlanBewirb dich beim Solopreneur Accelerator.Jetzt bewerben →

Häufig gestellte Fragen

Woran erkenne ich, dass ich Vibe Coding betreibe?

Die Warnzeichen: Du hast die KI mehr als 3 Mal gebeten, denselben Bug zu beheben, du kannst jemand anderem dein Datenbankschema nicht erklären, dieselben Daten scheinen in verschiedenen Features unterschiedlich gespeichert zu sein, du scheust dich, Features hinzuzufügen, weil du nicht weißt, was sie kaputt machen, oder du denkst insgeheim darüber nach, „mit einem leeren Blatt neu anzufangen“. Treffen drei oder mehr davon zu, steuerst du auf die Klippe zu.

Ist Vibe Coding jemals in Ordnung?

Ja – für Prototypen und einfache Apps, die du bereit bist wegzuwerfen. Tools, die für reines Prompting gebaut sind, sind großartig für schnelle MVPs. Die Falle schnappt zu, wenn aus einem Wegwerf-Prototyp unbemerkt das Produkt wird und die Architekturentscheidungen von Monat 3 von niemandem getroffen wurden.

Kann ich ein Vibe-Coding-Projekt retten, oder muss ich neu bauen?

Meistens kannst du es retten. Pausiere die Feature-Entwicklung für ein paar Tage, kartiere jede Tabelle und wie sie zusammenhängen, finde heraus, wo Daten dupliziert sind, entwirf das Schema, das diese Entitäten hätten haben sollen, und migriere dann: Duplikate zusammenführen, fehlende Fremdschlüssel ergänzen, Mandantentrennung hinzufügen, Row-Level-Security aktivieren. Das fühlt sich langsam an. Es ist Monate schneller als der Neubau, auf den du sonst zusteuerst.

Muss ich programmieren lernen, um der Architekt zu sein?

Nein – aber du musst die Grundlagen lernen, wie Systeme zusammenpassen: Entitäten, Beziehungen, eine einzige Wahrheitsquelle, Berechtigungen. Du triffst diese Entscheidungen; die KI schreibt die Umsetzung. Diese Fähigkeit lässt sich in Wochen lernen, und sie ist der Unterschied zwischen einem Projekt, das in Monat 3 stirbt, und einem, das sich aufsummiert. Wenn du darauf deinen Ausstieg aus dem Konzern aufbaust, miss zuerst, wie dringend du ihn brauchst – und baue ihn dann auf einem echten Fundament.