Ihr KI-gebautes MVP hält nicht: Audit, Refactoring oder Neuentwicklung?

Kurz gesagt (Stand: November 2026). Ein MVP, das mit Cursor, Lovable, Bolt, Replit oder von einem „Vibe-Coding“-Freelancer gebaut wurde, reicht meist, um die ersten Nutzer zu finden – und bricht dann an denselben Stellen: fehlende Zugriffskontrolle, Datenbankschlüssel im Browser, keine Tests, langsame Abfragen bei wachsenden Daten und Code, den niemand außerhalb des ursprünglichen Werkzeugs deployen kann. Beginnen Sie nicht mit einer Neuentwicklung. Beginnen Sie mit einem Audit von ein bis drei Wochen, das drei Fragen beantwortet: Sind Nutzerdaten gerade offen, lässt sich der Code ändern, ohne ihn zu beschädigen, und trägt er die nächsten sechs bis zwölf Monate Wachstum? Die meisten MVPs mit echten Nutzern werden danach schrittweise repariert und umgebaut; eine komplette Neuentwicklung lohnt sich nur, wenn das Produkt noch nicht validiert und der Code klein ist oder wenn sich das Kerndesign nicht absichern lässt.

Dieser Artikel richtet sich an Gründer und Product Owner, nicht nur an Entwickler. Er zeigt, was die Daten über KI-generierten Code sagen, welche Vorfälle die Probleme sichtbar gemacht haben, elf Warnsignale, die Sie selbst prüfen können, was ein Audit abdeckt, wie Sie zwischen Reparieren und Neubauen entscheiden und was Investoren und EU-Recht hinzufügen.

Warum KI-gebaute MVPs im Echtbetrieb brechen

KI-Werkzeuge sind gut darin, Code zu erzeugen, der läuft. Viel schwächer sind sie bei dem, was ein Produkt braucht, sobald echte Nutzer, echte Daten und echtes Geld dazukommen. Die Daten aus 2025–⁠2026 sind eindeutig:

• Sicherheit verbessert sich kaum. In den Tests von Veracode stieg die syntaktische Korrektheit von KI-Code auf über 95 %, aber nur etwa die Hälfte ist sicher – ein Wert, der sich seit 2023 kaum bewegt hat (Veracode, Frühjahr 2026).
• Mehr Code, mehr Befunde. In der Analyse von Apiiro erzeugten KI-gestützte Entwickler drei- bis viermal mehr Code und zehnmal mehr Sicherheitsbefunde; Pfade zur Rechteausweitung stiegen um 322 % (Apiiro via The Register, September 2025).
• Performance-Probleme. KI-geschriebene Pull Requests enthielten etwa achtmal häufiger übermäßige I/O – einer der Hauptgründe, warum eine App mit wachsenden Daten langsamer wird (CodeRabbit, Dezember 2025).
• Kopieren statt Gestalten. Laut GitClear sank der Anteil umgebauter Codezeilen von etwa 25 % (2021) auf unter 10 % (2024), und kopierter Code überholte erstmals verschobenen (GitClear).
• Geheimnisse gelangen nach außen. 2025 kamen auf öffentlichem GitHub 29 Millionen neue fest eincodierte Geheimnisse hinzu, 34 % mehr; Schlüssel für KI-Dienste stiegen um 81 % (GitGuardian, März 2026).
• Reviews halten nicht Schritt. 96 % der Entwickler vertrauen KI-Code nicht vollständig, aber nur 48 % prüfen ihn immer vor dem Commit (Sonar, Januar 2026). Schon frühere Forschung zeigte: Wer einen KI-Assistenten nutzt, schreibt unsichereren Code und hält ihn eher für sicher (Stanford, CCS 2023).
• Pakete, die es nicht gibt. In einer Studie der USENIX Security 2025 mit 16 Modellen existierten 19,7 % der empfohlenen Pakete nicht; Angreifer registrieren solche Namen („Slopsquatting“) (CSO Online).

