Der KI-Prototyp-Eisberg: Ist Ihr MVP produktionsreif?
Ein Prompt wird zu einem Bildschirm. Ein paar weitere werden zu einem Ablauf. Am Ende des Nachmittags ist die Anwendung klickbar, vorführbar, und jemand sagt den Satz: Die Software ist fast fertig.
Was existiert, ist ein Prototyp. Das ist keine Kritik — Prototypen validieren Ideen und kosten einen Bruchteil dessen, was sie früher gekostet haben. Problematisch wird es, wenn die Demo mit dem System verwechselt wird. KI hat verändert, wie schnell Software umgesetzt wird. Sie hat das Engineering darunter nicht abgeschafft.
Die Demo ist der erste von fünf Schritten
Ein Prototyp beantwortet vier Fragen. Lässt sich die Idee in Software abbilden? Ergibt der Ablauf Sinn? Verstehen Nutzer den Bildschirm? Bringt die Kernfunktion Nutzen?
Für ein lokales Werkzeug, das das Problem einer einzigen Person löst, reicht das. Sobald Software zu einem Dienst wird — Kundenkonten, private Daten, Zahlungen, Geschäftsabläufe — ist “funktioniert es?” nicht mehr die Frage. Funktioniert es unter Last, scheitert es kontrolliert, erholt es sich von Datenverlust, erreicht ein Nutzer wirklich nur seine eigenen Datensätze, lässt sich ein fehlerhaftes Release zurückrollen, und wer ist verantwortlich, wenn es bricht. Eine Demo beantwortet nichts davon.
1. Scope: Prototypen bauen nur den Idealpfad
Ein Prototyp zeigt den Idealpfad: Daten eingeben, klicken, Ergebnis erhalten. Der Produktivbetrieb muss zusätzlich beantworten, was passiert, wenn diese Daten fehlen, ungültig sind, doppelt ankommen, verzögert eintreffen oder in falscher Reihenfolge übermittelt werden.
Dieselbe Lücke zeigt sich bei den Nutzerreisen. Registrierung, Anmeldung, Onboarding und normale Nutzung sind fast immer vorhanden. Fehlgeschlagene Aktionen, Kontowiederherstellung, Kündigung und administrative Eingriffe fast nie.
Was diese Phase liefert, ist ein geschriebener Scope mit einer Grenze darum. Wir liefern ihn im ersten Milestone, bevor eine Zeile produktiver Code existiert, weil ein Dokument das billigste Artefakt ist, dem man widersprechen kann.
2. Architektur: Die Zugriffsregel gehört in die Datenbank
Eine Funktion kann auf dem Bildschirm vollkommen korrekt aussehen und trotzdem die Datensätze eines Kunden einem anderen aushändigen, weil die Regel darunter unvollständig ist.
CVE-2025-48757, veröffentlicht am 29. Mai 2025 mit einem CVSS-Wert von 9,3, beschreibt eine “unzureichende Row-Level-Security-Richtlinie in Lovable bis 2025-04-15”, die es “entfernten, nicht authentifizierten Angreifern erlaubt, beliebige Datenbanktabellen generierter Seiten zu lesen oder zu beschreiben”. Der meldende Sicherheitsforscher fand 303 offene Endpunkte in 170 generierten Projekten — E-Mail-Adressen, Telefonnummern, Zahlungsdaten, API-Schlüssel.
In den KI-gebauten Codebasen, die wir bewerten, ist das unser erster Blick, und der Fehler hat immer dieselbe Gestalt: Die Autorisierung existiert in der Oberfläche und sonst nirgends. Die Schaltfläche ist ausgeblendet, die Route ist geschützt, die Abfrage im Frontend filtert nach Nutzer-ID — und die Tabelle darunter antwortet jedem, der sie direkt fragt.
Verschlüsselung gehört in dieselbe Entscheidung, nicht in eine spätere Härtungsrunde. Wer nach Supabase field encryption gesucht und einen Schalter pro Spalte erwartet hat: Den gibt es nicht mehr. Die auf pgsodium basierende Transparent Column Encryption wird nicht mehr empfohlen, wurde aus dem Table Editor des Dashboards entfernt und läuft auf eine Abkündigung zu. Vault bleibt bestehen, aber Vault ist für Geheimnisse gedacht — API-Schlüssel, Webhook-Token — nicht für die Spalten Ihrer Nutzer. Verschlüsselung auf Feldebene ist damit eine Entscheidung der Anwendung, und verschlüsselte Spalten verlieren das normale Abfragen: kein LIKE, kein Index, keine Sortierung. Günstig, wenn es von Anfang an mitgedacht wird, schmerzhaft im Nachrüsten.
3. Umsetzung: Der Code kommt schnell, zwei Dinge fehlen
In der Umsetzung ist KI wirklich gut: Anwendungscode, wiederkehrende Komponenten, klar definierte Geschäftslogik, Migrationen, erste Tests, Dokumentation, Refactoring, Infrastrukturkonfiguration. Der Engpass hat sich vom Tippen weg und auf die Definition des richtigen Systems verschoben.
Schnell ist nicht dasselbe wie korrekt. Zwei Auslassungen finden wir in fast jeder Codebasis, die wir später bewerten:
- Keine automatisierten Tests. “Hat das etwas kaputt gemacht?” wird in der Produktion beantwortet, und jede Änderung wird zu einem Glücksspiel, das der Gründer irgendwann nicht mehr eingeht.
- Geheimnisse im Repository oder im Client-Bundle. Ein
service_role-Schlüssel in einem Frontend-Build umgeht konstruktionsbedingt jede darüberliegende Zugriffsregel.
Wir verstehen KI-gestützte Entwicklung als ingenieurgeführte Umsetzung: Senior Engineers definieren das System, leiten die Umsetzung, prüfen das Ergebnis und bleiben dafür verantwortlich. Das Modell schreibt den Großteil des Codes. Es trägt keinerlei Verantwortung.
4. Betrieb: Das Deployment ist der Anfang der Arbeit
Fehler müssen automatisch erfasst werden, sonst laufen sie tagelang, bevor jemand sie bemerkt. Zu wissen, dass der Server läuft, ist nicht dasselbe wie zu wissen, dass die Anwendung funktioniert.
Hosting-Grenzen gehören dazu. Der kostenlose Supabase-Tarif bietet 500 MB Datenbank, 1 GB Dateispeicher, 5 GB ausgehenden Datenverkehr und 50.000 monatlich aktive Nutzer bei zwei aktiven Projekten — und pausiert ein Projekt nach einer Woche ohne Aktivität; Pro beginnt bei 25 US-Dollar im Monat mit 8 GB Speicher inklusive, danach 0,125 US-Dollar je GB. Lesen Sie die Pausenregel als das, was sie aussagt: Der kostenlose Tarif ist ein Prototyp-Tarif. Ein pausiertes Projekt ist ein Ausfall, und der Erste, der es bemerkt, wird ein Kunde sein. Ein Gigabyte Dateispeicher sind ein paar hundert Handyfotos.
Backups sind keine Wiederherstellung. Ein Backup, das nie zurückgespielt wurde, ist eine Annahme, und der Moment, in dem Sie es brauchen, ist ein schlechter Zeitpunkt für den Test. Machen Sie die Übung, bevor Sie sie brauchen: Spielen Sie ein Backup in ein leeres Projekt zurück, stoppen Sie die Zeit, und sehen Sie nach, was fehlt. Diese Zahl ist Ihre tatsächliche Wiederherstellungslage.
Dieselbe Disziplin gilt für Änderungen. In KI-gebauten Projekten finden wir das Gegenteil — Schemaänderungen direkt gegen die Produktion aus einem Chat-Prompt, keine umkehrbare Migration, Entwicklung und Produktion driften still auseinander, bis niemand mehr sagen kann, welche der beiden richtig ist.
Die meisten Plattformen brauchen außerdem interne Werkzeuge, die kein Kunde je sieht: ein Konto einsehen, einen missbräuchlichen Nutzer sperren, einen fehlgeschlagenen Job erneut starten, ein Audit-Log lesen. Ohne sie wird jeder Vorfall zu einer manuellen Datenbankoperation — langsam, riskant und im Nachhinein nicht prüfbar.
Wie viel davon brauchen Sie wirklich?
Nicht jede Anwendung braucht dasselbe Maß an Engineering. Ein lokales Hilfsprogramm ist keine Plattform mit Kundendaten. Die Messlatte steigt mit Geld, Gesundheit, Sicherheit, privaten Daten, geschäftskritischen Abläufen und rechtlichen Pflichten.
Nehmen Sie eine Zahlung. Sie darf nicht nur auf dem Bildschirm erfolgreich aussehen. Was passiert, wenn die Zahlung durchgeht, die Bestätigungsanfrage aber in eine Zeitüberschreitung läuft? Wenn der Nutzer zweimal klickt? Wenn der Anbieter dasselbe Webhook-Ereignis zweimal sendet? Wiederholungen, Idempotenz und Abstimmung sind Fragen des Produktions-Engineerings, und keine noch so gute Oberfläche löst sie.
Bei medizinischer und sicherheitskritischer Software steigt die Messlatte weiter. “Die KI hat es erfolgreich generiert” ist kein Nachweismodell.
KI ist nicht das Problem
Die Werkzeuge sind gut und ehrlich darin, gut zu sein. Lovable erzeugt ein React-Frontend, ein vernünftiges Supabase-Schema, funktionierende Anmeldung und ein laufendes Deployment schneller als jedes menschliche Team, und der Code ist lesbar genug, dass Entwickler ihn übernehmen können. Was es nicht kann, ist die Grenze zwischen “funktioniert, wenn ich es benutze” und “sicher, wenn ein Fremder es benutzt” zu verantworten. Die Antwort auf das oben genannte CVE war ein Sicherheitsscanner in Version 2.0, der meldet, ob Row-Level Security vorhanden ist, nicht ob sie korrekt ist — eine aktivierte Richtlinie, die nie greift, besteht den Scan. Lovable bestreitet das CVE zudem mit der Begründung, Kunden seien selbst dafür verantwortlich, ihre Anwendungsdaten zu schützen. Das lohnt ein zweites Lesen, denn es beschreibt zutreffend, wo die Verantwortung liegt.
Der Irrtum war nie, dass KI Software bauen kann. Sie kann es. Der Irrtum ist, dass ein funktionierender Prototyp zu produktionsreifer Software wird, weil die Umsetzung schnell war. KI hat die Kosten der Codeerzeugung gesenkt. Sie hat nicht die Kosten gesenkt, die Domäne zu verstehen, die Architektur zu entwerfen, die Daten zu schützen, das Verhalten zu verifizieren, die Infrastruktur zu betreiben und Verantwortung zu übernehmen.
Wenn Sie den Prototyp bereits haben und eine ehrliche Antwort auf den Rest wollen: Unser Vibe-Code-Rescue-Assessment ist kostenlos und endet in einem schriftlichen Urteil, dem Sie widersprechen können.
