Sie haben Ihren MVP mit einem Vibe-Code versehen. Jetzt steckst du fest.

Du hast etwas Echtes aufgebaut. Sie haben Lovable oder Bolt.new geöffnet, Ihre Idee in einfachem Englisch beschrieben und gesehen, wie innerhalb weniger Minuten eine funktionierende App erschien. Sie haben sich durch die Bildschirme geklickt. Du hast es Freunden gezeigt. Sie haben es auf X gepostet und Ihre ersten „Das ist krank“-Antworten erhalten. Das ist beeindruckend und Sie sollten sich dabei wohlfühlen.

Aber jetzt sind es drei Wochen her und die Dynamik hat nachgelassen. Sie verbringen mehr Zeit damit, defekte Funktionen zu reparieren, als neue zu erstellen. Ihr Supabase-Dashboard enthält Tabellen, die Sie nicht vollständig verstehen. Ihre Authentifizierung funktioniert auf dem Desktop, funktioniert jedoch auf Mobilgeräten nicht. Sie benötigen die Stripe-Integration und jede Eingabeaufforderung, die Sie versuchen, erzeugt Code, der mit dem bereits vorhandenen Code in Konflikt steht.

Du bist an die Wand gefahren. Und du bist nicht allein.

Die 80/20-Wand: Wo die Vibe-Codierung zusammenbricht

Vibe-Codierungstools wie Lovable, Bolt.new, Replit Agent und v0 sind in den ersten 80 % eines Produkts außergewöhnlich. Sie generieren UI-Komponenten, vernetzen Datenbanken, erstellen Authentifizierungsflüsse und produzieren etwas, das wie eine echte App aussieht und sich anfühlt. Für die Prototypenerstellung und Validierung sind sie der schnellste Weg von der Idee zur Demo, den es je gab.

Das Problem sind die letzten 20 %. Dort leben Randfälle. Hier muss die Zahlungsabwicklung fehlgeschlagene Belastungen, Teilrückerstattungen und Webhook-Wiederholungsversuche verarbeiten. Hier muss Ihr mehrstufiges Formular den Fortschritt speichern, schrittübergreifend validieren und nach Browserabstürzen wiederherstellen. Hier muss Ihre App funktionieren, wenn zwei Benutzer gleichzeitig denselben Datensatz bearbeiten.

KI meistert den glücklichen Weg hervorragend. Es kämpft mit den unzufriedenen Pfaden, und Produktionssoftware besteht zu 80 % aus unzufriedenen Pfaden. Was passiert, wenn das Netzwerk mitten in der Transaktion abbricht? Wenn ein Benutzer ein Formular zweimal sendet? Wenn Ihre Datenbankabfrage 50.000 statt 50 Zeilen zurückgibt? Dies sind die Fragen, die eine Demo von einem Produkt unterscheiden, und es sind die Fragen, die Vibe-Coding-Tools nicht mit einer einzigen Eingabeaufforderung beantworten können.

Entwickler nennen dies die 80/20-Wand. Die ersten 80 % erfordern 20 % des Aufwands. Die letzten 20 % erfordern 80 % des Aufwands. Vibe-Codierungstools komprimieren die ersten 80 % von Wochen auf Stunden. Aber die letzten 20 % komprimieren sie überhaupt nicht. Sie machen es schwieriger, weil der von ihnen generierte Code nicht darauf ausgelegt ist, damit umzugehen.

Das Sicherheitsproblem, über das niemand spricht

Hier ist der Teil, der Sie nachts wach halten sollte. Das ergab eine Sicherheitsanalyse der von Lovable generierten Anwendungen10,3 % hatten kritische Sicherheitslücken auf Zeilenebene (RLS).in ihren Supabase-Datenbanken. Das bedeutet, dass jede zehnte App über Datenbanktabellen verfügte, in denen jeder authentifizierte Benutzer die Daten anderer Benutzer lesen, ändern oder löschen konnte. Kein theoretisches Risiko. Ein funktionierender Exploit.

Dies ist nicht auf Lovable beschränkt. Eine CodeRabbit-Analyse von 470 Pull-Requests ergab, dass KI-generierter Code dies getan hat2,74-mal höhere Sicherheitslückenratenim Vergleich zu von Menschen geschriebenem Code. Die gleiche Analyse ergab1,7-mal mehr größere Problemegesamt. KI schreibt Code, der funktioniert. Es wird kein Code geschrieben, der sicher ist.