Das heißt nicht, dass Sie keine KI zum Entwickeln nutzen sollten. Es heißt, dass schnell geschriebener Code die Prüfungen braucht, die ein Produkt braucht – und die bei einem vibe-codierten MVP oft übersprungen wurden.

Vorfälle, die das Problem sichtbar gemacht haben

Das Muster ist immer gleich: Die Voreinstellung, mit der ein Prototyp schnell funktioniert – offene Datenbank, Schlüssel im Frontend, ein Agent mit Produktionszugriff –, bleibt bestehen, wenn aus dem Prototyp das Produkt wird.

Elf Warnsignale, die Sie ohne Entwicklerwissen prüfen können

1. Datenbankschlüssel sind im Browser sichtbar. Öffnen Sie Ihre App, sehen Sie sich den Seitenquelltext oder das geladene JavaScript an und suchen Sie nach „supabase“, „firebase“ oder „apiKey“. Ein öffentlicher Schlüssel allein ist kein Problem, aber dann muss jede Tabelle durch Row-Level-Security geschützt sein. Fragen Sie nach.
2. Eine andere ID in der URL zeigt fremde Daten. Melden Sie sich als Testnutzer an, öffnen Sie eine Bestellung oder ein Profil und ändern Sie die Nummer in der Adresszeile.
3. Es gibt eine Datenbank für alles, oder der KI-Agent hat Zugriff auf die Produktion.
4. Es gibt keine automatischen Tests und keine Pipeline, die sie bei jeder Änderung ausführt. Fragen Sie Ihren Entwickler, welcher Test läuft, wenn er den Bezahlcode ändert.
5. Jede neue Funktion macht eine alte kaputt, und Schätzungen verschieben sich ständig.
6. API-Schlüssel liegen im Repository, in Chatverläufen oder in geteilten Dokumenten.
7. Die App wird mit wachsenden Daten langsamer, und niemand kann zeigen, warum, weil es kein Monitoring gibt.
8. Die Produktion läuft im kostenlosen Tarif. Der Free-Plan von Supabase pausiert Projekte zum Beispiel nach einer Woche Inaktivität und begrenzt die Datenbank auf 500 MB; tägliche Backups gibt es in den bezahlten Tarifen (Supabase-Preise).
9. Sie können nicht belegen, wem der Code gehört: Verträge mit Freelancern, Nutzungsbedingungen der KI-Werkzeuge, Konto des Repositorys.
10. Niemand kann die App außerhalb des Werkzeugs oder Laptops deployen, auf dem sie gebaut wurde.
11. Abhängigkeiten, die niemand kennt, oder Pakete, die erst vor Kurzem angelegt wurden.

Wenn Sie bei den ersten drei Punkten mit „ja“ oder „weiß ich nicht“ antworten, ist es dringend: Personenbezogene Daten könnten jetzt offen liegen. Vier oder mehr „ja“ insgesamt bedeuten: Audit vor der nächsten Funktion.

Was ein Audit abdeckt

Ein brauchbares Audit dauert je nach Größe ein bis drei Wochen und endet mit einem kurzen Bericht, mit dem Sie arbeiten können: was diese Woche behoben werden muss, was Wachstum blockiert und was warten kann. Es verbindet automatische Scans (Geheimnisse, Abhängigkeiten, statische Analyse) mit dem Review eines Entwicklers, der die Geschäftslogik liest: wer welche Daten sehen darf, was passiert, wenn ein Zahlungs-Webhook zweimal ankommt, welche Abfragen auf jeder Seite laufen.

Reparieren, umbauen oder neu bauen?

Zwei Fragen bestimmen den Weg: Hat das Produkt echte Nutzer und Umsatz, und lässt sich der Code ändern, ohne ihn zu beschädigen?

Vorsicht bei der großen Neuentwicklung. Joel Spolsky nannte das Neuschreiben von Grund auf „den schlimmsten strategischen Fehler“, den ein Softwareunternehmen machen kann; Netscape blieb durch seine Neuentwicklung rund drei Jahre ohne neues Release (Joel on Software). Eine Neuentwicklung wirft auch weg, was der unordentliche Code weiß: die Sonderfälle, die Ihre Nutzer schon gefunden haben.

