Lovable, Bolt, v0, Cursor: Was Tun, Wenn Der KI-Code Kaputt Ist

Es gibt eine Szene, die ich inzwischen fast woechentlich erlebe. Jemand baut sich an einem Wochenende mit Lovable, Bolt oder v0 ein lauffaehiges Demo, freut sich, zeigt es Freunden und der Familie. Dann will er eine einzige Sache ergaenzen - Zahlungen, einen Login, einen weiteren Bildschirm - und alles faengt an einzustuerzen. Er bittet die KI, das zu reparieren. Sie repariert es. Eine Stunde spaeter ist etwas kaputt, das vorher lief. Wieder die Bitte um Reparatur. Nach dem zehnten Durchlauf ist der Code so weit, dass weder er noch die KI noch versteht, was eigentlich passiert.

Wenn Sie sich hier wiedererkennen: Das ist nicht Ihre Schuld und kein Zeichen von Unvermoegen. Genau dafuer sind diese Tools gemacht - eine Idee schnell sichtbar zu machen. Das Problem beginnt erst, wenn Sie aus dem Demo ein echtes, an Nutzer auslieferbares Produkt machen wollen. In diesem Artikel lege ich offen, wo jedes Tool an seine Grenze stoesst, warum die KI etwas "repariert" und gleich wieder zerlegt, was Sie vor der Anfrage vorbereiten sollten und wann sich Retten lohnt statt sauberem Neuaufbau. Ich rede dabei nicht aus der Theorie - ich uebernehme solche Projekte tatsaechlich und mache aus kaputtem Lovable- oder Bolt-Code etwas, das in Produktion laeuft, mit echten Nutzern und echtem Geld.

Warum die KI bis 80 Prozent fuehrt und dort stehen bleibt

Lovable, Bolt und v0 erledigen den sichtbaren Teil erstaunlich schnell - Buttons, Formulare, Bildschirme, ein schoenes Layout. Das sind grob 80 Prozent von dem, was nach "App" aussieht. Aber die restlichen 20 Prozent - Zahlungen, Authentifizierung, Datenbank, Deployment, Sicherheit, DSGVO, Randfaelle - sind der schwerste, teuerste und genau der Teil, durch den die App ueberhaupt erst mit echten Menschen funktioniert. Dort verbessert die KI nicht, dort prallt sie ab.

Der Grund ist einfach. Die sichtbare Schicht ist schablonenhaft: Aehnliche Formulare und Bildschirme gibt es millionenfach im Netz, die KI hat sie "gesehen" und gibt sie im Sekundentakt wieder. Die restlichen 20 Prozent dagegen sind einzigartig fuer Ihr Projekt und verlangen Entscheidungen, die man nur im Verstaendnis des Ganzen treffen kann: wie Daten fliessen, wer was sehen darf, was passiert, wenn eine Zahlung fehlschlaegt. Das ist kein Kopieren, das ist Ingenieursarbeit. Und genau dort beginnt alles zu brechen.

Wo es je nach Tool bricht

Jedes Tool hat seinen eigenen "Charakter" und seine typische Bruchstelle. Wer sie kennt, versteht viel schneller, was er da eigentlich in der Hand haelt.

Lovable - Deployment und Datenbank

Lovable baut eine vollstaendige Anwendung (React plus Supabase) und uebernimmt vieles selbst, weshalb es anfangs magisch wirkt. Kaputt geht es aber meist an zwei Stellen. Erstens die Supabase-Datenbank: Sobald das Datenmodell komplexer wird, beginnt das Durcheinander mit den RLS-Regeln (Row Level Security, der Zugriffsschutz auf Zeilenebene), Tabellenbeziehungen verhaken sich, und Abfragen liefern entweder zu viel oder gar nichts. Zweitens Deployment und Umgebungen: In der Lovable-Vorschau laeuft es, auf der echten Domain mit echten Variablen nicht mehr, weil Schluessel, URLs oder CORS nur fuer den "Demo-Modus" konfiguriert sind.

Bolt - State und Integrationen

Bolt generiert ein interaktives Frontend hervorragend schnell. Die Grenze: sobald die App viel Zustand (State) bekommt - Warenkorb, eingeloggter Nutzer, Filter, voneinander abhaengige Formulare. Dieser State faengt an zu "entgleiten": Sie klicken hier, und etwas voellig Unzusammenhaengendes aktualisiert sich dort. Die zweite Schmerzstelle von Bolt sind Integrationen mit echten Systemen: Zahlungen, E-Mail, externe APIs. Auf Demo-Ebene zeigt Bolt, "wie es aussehen wuerde", aber fuer den echten Anschluss braucht es eine Serverseite, Secret-Management und Fehlerbehandlung, die schnelles Generieren nicht liefert.

