Lovable, Bolt, v0, Cursor: Was tun, wenn der KI-Code kaputt ist

Es gibt eine Szene, die ich inzwischen fast wöchentlich erlebe. Jemand baut sich an einem Wochenende mit Lovable, Bolt oder v0 ein lauffähiges Demo, freut sich, zeigt es Freunden und der Familie. Dann will er eine einzige Sache ergänzen - Zahlungen, einen Login, einen weiteren Bildschirm - und alles fängt an einzustürzen. Er bittet die KI, das zu reparieren. Sie repariert es. Eine Stunde später 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 Unvermögen. Genau dafür 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 stößt, 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 – solche Projekte sehe ich ständig, und mein Weg mit ihnen ist immer derselbe: Kaputten Lovable- oder Bolt-Code übernehme oder flicke ich nicht, sondern nutze den Prototyp als Spezifikation und baue das Produkt von Grund auf – so, dass es in Produktion läuft, mit echten Nutzern und echtem Geld.

Warum die KI bis 80 Prozent führt und dort stehen bleibt

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

Der Grund ist einfach. Die sichtbare Schicht ist schablonenhaft: Ähnliche 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 für Ihr Projekt und verlangen Entscheidungen, die man nur im Verständnis des Ganzen treffen kann: wie Daten fließen, wer was sehen darf, was passiert, wenn eine Zahlung fehlschlägt. 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 hält.

Lovable - Deployment und Datenbank

Lovable baut eine vollständige Anwendung (React plus Supabase) und übernimmt 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 läuft es, auf der echten Domain mit echten Variablen nicht mehr, weil Schlüssel, URLs oder CORS nur für 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 abhängige Formulare. Dieser State fängt an zu "entgleiten": Sie klicken hier, und etwas völlig Unzusammenhängendes 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 würde", aber für den echten Anschluss braucht es eine Serverseite, Secret-Management und Fehlerbehandlung, die schnelles Generieren nicht liefert.

v0 - schönes UI, aber das Backend muss geprüft werden

v0 (von Vercel) ist in dieser Gruppe der Beste für eine Sache: eine wirklich schöne React/Next.js-Oberfläche oder eine ganze Seitenansicht zu bauen. Es kann auch Datenbank, Login und Serverlogik generieren, seine Stärke ist aber die Oberfläche. Menschen bleiben hängen, weil sie einen wunderbar aussehenden Bildschirm haben und denken, es sei "nur noch anzuschließen" - in Wirklichkeit ist der schwierigste Teil (Sicherheit, Datenlogik, Fehlerbehandlung) noch ungeprüft.

Cursor - generiert, aber Sie müssen es verstehen

Cursor ist anders als die drei oben: ein Editor mit starker KI, gedacht für jemanden, der bereits Code lesen kann. Es schreibt viel und schnell. Aber wenn Sie nicht beurteilen können, was es geschrieben hat, lässt es Sie nur schneller etwas anhäufen, das Sie nicht verstehen. Das typische Szenario: Cursor generiert komplexe Logik, sie läuft fast, Sie bitten um eine kleine Korrektur, es schreibt mehr um als nötig, und plötzlich haben Sie 2.000 Zeilen, die Sie weder lesen noch sicher ändern können. Cursor ist wunderbar für Profis und gefährlich für jeden, der erwartet, dass es "alles von allein regelt".

Warum die KI "repariert" und gleich wieder zerlegt

Das ist eine der häufigsten Fragen, die ich höre: "Warum repariert es die eine Stelle und zerstört die andere?" Die Antwort ist Kontextverlust. Die KI sieht nicht Ihr ganzes Projekt auf einmal als zusammenhängendes System. Bei jeder Korrektur arbeitet sie mit einem begrenzten, sichtbaren Ausschnitt, "erinnert" sich nur an so viel, wie hineinpasst, und rät beim Rest. Während sie Stelle A repariert, ändert sie unbemerkt etwas, von dem Stelle B abhängt, über die sie gerade "nichts wusste".

Je größer das Projekt, desto schneller dreht sich dieser Kreis. Anfangs, solange wenige Dateien da sind, hält die KI noch alles "im Kopf" und wirkt großartig. Ab einer bestimmten Größe hat jede neue Reparatur eine wachsende Wahrscheinlichkeit, etwas anderes zu zerlegen - und plötzlich 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 hält 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, dass den bestehenden Code ein Mensch reparieren soll – die Person, die ihn erstellt hat, oder ein anderer Entwickler –, gibt es drei Dinge, mit denen die Einschätzung schnell und genau abläuft statt als teures Raten. Diese drei Dinge erledigen Sie selbst in einer halben Stunde.

