Sie haben Ihr MVP an einem Wochenende ausgeliefert. Nach drei Wochen haben sich einige hundert Nutzer angemeldet, und das Dashboard, das Sie mit Cursor oder Lovable gebaut haben, steht noch. In Woche sechs beginnen sich Support-Anfragen zu häufen: ein Login, der bei einem Kunden abbricht, ein Stripe-Webhook, der eine Zahlung stillschweigend verwirft, und eine Vercel-Rechnung, die nichts mit dem kostenlosen Tarif gemein hat, für den Sie sich angemeldet haben.
Dieses Muster ist inzwischen weit verbreitet. Laut TechCrunch hatten etwa ein Viertel dieser Startups Codebasen, die zu 95 % oder mehr KI-generiert waren. Vibe coding for startups ist nicht mehr experimentell – es ist die Standardmethode. Wie jeder Standard bringt es Annahmen mit, die den Kontakt mit echten Nutzern nicht überleben.
Der erste Monat einer Vibe-Coded-App gehört Freunden und Familie. Der zweite Monat gehört echten Kunden, Abrechnungsschwellen und Edge-Cases, auf die die KI nie trainiert wurde. Hier taucht die technische Schuld des Vibe-Codings schließlich an der Oberfläche auf – und meist alles auf einmal. Wenn Sie sich einen Eindruck von den Produkten verschaffen möchten, die auf diese Weise entstehen, sind die bekanntesten Vibe-Coded-Apps inzwischen in der Produktion im Einsatz.
Im Folgenden sind zwölf Punkte aufgeführt, die in fast keinem Tutorial zum zweiten Monat erwähnt werden. Je schneller Sie das Muster erkennen, desto günstiger wird die Bereinigung des Vibe-Codes.
Warum Monat zwei technische Schulden des Vibe-Codings aufdeckt
Drei Kräfte summieren sich um die Wochen vier bis acht. Jede einzelne ist überlebbar. Zusammen erzeugen sie die Klippe, die Gründer als “alles ist gleichzeitig kaputtgegangen” beschreiben.
Erstens ersetzen echte Nutzer Early Adopters. Menschen, die nicht beim Aufbau des Produkts mitgeholfen haben, testen Eingaben, die niemand vorhergesehen hat, und KI-generierter Code ist bekanntermaßen dünn bei Edge-Cases. Die MIT-Sloan-Management-Review-Analyse 2025 ergab, dass Produktivitätsgewinne oft als sich aufschaukelnde technische Schulden innerhalb des ersten Quartals nach der Bereitstellung wieder auftauchen, insbesondere wenn unerfahrene oder nicht-technische Entwickler ohne Review ausliefern.
Zweitens stoßen die kostenlosen Tarife an ihre Grenzen. Vercel, Supabase, OpenAI und die anderen sind großzügig bis zu einer stillen Schwelle. Die Messung läuft weiter, auch wenn Ihre Funktionen es nicht tun.
Drittens taucht die KI-Übergabelücke auf. Sie bitten das Modell, eine kleine Funktion hinzuzufügen, es nimmt die Änderung vor, und drei unzusammenhängende Dinge brechen. Niemand – weder Sie noch die KI – hatte die gesamte Architektur im Kopf, also bemerkte niemand die Abhängigkeit. Die zwölf folgenden Punkte lassen sich sauber auf eine dieser drei Kräfte zurückführen.
Wo Vibe-Coded-Apps zuerst brechen
Die Liste ist in vier Themen unterteilt. Drei Punkte betreffen Sicherheit, drei sind reine architektonische Schulden, drei beinhalten stille Ablaufdaten, und drei decken die Prozesslücken auf, die Monat zwei schließlich enthüllt.
Unsichtbare Sicherheitsrisiken.
1–3
KI generiert Happy-Path-Auth und überspringt Verteidigungsebenen.
Architektonische Schulden unter “es funktioniert”.
4–6
Code sieht modular aus, versteckt aber gemeinsamen Zustand.
Dinge, die still ablaufen.
7–9
Kein KI-Prompt sagt “erneuern Sie dies in 90 Tagen”.
Prozesslücken, die Monat zwei enthüllt.
10–12
Die Generierung hat Dokumentation und Tests überholt.
Der erste echte Nutzer findet Ihren Authentifizierungsfehler
KI-Tools generieren Login-Flows, die für Happy Paths funktionieren. Sie bieten selten Rate-Limiting, Session-Ablauf oder rollenbasierte Zugangskontrolle an. Der Veracode-2025-GenAI-Code-Security-Report ergab, dass rund 45 % der KI-generierten Codebeispiele ausnutzbare Schwachstellen enthielten, wobei Authentifizierung stets an der Spitze stand. Häufige Sicherheitsrisiken beim Vibe-Coding treten hier zuerst auf, da Auth der erste Endpunkt ist, den echte Nutzer aktiv ausprobieren. Ein strukturierter Sicherheits-Code-Review erkennt diese Muster, bevor sie die Produktion erreichen.
Das Passwort-Reset hat still aufgehört zu funktionieren
Das Passwort-Reset ist der am häufigsten ausgelieferte und am wenigsten getestete Flow in Vibe-Coded-Apps. Die KI baut das Formular, generiert den Token und sendet die E-Mail. Was sie selten sauber behandelt:
- Token-Ablauf-Edge-Cases (ein Token, der in einer Stunde ablaufen sollte, lebt still ewig weiter).
- SMTP-Fehlkonfiguration in der Produktion (funktioniert lokal, schlägt hinter einem Proxy fehl).
- Rate-Limiting am Reset-Endpunkt (was ihn zu einem kostenlosen E-Mail-Bombing-Vektor macht).
Dies ist einer der häufigsten stillen Vibe-Coding-Fehler. Nutzer gehen davon aus, dass das System unzuverlässig ist, und kündigen ohne Rückmeldung.
Der Stripe-Webhook verwirft Ereignisse lautlos
Stripe und andere Payment-Webhooks benötigen Idempotenz-Schlüssel, Retry-Handling und eine Warteschlange für fehlgeschlagene Ereignisse. KI-generierte Webhook-Handler überspringen meist alle drei. Zahlungen gelingen, aber Ihre Datenbank denkt, sie haben es nicht, oder dieselbe Zahlung wird zweimal registriert. Beide Varianten kosten Sie Geld.
Sie werden das nicht bemerken, bis ein Kunde wegen einer fehlenden Quittung oder einer Doppelbelastung eine E-Mail schreibt. Zu diesem Zeitpunkt läuft das Problem seit zwei Wochen, und die Abstimmung dauert länger als das Erkennen es gedauert hätte.
Ihre Datenbank kriecht bei 10.000 Zeilen
Die gleiche Abfrage, die am Launch-Tag in 80 Millisekunden zurückgab, dauert bei 10.000 Zeilen sieben Sekunden. Die Ursache ist fast immer identisch: KI-generierter Code verwendet standardmäßig ORM-Muster, die eine Abfrage pro Datensatz auslösen statt einer Batch-Abfrage.
Erschwerend kommt hinzu, dass Vibe-Coded-Apps selten Datenbankindizes auf den abgefragten Spalten haben. Wer von Anfang an für skalierbare Architektur entwickelt, verhindert dies; nachträglich zu beheben erfordert jemanden, der den tatsächlichen Abfrageplan lesen kann.
Eine Funktion anfassen, drei andere brechen
Das ist der charakteristische Vibe-Coding-Fehler. Sie bitten Claude oder Cursor, ein Formular zu aktualisieren, und eine Funktion, über die Sie seit Wochen nicht nachgedacht haben, hört auf zu funktionieren. Die Grundursache ist versteckte Kopplung. KI-Tools generieren Code, der modular aussieht, aber unter der Haube Zustand, Datenbanktabellen oder globale Variablen teilt.
Das Muster verstärkt sich mit jedem Sprint. Je länger es unbehandelt bleibt, desto schwieriger wird es vorherzusagen, welche Dateiänderung welchen Nutzer-Flow bricht.
Die „Modulare“ Architektur ist ein verkleideter Monolith
Ihre Dateistruktur sieht sauber aus. Es gibt einen components-Ordner, einen api-Ordner, einen lib-Ordner. Jede Datei ist angemessen kurz. All das bedeutet für sich genommen nichts. Vibe-Coded-Apps sehen von außen häufig wie Microservices aus, verhalten sich aber innen wie ein einzelner eng gekoppelter Monolith.
Der Test ist einfach: Wählen Sie eine beliebige Datei und versuchen Sie zu erklären, was kaputtgehen würde, wenn Sie sie löschen. Wenn die Antwort das Öffnen von vier weiteren Dateien erfordert, ist Ihre Architektur theatralisch statt strukturell. Echte Modularität besteht einen Löschtest.
Eine nicht fixierte Abhängigkeit liefert einen Breaking Change
Wenn die KI Ihre package.json, listet sie Abhängigkeiten normalerweise mit Caret- oder Tilde-Versionsbereichen auf. Das bedeutet, npm zieht bei jeder Installation die neueste Patch- oder Minor-Version. Wenn eines dieser Upstream-Pakete einen Breaking Change liefert, hört Ihr Build auf zu funktionieren. Sie haben nichts falsch gemacht – Sie haben einfach nicht fixiert.
Drei Wochen in der Produktion ist ein typisches Zeitfenster, in dem das auftaucht. Sperren Sie die Versionen explizit an dem Tag, an dem Sie zahlende Kunden haben.
SSL, Domain oder API-Schlüssel ist gerade abgelaufen
Das ist der dümmste Punkt auf der Liste, und der, den Gründer nicht ernst nehmen, bis er eintritt. Ihr SSL-Zertifikat erneuert sich nach einem Zeitplan, den Sie vergessen haben, Ihre Domain-Registrierung läuft in 60 Tagen ab, und Ihr OpenAI-Schlüssel wurde mit einem 90-Tage-Ablauf eingerichtet, den Ihr ehemaliger Mitgründer eingestellt hat.
Es gibt keinen KI-Prompt für “und bitte daran erinnern, dies in drei Monaten zu erneuern”. Kalender-Erinnerungen sind unspektakulär, und sie verhindern mehr Ausfälle als jede Framework-Entscheidung.
Die Free-Tier-Rechnung landet in Ihrem Posteingang
Sie haben ein Vercel-Funktionsaufruf-Limit, einen Supabase-Zeilen-Schwellenwert oder ein OpenAI-Token-Budget überschritten. Keiner dieser Anbieter warnt Sie im Voraus mit etwas, das wie eine Warnung aussieht. Sie senden eine Status-E-Mail, die wie eine routinemäßige Abrechnung aussieht.
Die erste Überraschungsrechnung ist in der Regel drei- bis fünfmal so hoch, wie ein bezahlter Plan im Voraus gekostet hätte. Die Lektion lautet: Alarme setzen, keine Budgets. Budgets stoppen Dienste, wenn Sie sie überschreiten; Alarme geben Ihnen die Möglichkeit zu reagieren, bevor die Seite ausfällt.
Keine Tests, kein Sicherheitsnetz für den nächsten Prompt
Vibe-Coded-Apps enthalten fast nie automatisierte Tests. KI-Tools generieren Funktionen, nicht das Sicherheitsnetz darum herum. Jeder nachfolgende Prompt hat keine Möglichkeit zu überprüfen, ob zuvor funktionierende Flows noch funktionieren, daher ist jede Änderung ein Münzwurf.
Die minimale nützliche Abdeckung ist klein. Drei Tests decken den größten Teil der relevanten Oberfläche ab:
- Registrierung und Login
- Die primäre Aktion, die Sie bezahlt (Checkout, Abonnement, Upload, Generierung)
- Ein End-to-End-Happy-Path
Diese drei Tests verhindern mehr Vibe-Coding-Fehler als jede andere einzelne Maßnahme, die Sie diesen Monat ergreifen können.
Die KI benennt Ihren öffentlichen Endpunkt um
Beim Beheben eines unzusammenhängenden Fehlers entschied Ihr KI-Assistent, dass der Endpunkt /api/v1/user-profile anstatt /api/user. Das Frontend wurde aktualisiert, lokale Tests wurden aktualisiert, und die Änderung wurde zusammengeführt. Ihre mobile App, der Drittanbieter-Integrationspartner und die Dokumentationsseite auf Ihrer Website rufen alle noch den alten Endpunkt auf.
This is a vibe coding risk unsichtbar während der Entwicklung und katastrophal in der Produktion ist. Jeder öffentliche API-Endpunkt benötigt einen expliziten “Nicht umbenennen”-Kommentar, den die KI zusammen mit der Datei liest.
Die Investor-Due-Diligence fragt nach dem Architekturdiagramm
Sie haben eine kleine Runde eingesammelt, und der technische Berater des Investors schickte eine höfliche E-Mail mit der Bitte um das Architekturdiagramm, die Abhängigkeitskarte und die Sicherheitsüberprüfung. Sie haben nichts davon, und die KI kann es nicht nachträglich schreiben, weil die Entscheidungen nie Entscheidungen waren, nur Ausgaben.
Ein handgezeichnetes Architekturdiagramm aus der ersten Woche erspart Ihnen einen hektischen Sonntag vor dem Due-Diligence-Gespräch. Das Gleiche gilt für das Befolgen einiger Vibe-Coding-Best-Practices vom ersten Tag an, wie das Schreiben eines Satzes pro Merge über das, was sich geändert hat und warum.
Was Monat zwei wirklich sagt
Die zwölf Punkte teilen eine Grundursache. KI-Coding-Tools optimieren für Code, der jetzt läuft, nicht für Code, der echte Nutzer, echte Daten und echte Zeit übersteht. Monat zwei ist der erste Moment, in dem Ihre App alle drei gleichzeitig hat.
Das ist der Moment, in dem die Prototypenphase endete und die Produktphase begann. Jedes Team, das über Monat drei hinauskommt, behandelt diesen Übergang als geplantes Ereignis. Je schneller Sie akzeptieren, dass ein Vibe-Coded-MVP jetzt ein Kandidat für Legacy-Code-Modernisierung ist, desto günstiger wird das nächste Quartal.
Wie ein ordentliches Vibe-Code-Cleanup laussieht, hängt davon ab, wie viel Runway Sie haben, aber die Reihenfolge ändert sich selten. Sie prüfen, was strukturell solide ist, beheben zuerst die kritischen Vibe-Coding-Sicherheits-probleme, refaktorisieren die architektonischen Muster, die die Skalierung blockieren, und fügen Testabdeckung rund um die Flows hinzu, die Sie bezahlen. AI code refactoring beschleunigen die Routineteile, während ein Senior-Ingenieur die Ermessensentscheidungen über das Refactoring und das Neuschreiben von einer sauberen Basis trifft.
Das Befolgen einiger Vibe-Coding-Best-Practices geht schneller zurück als jede Framework-Entscheidung. Fixieren Sie Abhängigkeiten. Testen Sie die drei Flows, die wichtig sind. Halten Sie ein Architekturdiagramm aktuell. Setzen Sie Abrechnungsalarme. Die Disziplin kostet Stunden; sie nicht zu haben kostet Wochen. Wenn Ihr Team nicht in der Lage ist, die Arbeit direkt zu erledigen, ist das genau der Zeitpunkt, an dem ein strukturiertes Vibe-Coding-Cleanup-Engagement am schnellsten zurückzahlt, oft innerhalb desselben Quartals, in dem Sie es starten.
Für Teams, die von Grund auf bauen statt aufzuräumen, gilt dieselbe Logik umgekehrt. Senior-Engineering von Anfang an in künstliche Intelligenz-Entwicklung einzubringen verhindert, dass die meisten Punkte auf dieser Liste jemals auftauchen. Ob Sie dies intern oder durch laufende Software-Wartung mit einem externen Team handhaben, die Kostenkurve für das Beheben von Vibe-Coding-Bugs steigt mit jeder Woche, die Sie verzögern.
Zusammenfassung
Monat zwei muss keine Krise sein. Die zwölf oben genannten Probleme sind vorhersehbar, was bedeutet, dass sie planbar sind. Die meisten können mit einigen Tagen Arbeit am Anfang verhindert werden, und alle können behoben werden, wenn sie auftreten, meist schneller als Gründer erwarten. Die Teams, die mit ihrem Runway intact über Monat drei hinausgehen, erkennen die Muster frühzeitig und handeln gezielt, nicht reaktiv. Wenn die Punkte auf dieser Liste mit dem übereinstimmen, was Sie gerade auf Ihrem Dashboard sehen, kontaktieren Sie uns und wir helfen Ihnen, das Schlimmste zu priorisieren, bevor der nächste Abrechnungszyklus kommt.
FAQ
Was ist technische Schuld beim Vibe-Coding?
Das ist die Wartungslast, die sich in KI-generierten Codebasen ansammelt, die ohne architektonische Überprüfung, automatisierte Tests oder Sicherheitshärtung ausgeliefert werden. Sie taucht um die Wochen vier bis acht als Authentifizierungsfehler, Skalierungsprobleme und Breaking Dependencies auf. Das Muster wächst schneller als traditionelle technische Schulden, weil der ursprüngliche Autor (die KI) sich nicht an die getroffenen Entscheidungen erinnert, was bedeutet, dass niemand erklären kann, warum der Code so geformt ist, wie er ist.
Ist Vibe-Coding produktionsreif?
Ja für Prototypen und interne Tools, nein für Apps, die Nutzerdaten, Zahlungen oder echten Traffic ohne eine Sicherheits- und Architekturüberprüfung zuerst verarbeiten. Branchenforschung zeigt, dass fast die Hälfte des KI-generierten Codes ausnutzbare Sicherheitslücken enthält. KI-entwickelte Software kann produktionsreif werden, aber erst nach einem strukturierten Cleanup, der Tests hinzufügt, Authentifizierung behebt und verschlungene Logik entkoppelt.
Kann eine Vibe-Coded-App repariert werden, ohne sie von Grund auf neu zu schreiben?
Fast immer, ja. Ein vollständiges Neuschreiben ist selten der richtige Ausgangspunkt. Ein gezieltes Refactoring prüft, was strukturell solide ist, behebt kritische Sicherheits- und Datenbankprobleme und fügt Testabdeckung rund um die Flows hinzu, die Sie bezahlen. Dieser Ansatz bewahrt die funktionierenden Teile und ist deutlich schneller und günstiger als das Neuaufbauen von Grund auf.
Wie erkennen Sie, wann eine Vibe-Coded-App ein Cleanup benötigt?
Achten Sie auf vier Signale: Änderungen, die nicht verwandte Funktionen brechen, Performance, die unter echtem Traffic abbaut, wiederkehrende Fehler beim Login oder Checkout und die Unfähigkeit, neue Funktionen sicher auszuliefern. Jedes einzelne davon ist ein Warnsignal. Alle vier bedeuten, dass die Codebasis jede Woche aktiv an Wert verliert, wenn sie unverändert bleibt.
Erfahren Sie, wie Redwerk eine strauchelnde Fitness-App von einem anderen Anbieter übernahm, die übernommenen technischen Schulden bereinigte und Pridefit half, Abonnements um 45%