v0 - schoenes UI, aber kein Backend

v0 (von Vercel) ist in dieser Gruppe der Beste fuer eine Sache: eine wirklich schoene React/Next.js-Oberflaeche oder eine ganze Seitenansicht zu bauen. Wichtig ist nur zu verstehen, was es tut: Es baut die Vorderseite. Keine Datenbank, kein Login, keine Serverlogik, kein Ort, an dem echte Daten liegen. Menschen bleiben haengen, weil sie einen wunderbar aussehenden Bildschirm haben und denken, es sei "nur noch anzuschliessen" - in Wirklichkeit liegt die gesamte schwere Arbeit noch vor ihnen, die v0 gar nicht erledigen sollte. Das ist kein Mangel von v0, sondern ein Missverstaendnis darueber, wofuer es gedacht ist.

Cursor - generiert, aber Sie muessen es verstehen

Cursor ist anders als die drei oben: ein Editor mit starker KI, gedacht fuer jemanden, der bereits Code lesen kann. Es schreibt viel und schnell. Aber wenn Sie nicht beurteilen koennen, was es geschrieben hat, laesst es Sie nur schneller etwas anhaeufen, das Sie nicht verstehen. Das typische Szenario: Cursor generiert komplexe Logik, sie laeuft fast, Sie bitten um eine kleine Korrektur, es schreibt mehr um als noetig, und ploetzlich haben Sie 2.000 Zeilen, die Sie weder lesen noch sicher aendern koennen. Cursor ist wunderbar fuer Profis und gefaehrlich fuer jeden, der erwartet, dass es "alles von allein regelt".

Warum die KI "repariert" und gleich wieder zerlegt

Das ist eine der haeufigsten Fragen, die ich hoere: "Warum repariert es die eine Stelle und zerstoert die andere?" Die Antwort ist Kontextverlust. Die KI sieht nicht Ihr ganzes Projekt auf einmal als zusammenhaengendes System. Bei jeder Korrektur arbeitet sie mit einem begrenzten, sichtbaren Ausschnitt, "erinnert" sich nur an so viel, wie hineinpasst, und raet beim Rest. Waehrend sie Stelle A repariert, aendert sie unbemerkt etwas, von dem Stelle B abhaengt, ueber die sie gerade "nichts wusste".

Je groesser das Projekt, desto schneller dreht sich dieser Kreis. Anfangs, solange wenige Dateien da sind, haelt die KI noch alles "im Kopf" und wirkt grossartig. Ab einer bestimmten Groesse hat jede neue Reparatur eine wachsende Wahrscheinlichkeit, etwas anderes zu zerlegen - und ploetzlich stecken Sie in einer Schleife, aus der die KI Sie nicht herausholt, weil sie selbst deren Ursache ist. Ein Mensch durchbricht diese Schleife schlicht: Er haelt die ganze Architektur im Kopf, versteht die Ursache statt nur das Symptom und repariert einmal so, dass es repariert bleibt. Wo die KI zehnmal flickt, behebt ein Mensch, der es versteht, es ein einziges Mal.

Was Sie VOR der Anfrage tun sollten

Wenn Sie entschieden haben, Hilfe zu suchen - egal ob bei mir oder anderswo -, gibt es drei Dinge, mit denen die Einschaetzung schnell und genau ablaeuft statt als teures Raten. Diese drei Dinge erledigen Sie selbst in einer halben Stunde.

Mit diesen drei Dingen kann ich in recht kurzer Zeit sagen, ob punktuelle Reparaturen genuegen oder ein Teil guenstiger neu gebaut wird, und was es realistisch kostet. Ohne sie bleiben nur allgemeine Floskeln, die niemandem nuetzen.

Retten oder neu aufbauen?

Die wichtigste Entscheidung. Und entgegen der Erwartung ist die richtige Antwort nicht immer "wirf alles weg und schreib von null". Ich entscheide nach einem Blick in den Code, aber die Logik ist ungefaehr diese.