Mit diesen drei Dingen kann ein Entwickler recht schnell sagen, ob punktuelle Reparaturen genügen oder ein Neuaufbau günstiger ist, und was es realistisch kostet. Ohne sie bleiben nur allgemeine Floskeln, die niemandem nützen. Wenn Sie sich bei mir für einen sauberen Neuaufbau entscheiden, brauche ich aus dieser Liste nur Punkt 3 und einen Link zum Prototyp: Den Code übernehme ich nicht, deshalb ist kein Zugriff aufs Repository nötig.

Retten oder neu aufbauen?

Die wichtigste Entscheidung – und Sie können sie selbst treffen. Entgegen der Erwartung ist die richtige Antwort nicht immer „wirf alles weg und schreib von null“. Die Logik ist ungefähr diese.

Situation	Was Sie wählen sollten
UI sauber, Probleme lokal (Zahlungen verbinden nicht, Deployment bricht, eine Integration)	Retten. Punktuelle Reparaturen – selbst oder mit der Person, die den Code erstellt hat. Oft der günstigste Weg.
Frontend gut, aber kein echtes Backend oder Datenmodell	Gemischt. Das Frontend behalten und darunter ein sauberes Backend bauen – das kann der Ersteller oder ein anderer Entwickler übernehmen.
Logik verstreut, jede Reparatur zerlegt anderes, niemand versteht die Struktur	Neu aufbauen. Die Oberfläche wird zur Spezifikation, der Code wird sauber von Grund auf geschrieben – genau das ist meine Arbeit.
Es ist ein internes Tool oder Demo, nicht für 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 für 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 nötig ist. Genauso offen sage ich, was ich selbst mache: ausschließlich den sauberen Neuaufbau von Grund auf – Retten und Flicken überlasse ich Ihnen oder der Person, die den Code erstellt hat. Mehr dazu, warum ein KI-Prototyp grundsätzlich noch kein Produkt ist und was "läuft auf meinem Bildschirm" von "läuft für echte Nutzer" trennt, lesen Sie im Artikel "Vibe Coding: Warum ein KI-Prototyp noch kein Produkt ist".

Welches Tool wofür 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: für welche Arbeit jedes Tool gedacht ist und wo seine Möglichkeiten enden.

Tool	Wofür es taugt	Wo die Grenze liegt
Lovable	Vollständiges Demo mit DB und Login, schnelles MVP zur Ideenprüfung	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	Schöne React/Next.js-Komponenten und Seiten, UI-Grundlage	Backend, DB und Login werden generiert, brauchen aber sorgfältige Prüfung
Cursor	Schnelleres Entwickeln für jemanden, der Code lesen und beurteilen kann	Ohne Verständnis häuft man schnell an, was man nicht mehr beherrscht

Realistische Preisrahmen

Offen gesagt, weil das niemand direkt ausspricht. Reparatur und Fertigstellung auf bestehendem Code biete ich nicht an, deshalb finden Sie hier meine Preise für einen sauberen Neuaufbau von Grund auf, bei dem Ihr Prototyp zur Spezifikation wird – als transparenter Festpreis, damit Sie vorab wissen, was geliefert wird und was es kostet:

• MVP / PWA mit Login, Daten und Deployment (iOS und Android aus einer Codebasis): ab 2.900 €
• Business-App mit Zahlungen und Integrationen, die gute Oberfläche als Spezifikation: ab 6.900 €
• Komplexe Plattform mit mehreren Nutzertypen und vielen Integrationen: ab 14.900 €

Der Preis hängt davon ab, was das Produkt können muss, nicht vom Zustand Ihres Codes – deshalb brauche ich für das Angebot nicht einmal den Code. Lokale Integrationen (PayPal, Klarna, SEPA, E-Rechnung, DATEV) sind im Umfang enthalten – meist ist das die Stufe Business-App ab 6.900 €. Wie viel die vermeintlich „kostenlose“ KI-Lösung am Ende wirklich kostet, beschreibe ich gesondert im Artikel „Die wahren Kosten einer kostenlosen KI-Website“.