Was es kostet. Unabhängige Daten gibt es nicht; veröffentlichte Preise sind Angaben von Anbietern und gehen weit auseinander: Audits ab einigen hundert Euro für kleine Apps (vibecoding.app) bis zu einem kostenlosen 48-Stunden-Review mit anschließender Festpreis-Rettung für 50.000–⁠150.000 $; typische Rettungen liegen bei 15.000–⁠50.000 $ (Red Leg, MetaCTO). Eine Agentur setzt eine Rettung mit rund 12 Wochen an und eine komplette Neuentwicklung mit dem Drei- bis Fünffachen ihrer Kosten (Azumo). Zur Orientierung bei Sätzen und Teammodellen siehe unseren Leitfaden zu den Kosten der MVP-Entwicklung 2026.

Worauf Investoren achten

Die technische Due Diligence in Seed- und Series-A-Runden prüft zunehmend KI-gebauten Code. Rechnen Sie mit Fragen zu:

• Eigentum: Verträge mit allen Auftragnehmern, Nutzungsbedingungen der KI-Werkzeuge, wo das Repository liegt.
• Sicherheit: Berechtigungen, Geheimnisse, Zahlungs-Webhooks, Abhängigkeiten.
• Architektur und Skalierbarkeit: was bei zehnmal so vielen Nutzern bricht.
• Dokumentation und Bus-Faktor: Kann jemand anderes als der ursprüngliche Entwickler den Code ändern und deployen?
• Compliance: DSGVO und bei KI-Funktionen der AI Act.
• Portabilität: Lässt sich die App außerhalb der Plattform bauen und betreiben, auf der sie entstanden ist?

Ein Auditbericht und ein Maßnahmenplan beantworten die meisten Fragen, bevor der Investor sie stellt (SCAND).

Was EU-Recht hinzufügt

• DSGVO. Liegen personenbezogene Daten offen, müssen Sie binnen 72 Stunden die Aufsichtsbehörde informieren und bei hohem Risiko die Betroffenen (Art. 33–⁠34); Bußgelder reichen bis 20 Mio. € oder 4 % des weltweiten Umsatzes (Art. 33 DSGVO). Eine offene Datenbank ist eine meldepflichtige Datenpanne, ob sie schon jemand genutzt hat oder nicht.
• Cyber Resilience Act. Wer eine App oder ein vernetztes Produkt in der EU verkauft, muss seit dem 11. September 2026 aktiv ausgenutzte Schwachstellen binnen 24 Stunden melden; ab Dezember 2027 braucht es eine SBOM und Sicherheitsupdates. Für eigenständiges SaaS gelten andere Regeln. Unser Leitfaden: Meldepflichten nach dem CRA.
• Barrierefreiheit. Verbraucher-Apps im Onlinehandel, Banking und ähnlichen Diensten müssen seit Juni 2025 barrierefrei sein; Kleinstunternehmen, die Dienstleistungen erbringen, sind ausgenommen.

KI weiter nutzen – mit Leitplanken

Die Lösung ist nicht, auf KI-Werkzeuge zu verzichten, sondern das hinzuzufügen, was die erste Version ausgelassen hat:

• automatische Tests für die Abläufe, die Geld bringen oder personenbezogene Daten berühren, bei jeder Änderung;
• ein Review durch einen Menschen für alles, was Zugriffsrechte, Zahlungen oder das Löschen von Daten betrifft;
• getrennte Entwicklungs-, Staging- und Produktionsumgebungen und kein KI-Agent mit Produktionszugriff;
• Geheimnis- und Abhängigkeitsscans in der Pipeline;
• Monitoring, das langsame Abfragen und Fehler zeigt, bevor Nutzer sie melden.

Mit diesen Leitplanken beschleunigen KI-Werkzeuge die nächste Version, statt das Problem zu vergrößern.

Wie wir helfen