Die realen Konsequenzen sind bereits da. Moltbook, ein auf KI basierendes soziales Netzwerk, wurde mit öffentlich zugänglicher Supabase-Datenbank gestartet. Das Ergebnis:1,5 Millionen API-Schlüssel und 35.000 Benutzer-E-Mails offengelegt. Das ergab eine unabhängige Prüfung11 % der Indie-Start-URLs legen Supabase-Anmeldeinformationen in ihrem Frontend-Code offen. Dies sind keine Randfälle. Es sind Muster.

Vibe-Codierungstools erklären Ihnen die Sicherheit nicht, weil Sie nicht nach Sicherheit gefragt haben. Sie haben nach einem Benutzerregistrierungsformular gefragt und eines erhalten. Sie haben nicht gefragt: „Stellen Sie sicher, dass Benutzer nicht über direkte API-Aufrufe auf die Daten anderer zugreifen können“, also hat das Tool dies nicht eingerichtet. RLS-Richtlinien, API-Schlüssel-Scoping, Eingabebereinigung, Ratenbegrenzung; Dies sind Dinge, die erfahrene Ingenieure standardmäßig hinzufügen, weil sie gesehen haben, was passiert, wenn Sie dies nicht tun.

Die Kreditverbrennungsfalle

Vibe-Codierungstools werden nach Credits, Token oder Rechenzeit abgerechnet. Der Pitch ist einfach: Beschreiben Sie, was Sie wollen, besorgen Sie sich funktionierenden Code, iterieren Sie. Die Realität sieht anders aus.

Liebenswerte User berichten400 Credits in weniger als einer Stunde durchbrennenbeim Debuggen einer komplexen Funktion. Benutzer von Bolt.new beschreiben, wie sie sich verfangenendlose Fehlerschleifenwo die KI eine Sache kaputt macht, während sie eine andere repariert. Plattformübergreifend melden Benutzer ihre Ausgaben30–40 % ihrer Eingabeaufforderungen reparieren Dinge, die die KI kaputt gemacht hatin vorherigen Eingabeaufforderungen.

Denken Sie über dieses Verhältnis nach. Für alle drei Aufforderungen, die Ihr Produkt voranbringen, dienen eine oder zwei Aufforderungen dazu, den Schaden zu beheben. Sie zahlen, um Fortschritte zu machen, und zahlen erneut, um das Chaos zu beseitigen. Das Tool, mit dem Sie eigentlich Geld sparen sollten, ist nun ein wiederkehrender Kostenfaktor mit sinkenden Erträgen.

Der Kreditverbrauch beschleunigt sich, wenn Ihre Codebasis wächst. Eine 500-Zeilen-App ist für die KI leicht nachzuvollziehen. Eine 5.000-Zeilen-App mit mehreren Seiten, gemeinsamem Status, API-Routen und Datenbankmigrationen ist dies nicht. Die KI beginnt, den Kontext zu verlieren. Es schreibt Komponenten neu, die Sie bereits repariert haben. Es führt Muster ein, die im Widerspruch zu den Mustern stehen, die es vor drei Eingabeaufforderungen verwendet hat. Sie geben mehr Credits für weniger Fortschritte aus und die Lücke wird mit jeder Sitzung größer.

Die Codequalitätsspirale

KI-generierte Codebasen weisen bestimmte Probleme auf, die sich mit der Zeit verschärfen.

Code-Duplizierung.Die Analyse vibecodierter Projekte zeigt ein8-fache Steigerung der Codeduplizierungim Vergleich zu von Menschenhand geschaffenen Projekten. Die KI erinnert sich nicht daran, dass sie bereits vor drei Dateien eine Datumsformatierungsfunktion geschrieben hat. Es schreibt ein neues. Dann noch einer. Dann ein etwas anderes. Jetzt verfügen Sie über vier Datumsformatierer mit jeweils unterschiedlichem Verhalten. Wenn Sie die Datumsanzeige in Ihrer App ändern möchten, müssen Sie alle vier finden und aktualisieren.

Inkonsistente Muster.Die Prompt-by-Prompt-Entwicklung erzeugt Code ohne architektonische Konsistenz. Eine Seite ruft Daten in einem useEffect-Hook ab. Ein anderer verwendet serverseitiges Rendering. Ein dritter ruft die API direkt von einem onClick-Handler auf. Keiner dieser Ansätze ist für sich genommen falsch, aber die Kombination aller drei in einer App schafft eine Codebasis, über die niemand nachdenken kann; nicht die KI und kein menschlicher Entwickler, den Sie später einstellen.