Häufig gestellte Fragen

Können Sie mein Lovable-Projekt übernehmen?

Nein. Fremden oder KI-generierten Code übernehme, repariere oder erweitere ich nicht – auch dann nicht, wenn er nach GitHub synchronisiert ist. Stattdessen baue ich das Produkt sauber von Grund auf neu und nutze Ihren Lovable-Prototyp als Spezifikation und visuelles Vorbild: Bildschirme, Abläufe und die Logik, die Sie herausgearbeitet haben, gehen nicht verloren. Das ist für Sie die bessere Lösung: Sie zahlen nicht dafür, fremden Code zu entwirren, erben kein Durcheinander aus Supabase-Regeln und versteckten Lücken und bekommen ein sauberes Fundament, das jeder Entwickler warten kann. Wenn Sie auf dem bestehenden Code weiterbauen möchten, können Sie das selbst tun oder mit der Person, die ihn erstellt hat.

Ist Bolt-Code produktionsreif?

Das Frontend sieht oft gut genug aus, aber produktionsreif heißt mehr als ein hübsches 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 übernehme ich keinen Bolt-Code: Oberfläche und Abläufe des Projekts nutze ich als Spezifikation und baue das Produkt mit einem verlässlichen Backend und den nötigen Integrationen sauber von Grund auf, damit es mit echten Nutzern und echtem Geld läuft.

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 größer das Projekt, desto schneller beginnt dieser Kreislauf. Ein Mensch hält 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?

Das hängt davon ab, welchen Weg Sie wählen. Soll die Person, die den Code erstellt hat, oder ein anderer Entwickler den bestehenden Code reparieren, braucht sie drei Dinge: Zugang zum Code (ein GitHub-Repository oder das exportierte Projekt, keine Screenshots), Zugang zu den Diensten, die Sie nutzen (Supabase, Vercel, Zahlungs- oder E-Mail-Konten), und fünf bis zehn Sätze dazu, was die App tun soll und was konkret nicht funktioniert. Entscheiden Sie sich bei mir für einen sauberen Neuaufbau, brauche ich keinen Code – ein Link zum Prototyp oder Screenshots, dieselben fünf bis zehn Sätze dazu, was das Produkt können muss, und die Info, welche Konten Sie bereits haben, genügen.

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

Retten lohnt sich, wenn UI und Struktur sauber sind und die Probleme lokal bleiben: Zahlungen verbinden sich nicht, das Deployment bricht, eine Integration läuft nicht. Solche Reparaturen können Sie selbst übernehmen oder mit der Person, die den Code erstellt hat. Ein Neuaufbau ist günstiger, wenn die Logik verstreut ist, es kein echtes Backend oder Datenmodell gibt und jede Reparatur etwas anderes zerlegt. Ich arbeite ausschließlich auf diesem zweiten Weg: Fremden Code übernehme ich nicht, ich baue das Produkt von Grund auf und nutze Ihren Prototyp als Spezifikation.

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

Reparatur oder Fertigstellung auf bestehendem KI-Code biete ich nicht an – das können Sie selbst übernehmen oder mit der Person, die den Code erstellt hat. Meine Preise gelten für einen sauberen Neuaufbau von Grund auf nach Ihrem Prototyp: MVP / PWA (iOS und Android aus einer Codebasis) ab 2.900 €, Business-App mit Zahlungen und Integrationen ab 6.900 €, komplexe Plattform ab 14.900 €, jeweils als Festpreis. Der Preis hängt davon ab, was das Produkt können muss, nicht vom Zustand Ihres Codes – deshalb brauche ich für das Angebot nicht einmal den Code.

Kurz gefasst

Lovable, Bolt, v0 und Cursor sind großartige Tools für das, wofür sie gedacht sind: eine Idee schnell sichtbar zu machen. Sie gehen nicht kaputt, weil sie schlecht wären, 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. Entscheiden Sie, welcher Weg Ihrer ist: den bestehenden Code reparieren (selbst oder mit der Person, die ihn erstellt hat) oder sauber neu aufbauen. Wählen Sie den zweiten, beschreiben Sie, was Sie wollten, und Ihr Prototyp wird zur Spezifikation: Ihre gute Arbeit bleibt erhalten, und darunter baue ich von Grund auf das, was ein erneutes Einstürzen verhindert – damit es läuft und Geld verdient, nicht nur hübsch aussieht.