Situation	Was ich tue
UI sauber, Probleme lokal (Zahlungen verbinden nicht, Deployment bricht, eine Integration)	Ich rette. Punktuelle Reparaturen, oft der guenstigste Weg.
Frontend gut, aber kein echtes Backend oder Datenmodell	Gemischt. Ich behalte das Frontend und baue darunter ein sauberes Backend.
Logik verstreut, jede Reparatur zerlegt anderes, niemand versteht die Struktur	Ich baue neu. Ich nutze die Oberflaeche als Spezifikation und schreibe den Code sauber.
Es ist ein internes Tool oder Demo, nicht fuer echte Kunden und Geld	Vielleicht reicht Ihnen die KI. Ich sage es offen, wenn Sie mich nicht brauchen.

Die letzte Zeile ist mir wichtig. Wenn Ihr Projekt ein Hobby ist, ein internes Tool fuer ein paar Leute oder die Visualisierung einer Idee, dann reicht Ihnen die KI wirklich, und das sage ich Ihnen auch. Ich versuche nicht, Arbeit dort zu verkaufen, wo sie nicht noetig ist. Das ist uebrigens auch das Zeichen dafuer, dass ich, wenn ich sage "hier muss neu gebaut werden", das nicht wegen der Rechnung sage. Mehr dazu, warum ein KI-Prototyp grundsaetzlich noch kein Produkt ist und was "laeuft auf meinem Bildschirm" von "laeuft fuer echte Nutzer" trennt, lesen Sie im Artikel "Vibe Coding: Warum ein KI-Prototyp noch kein Produkt ist".

Welches Tool wofuer taugt - und wo seine Grenze liegt

Eine kurze Tabelle, damit Sie bei der Auswahl nicht durcheinanderkommen. Das ist kein Ranking "bestes gegen schlechtestes", sondern eine Landkarte: fuer welche Arbeit jedes Tool gedacht ist und wo seine Moeglichkeiten enden.

Tool	Wofuer es taugt	Wo die Grenze liegt
Lovable	Vollstaendiges Demo mit DB und Login, schnelles MVP zur Ideenpruefung	Supabase-Regeln, Deployment auf echte Domain, wachsendes Datenmodell
Bolt	Interaktiver Frontend-Prototyp, schnelles Bild davon, wie es liefe	Komplexer State, echte Integrationen, Zahlungen, Serverseite
v0	Schoene React/Next.js-Komponenten und Seiten, UI-Grundlage	Gar kein Backend, keine DB, kein Login - nur die Vorderseite
Cursor	Schnelleres Entwickeln fuer jemanden, der Code lesen und beurteilen kann	Ohne Verstaendnis haeuft man schnell an, was man nicht mehr beherrscht

Realistische Preisrahmen

Offen gesagt, weil das niemand direkt ausspricht. Die Preise haengen davon ab, wie viel erhalten bleibt, aber die Rahmen sehen so aus. Alle Betraege verstehen sich als transparenter Festpreis zzgl. 19 Prozent USt., damit Sie vorab wissen, was geliefert wird und was es kostet.

• Lokale Reparaturen an einem sauberen Projekt (Deployment, eine Integration, ein State-Fehler): ab 800 bis 1.800 €
• Fertigstellung eines KI-MVP bis zum echten Go-live mit Login, Zahlungen, Daten und Deployment: 4.000 bis 9.000 €
• Sauberer Neuaufbau bis zur Produktionsreife unter Erhalt der guten Oberflaeche: ab 6.000 bis 12.000 € und mehr, je nach Integrationen

Den genauen Betrag nenne ich erst nach einem Blick in den Code - alles andere waere geraten. Aber diese Rahmen helfen, die Groessenordnung einzuschaetzen, damit Sie nach keiner Seite ueberrascht werden. Und oft beginnen wir mit einem kleinen Schritt: Ich pruefe, zeige Ihnen, was wirklich kaputt ist, und Sie entscheiden mit dem vollen Bild. Wie viel die vermeintlich "kostenlose" KI-Loesung am Ende wirklich kostet, beschreibe ich gesondert im Artikel "Die wahren Kosten einer kostenlosen KI-Website".

Haeufig gestellte Fragen

Koennen Sie mein Lovable-Projekt uebernehmen?

Ja. Lovable kann den Code nach GitHub synchronisieren, und sobald ich Zugriff auf das Repository habe, uebernehme ich das Projekt wie eine ganz normale React/Vite- plus Supabase-Anwendung. Zuerst lade ich es lokal herunter, starte es, sehe mir an, was wirklich kaputt ist, und entscheide erst dann, ob gezielte Reparaturen genuegen oder ob ein Teil sauberer neu gebaut werden sollte. Sie muessen vorab nichts auseinandernehmen, geben Sie mir einfach Zugang und eine kurze Beschreibung dessen, was die App tun soll.