Fehlende Fehlerbehandlung.KI-generierter Code kümmert sich um den Erfolgsfall. Es rendert die Daten, wenn die API 200 zurückgibt. Es verarbeitet nicht, was passiert, wenn die API 500 zurückgibt, eine Zeitüberschreitung auftritt oder fehlerhaftes JSON zurückgibt. Produktionsbenutzer lösen diese Fehlermodi täglich aus. Ohne Fehlerbehandlung zeigt Ihre App leere Bildschirme, endlose Spinner oder kryptische Fehlermeldungen an, die Benutzer direkt zu Ihrem Konkurrenten weiterleiten.

Keine Tests.Vibe-Codierungstools generieren selten Tests, es sei denn, Sie fragen ausdrücklich danach. Und wenn Sie danach fragen, testen die Tests in der Regel, ob der Code das tut, was der Code tut (tautologische Tests), und nicht die Geschäftslogik und Grenzfälle. Wenn Sie später eine Funktion ändern müssen, gibt es kein Sicherheitsnetz. Jede Veränderung ist ein Glücksspiel.

Diese Probleme verschärfen sich. Doppelter Code erschwert das Auffinden von Fehlern. Inkonsistente Muster machen Änderungen riskant. Fehlende Fehlerbehandlung führt zu benutzerseitigen Fehlern. Keine Tests bedeuten, dass Sie kein sicheres Refactoring durchführen können. Jedes Problem verstärkt die anderen, bis die Codebasis einen Punkt erreicht, an dem die Behörden es für nötig haltenmehr Zeit, vorhandenen Vibe-Code zu reparieren, als bei Null anzufangen.

Wann sollte man mit der Vibe-Codierung aufhören und Ingenieure einstellen?

Nicht jedes Vibe-codierte Projekt muss gerettet werden. Manche Prototypen bestätigen eine Idee und werden verworfen. Das ist in Ordnung. Aber wenn Sie drei oder mehr dieser Fragen mit „Ja“ beantworten, ist es an der Zeit, Ingenieure hinzuzuziehen:

• Sie verbringen mehr Zeit mit dem Debuggen als mit dem Erstellen neuer Funktionen
• Sie verarbeiten echte Benutzerdaten (E-Mails, Zahlungen, persönliche Informationen).
• Sie benötigen eine Zahlungsabwicklung, eine Abonnementabrechnung oder Finanztransaktionen
• Ihre App muss für mehr als 100 gleichzeitige Benutzer zuverlässig funktionieren
• Sie integrieren APIs von Drittanbietern, die Webhooks oder OAuth erfordern
• Sie haben Ihr Kreditbudget zweimal aufgebraucht und Ihre Funktionsliste hat sich nicht geändert
• Sie können nicht sicher antworten: „Wer kann auf diese Daten zugreifen?“ für jede Tabelle in Ihrer Datenbank
• Sie planen die Beschaffung von Finanzmitteln und Investoren werden nach Ihrer technischen Architektur fragen
• Sie sind auf einen Fehler gestoßen, den Sie nach mehr als 20 Eingabeaufforderungen nicht beheben können

Am Übergangspunkt geht es nicht um Scheitern. Es geht darum zu erkennen, wo KI-Tools nicht mehr das richtige Werkzeug sind und erfahrene Ingenieure anfangen, das richtige Werkzeug zu sein. Ein Gründer, der ein MVP vibecodiert und die Nachfrage validiert hat, hat getan, was die meisten Startup-Ratschläge raten: schnell versenden, schnell lernen. Der nächste Schritt besteht darin, diesen validierten Prototyp in Produktionssoftware umzuwandeln.

Was eine Agentur anders macht

Eine häufige Reaktion auf die 80/20-Wand ist: „Ich werde lernen, zu programmieren und es selbst zu reparieren.“ Respektieren Sie diese Energie, aber bedenken Sie die Mathematik. Das Erlernen ausreichender React-, Datenbankdesign-, Authentifizierungs- und Bereitstellungsfunktionen zur Fertigstellung einer Produktionsanwendung erfordert 6–12 Monate gezieltes Lernen. Die Einstellung eines leitenden Ingenieurs für die Fertigstellung dauert 3–6 Wochen. Wenn Ihr Startup ein Marktfenster hat, schließt der 6-monatige Lernpfad dieses Fenster.