SDH prüft und übernimmt MVPs, die mit KI-Werkzeugen oder von Freelancern gebaut wurden. Für Apps aus Lovable, Bolt oder Cursor beginnt Vibe Code Rescue mit einem Audit zum Festpreis und geht mit Sicherheitskorrekturen und dem Produktivbetrieb weiter. Ein Architektur-Review deckt Sicherheit, Skalierbarkeit und Codequalität ab und endet mit einem priorisierten Plan; mit CTO as a Service führen wir die Reparatur, den Umbau oder den Neubau und bereiten Sie auf die Due Diligence vor; und unser Team für MVP-Entwicklung baut Version eins sauber, wenn das der richtige Weg ist. Sprechen Sie uns an, bevor Sie sich für eine Neuentwicklung entscheiden.

FAQ

Sollte ich ein mit KI gebautes MVP neu schreiben?

Meist nicht. Hat das Produkt Nutzer und Umsatz, beheben Sie zuerst die Sicherheitsprobleme und bauen Sie hinter Tests schrittweise um. Eine komplette Neuentwicklung lohnt sich, wenn das Produkt noch nicht validiert und die Codebasis klein ist oder wenn sich das Kerndesign nicht absichern lässt.

Wie lange dauert ein Code-Audit eines MVP?

Ein bis drei Wochen, je nach Größe der Codebasis und Zahl der Integrationen. Es sollte mit einer priorisierten Liste enden: dringende Sicherheitskorrekturen, Wachstumsblocker und was warten kann.

Was sind die häufigsten Probleme in vibe-codierten Apps?

Fehlende Zugriffskontrolle auf der Datenbank, Schlüssel im Frontend, keine automatischen Tests, doppelter Code, langsame Abfragen bei wachsenden Daten, Geheimnisse im Repository und Apps, die sich nicht außerhalb des Werkzeugs deployen lassen, mit dem sie gebaut wurden.

Ist KI-generierter Code unsicherer?

Im Schnitt ja. Unabhängige Tests finden, dass nur etwa die Hälfte des KI-generierten Codes sicher ist, und KI-gestützte Teams erzeugen mehr Sicherheitsbefunde. Tests, menschliches Review sensibler Stellen und Scans in der Pipeline fangen die meisten dieser Probleme ab, bevor sie Nutzer erreichen.

Was passiert, wenn meine KI-gebaute App personenbezogene Daten preisgibt?

Nach der DSGVO müssen Sie binnen 72 Stunden die Aufsichtsbehörde informieren und bei hohem Risiko die Betroffenen. Bußgelder können 20 Mio. € oder 4 % des weltweiten Umsatzes erreichen.

Quellen

• Veracode, GenAI code security, Update Frühjahr 2026
• The Register on Apiiro's study, AI code assistants and security problems, September 2025
• CodeRabbit, State of AI vs human code generation, Dezember 2025
• GitClear, AI Copilot code quality 2025
• GitGuardian, State of Secrets Sprawl 2026
• Sonar, Verification gap in AI coding, Januar 2026
• Perry et al., Do users write more insecure code with AI assistants?, ACM CCS 2023
• Superblocks, The Lovable RLS breach (CVE-2025-48757)
• Escape, Vulnerabilities in apps built with vibe coding, Oktober 2025
• Wiz, Exposed Moltbook database, Februar 2026
• Martin Fowler, Strangler Fig Application
• Joel Spolsky, Things you should never do, part I

Categories

Über den Autor

Pavlo Yablonskyi

CTO & Co-Founder

Vollständiges Profil ansehen

CTO & Mitbegründer von Software Development Hub. Software-Ingenieur mit 20+ Jahren Erfahrung. Python/Django-Fan, Software-Architekt und IT-Teamleiter. Stets auf dem Laufenden mit technischen Trends. Ausgeprägte technische Fähigkeiten und vielfältiges Fachwissen in den Bereichen Software-Strukturdesign, Entwicklung, Teammanagement und Cybersicherheit.

Vollständiges Profil ansehen