Ist Bolt-Code produktionsreif?

Das Frontend ist oft gut genug, um es zu behalten. Aber produktionsreif heisst mehr als ein huebsches Interface: Es braucht ein sauberes State-Management, ein sicheres Backend, eine echte Datenbank, Authentifizierung, Zahlungen und Fehlerbehandlung. Bolt erzeugt ein schnelles Demo, nicht diese schwere Schicht. Deshalb behalte ich ein echtes Bolt-Projekt meist als UI-Grundlage und baue darunter ein verlaessliches Backend mit den noetigen Integrationen, damit es mit echten Nutzern und echtem Geld laeuft.

Warum repariert die KI denselben Code immer wieder und zerlegt ihn erneut?

Weil die KI nicht das ganze Projekt auf einmal sieht und keinen dauerhaften Kontext hat. Bei jeder Korrektur arbeitet sie mit einem begrenzten, sichtbaren Ausschnitt des Codes, also bricht sie beim Reparieren der einen Stelle unbemerkt eine andere, an die sie sich gerade nicht erinnert. Je groesser das Projekt, desto schneller beginnt dieser Kreislauf. Ein Mensch haelt die ganze Architektur im Kopf und behebt die Ursache statt des Symptoms, weshalb eine Reparatur repariert bleibt.

Was sollte ich vorbereiten, bevor ich wegen eines kaputten KI-Projekts anfrage?

Drei Dinge. Erstens Zugang zum Code: ein GitHub-Repository oder das exportierte Projekt, keine Screenshots. Zweitens Zugang zu den Diensten, die Sie nutzen (Supabase, Vercel, Zahlungs- oder E-Mail-Konten). Drittens fuenf bis zehn Saetze dazu, was die App tun soll und was konkret nicht funktioniert. Damit kann ich schnell den Zustand beurteilen und Ihnen sagen, ob Reparaturen genuegen oder sich ein Neuaufbau lohnt, samt realistischem Festpreis.

Wann lohnt es sich, bestehenden KI-Code zu retten, und wann ist ein Neuaufbau guenstiger?

Retten lohnt sich, wenn UI und Struktur sauber sind und die Probleme lokal bleiben: Zahlungen verbinden sich nicht, das Deployment bricht, eine Integration laeuft nicht. Ein Neuaufbau ist guenstiger, wenn die Logik verstreut ist, es kein echtes Backend oder Datenmodell gibt und jede Reparatur etwas anderes zerlegt. Oft ist der beste Weg gemischt: Ich behalte das gute Frontend und baue darunter ein sauberes Backend. Ich entscheide nach einem Blick in den Code, nicht im Voraus.

Was kostet es, ein KI-generiertes Projekt zu reparieren oder fertigzustellen?

Das haengt davon ab, wie viel erhalten bleibt. Lokale Reparaturen an einem sauberen Projekt liegen ab 800 bis 1.800 Euro. Die Fertigstellung eines KI-MVP bis zum echten Go-live mit Authentifizierung, Zahlungen, Daten und Deployment liegt meist bei 4.000 bis 9.000 Euro. Ein sauberer Neuaufbau bis zur Produktionsreife beginnt bei 6.000 bis 12.000 Euro und mehr, je nach Integrationen. Alle Preise verstehen sich als Festpreis zzgl. 19 Prozent USt. Den genauen Betrag nenne ich erst nach einem Blick in den Code, alles andere waere geraten.

Kurz gefasst

Lovable, Bolt, v0 und Cursor sind grossartige Tools fuer das, wofuer sie gedacht sind: eine Idee schnell sichtbar zu machen. Sie gehen nicht kaputt, weil sie schlecht waeren, sondern weil Sie aus dem Demo etwas machen wollen, das Ingenieursarbeit braucht - ein sicheres Backend, echte Integrationen, saubere Daten. Wenn Ihr Projekt feststeckt, drehen Sie nicht den zwanzigsten Durchlauf. Exportieren Sie den Code, sammeln Sie die Zugaenge, beschreiben Sie, was Sie wollten, und lassen Sie mich draufschauen - oft behalte ich Ihre gute Arbeit und baue darunter das, was ein erneutes Einstuerzen verhindert, damit es laeuft und Geld verdient, nicht nur huebsch aussieht.