Bei Savi nutzen auch unsere leitenden Ingenieure KI-Tools. Wir verwenden täglich Cursor, Claude und Copilot. Der Unterschied besteht darin, dass wir sie als Beschleuniger zusätzlich zu unserer 5-10-jährigen Ingenieurserfahrung einsetzen und nicht als Ersatz dafür. Wir wissen, was wir anfordern müssen und, was noch wichtiger ist, was wir in der Ausgabe überprüfen müssen. Wir erkennen die RLS-Fehlkonfigurationen, die fehlenden Fehlergrenzen, die SQL-Injection-Vektoren und die Race Conditions, bevor sie Ihre Benutzer erreichen.

So sieht der Prozess aus, wenn uns ein Gründer einen Vibe-codierten Prototyp bringt:

Audit (1-2 Tage).Wir überprüfen Ihre bestehende Codebasis, Ihr Datenbankschema und Ihre Infrastruktur. Wir identifizieren Sicherheitslücken, Architekturprobleme und Code, der ersetzt werden muss. Wir geben Ihnen eine ehrliche Einschätzung: Kann das Problem behoben werden oder sollten wir neu anfangen? Manchmal verfügt eine Vibe-codierte App über solide UI-Komponenten und ein vernünftiges Datenbankschema, und wir können darauf aufbauen. In anderen Fällen weist das Fundament zu viele strukturelle Probleme auf und ein sauberer Anfang ist schneller und kostengünstiger.

Architektur (2-3 Tage).Wir entwerfen die Produktionsarchitektur. Datenbankschema mit geeigneten Indizes, RLS-Richtlinien und Migrationsstrategie. API-Schicht mit Authentifizierung, Ratenbegrenzung und Fehlerbehandlung. Frontend-Struktur mit konsistenten Datenabrufmustern, Statusverwaltung und Komponentenorganisation. Dies ist die Arbeit, die Vibe-Codierungstools vollständig überspringen.

Bauen (2-5 Wochen).Wir schreiben Produktionscode. Jede Funktion verfügt über Fehlerbehandlung, Ladezustände und Randfallabdeckung. Jede Datenbanktabelle erhält RLS-Richtlinien. Jede API-Route erhält eine Eingabevalidierung. Wir schreiben Tests für Geschäftslogik. Wir richten CI/CD-Pipelines ein, die Regressionen vor der Bereitstellung abfangen. Sie sprechen direkt mit dem Ingenieur, der Ihr Produkt entwickelt. Keine Projektmanager, die Nachrichten weiterleiten, keine wöchentlichen Statusanrufe, die eine Slack-Nachricht hätten sein können.

Start und Übergabe.Wir stellen es in der Produktion bereit, überwachen die erste Woche auf Probleme und geben Ihnen eine Codebasis mit Dokumentation, die Sie jedem Ingenieur auf der Welt mitgeben können. Keine Lieferantenbindung. Keine proprietären Frameworks. Standardtools, sauberer Code, Ihr Repository, Ihre Infrastruktur.

Wir erstellen Festpreisangebote. Sie kennen die Kosten, bevor wir eine Codezeile schreiben. Keine stündliche Abrechnung, die in die Höhe schießt, wenn das Debuggen länger dauert als erwartet. Es fallen keine „Änderungsanforderungs“-Zuschläge an, wenn Sie eine Funktion während der Erstellung klären.

Der Prototyp war der schwierige Teil. Der Abschluss ist der schlaue Teil.

Sie haben etwas getan, was die meisten Menschen nie tun: Sie haben eine Idee aufgegriffen, ein Werkzeug geöffnet und etwas gebaut, das Sie echten Menschen zeigen konnten. Dieser Prototyp hat bewiesen, dass Ihre Idee Bestand hat. Es hat bewiesen, dass Sie den Geschmack und den Antrieb haben, ein Produkt zu entwickeln.

Der nächste Schritt ist nicht dringlicher. Es ist Ingenieurskunst. Es sind die Sicherheitsverstärkung, die Randfallbehandlung, die Leistungsoptimierung und die Infrastrukturentscheidungen, die aus einem Prototyp eine Software machen, für die Menschen bezahlen und der sie ihre Daten anvertrauen.

Sie müssen kein Ingenieur werden, um ein Softwareunternehmen aufzubauen. Sie müssen jemanden einstellen, der weiß, wann KI eingesetzt werden muss und wann der Code von Hand geschrieben werden muss. Das ist der Unterschied zwischen einer Demo und einem Produkt.

Häufig gestellte Fragen