# Vom Prototyp in Produktion: was ein Vibe-Coding-Entwurf noch braucht *Quelle: https://www.provimedia.de/blog/vibe-coding-prototyp-in-produktion · Stand: 2026-07-27* > Der Prototyp läuft, alle sind begeistert, und plötzlich soll er live gehen. Die zwölf Punkte, die zwischen „funktioniert bei mir" und „trägt echte Nutzer" liegen. **Ein Prototyp wird nicht dadurch produktionsreif, dass er funktioniert. Er wird es, wenn geklärt ist, was bei falschen Eingaben, gleichzeitigen Zugriffen, fehlenden Berechtigungen und im Fehlerfall passiert — und wenn jemand ihn betreiben, ändern und im Notfall zurückrollen kann. Das sind zwölf prüfbare Punkte, keine Frage der Codequalität allein.** ## Warum scheitert der Sprung vom Prototyp in den Betrieb so oft? **Weil ein Prototyp eine andere Frage beantwortet als ein Produkt.** Der Prototyp beantwortet: Geht das überhaupt? Das Produkt beantwortet: Hält das, wenn hundert Leute es gleichzeitig falsch bedienen, das Netz wegbricht und in achtzehn Monaten jemand anderes eine Änderung einbauen soll? Der Prototyp hat auf all diese Fragen keine Antwort — nicht weil er schlecht gebaut wäre, sondern weil sie nicht gestellt wurden. Die Gefahr entsteht durch die Überzeugungskraft des Ergebnisses: Etwas, das im Termin einwandfrei vorgeführt wurde, wirkt fertiger, als es ist. ## Welche zwölf Punkte muss ich vor dem Livegang klären? ### Datenschicht - **Datenmodell nachziehen.** Prototypen speichern oft alles flach und ohne Beziehungen. Was in einer Demo funktioniert, verhindert später jede Auswertung und jede Änderung. - **Migrationen umkehrbar machen.** Jede Schema-Änderung braucht einen Rückweg. Ein generierter Migrationsschritt ohne Gegenstück ist eine Einbahnstraße. - **Gleichzeitigkeit prüfen.** Was passiert, wenn zwei Nutzer denselben Datensatz gleichzeitig ändern? Im Prototyp nie aufgetreten, im Betrieb am ersten Tag. ### Korrektheit - **Fehlerfälle implementieren.** Die OWASP Top 10:2025 führen falsch behandelte Ausnahmen erstmals als eigene Kategorie (A10). Generierter Code implementiert zuverlässig den Normalfall und verschluckt den Rest. - **Eingaben validieren.** Serverseitig, nicht nur im Formular. Prototypen prüfen im Browser, weil das für die Vorführung reicht. - **Tests für das Verhalten schreiben, das geschützt werden soll.** Siehe [Testabdeckung bei KI-Code](/blog/testabdeckung-ki-code). ### Zugriff - **Berechtigungen explizit machen.** Für jeden Endpunkt eine beantwortete Frage: Wer darf das aufrufen, und was passiert, wenn jemand anders es versucht? Fehlerhafte Zugriffskontrolle steht in den OWASP Top 10:2025 unverändert auf Platz eins. - **Geheimnisse aus dem Quelltext holen.** Prototypen tragen Zugangsdaten im Code, weil es schneller ging. ### Betrieb - **Abhängigkeiten inventarisieren.** Welche Pakete sind dabei, wer pflegt sie, welche Lizenz? Lieferketten-Fehler sind seit 2025 eigene OWASP-Kategorie (A03). - **Protokollierung und Alarmierung.** Wenn niemand merkt, dass es kaputt ist, ist es länger kaputt. - **Rückrollweg.** Ein Deploy ohne Rückweg ist ein Versprechen, keinen Fehler zu machen. - **Datenschutz klären.** Welche personenbezogenen Daten fallen an, auf welcher Rechtsgrundlage, wie lange gespeichert, wer verarbeitet sie im Auftrag? ## Lohnt es sich, den Prototyp neu zu schreiben? **Häufiger, als es sich anfühlt — aber die Entscheidung sollte an einem Kriterium hängen, nicht am Bauchgefühl.** Das Kriterium lautet: Versteht jemand im Team die Struktur gut genug, um sie gezielt zu ändern? - **Ja:** Dann ist Nachziehen der günstigere Weg. Die zwölf Punkte oben abarbeiten, in dieser Reihenfolge. - **Nein:** Dann bezahlen Sie den Neubau ohnehin — entweder jetzt bewusst oder später verteilt über jede einzelne Änderung. Der Prototyp bleibt als Spezifikation wertvoll: Er zeigt exakt, was das Produkt tun soll. Diesen zweiten Fall unterschätzt die Diskussion um KI-Werkzeuge regelmäßig. Die Daten von GitClear zeigen, dass echtes Umbauen von Code stark rückläufig ist — der Anteil verschobenen Codes fiel von 21 Prozent im Jahr 2022 auf 3,8 Prozent im Jahr 2026. Wo nicht mehr umgebaut wird, wächst stattdessen ein Bestand, den irgendwann niemand mehr anfassen will. ## Wie plane ich den Übergang realistisch? **Rechnen Sie den Übergang als eigenes Vorhaben, nicht als Restaufwand.** Ein Prototyp, der in zwei Tagen entstand, braucht für die zwölf Punkte typischerweise ein Vielfaches dieser Zeit — und das ist kein Scheitern, sondern die normale Verteilung: Die Demo ist der kleine Teil. Verlässlicher als jede pauschale Schätzung ist ein anderes Vorgehen: die zwölf Punkte durchgehen, jeden einzeln bewerten (erledigt, offen, unklar) und nur die offenen schätzen. Das dauert eine Stunde und ersetzt eine Diskussion, die sonst durch das ganze Projekt läuft. Wenn Sie diesen Weg als Dienstleistung begleitet haben möchten, ist unsere [SaaS-Entwicklung](/leistungen/saas-entwicklung) genau dafür da. ## Häufige Fragen zum Produktivgang ### Kann ich einen mit Lovable oder Bolt gebauten Prototyp direkt live stellen? Technisch ja, verantwortbar nur nach denselben zwölf Punkten. Der Ursprung des Codes ändert die Anforderungen nicht — sobald echte Nutzer und echte Daten beteiligt sind, gelten sie unabhängig davon, wer oder was den Code geschrieben hat. ### Reicht es, wenn die Tests grün sind? Nein. Tests prüfen, was jemand zu prüfen wusste. Bei einem Prototyp ist genau das die Lücke: Die Fehlerfälle, die niemand bedacht hat, sind auch nicht getestet. ### Was ist der häufigste übersehene Punkt? Berechtigungen. Fachlogik wird zuverlässig implementiert, weil sie im Auftrag steht. Die Frage „darf dieser Nutzer das?" steht selten im Auftrag und fehlt entsprechend oft. ### Sollte ich den Prototyp vorher von jemandem prüfen lassen? Ein externes Code-Audit vor dem Produktivgang ist deutlich günstiger als nach einem Vorfall. Was so ein Audit prüft, steht in unserer [Code-Audit-Checkliste](/blog/code-audit-checkliste). > **Die zwölf Punkte sind schnell abgehakt und schwer wirklich abgearbeitet.** [Code Guardian](/code-guardian) hängt die riskanten davon — Migration, Deploy, neue Abhängigkeit — an Gates, die vor dem jeweiligen Schritt stehen und eine Freigabe verlangen, statt darauf zu vertrauen, dass die Liste im richtigen Moment erinnert wird. ## Quellen - OWASP Top 10:2025 (Kategorien A01 Broken Access Control, A03 Software Supply Chain Failures, A10 Mishandling of Exceptional Conditions), finale Fassung Januar 2026. - GitClear, *The Maintainability Gap: 2026 AI Code Quality Research*. *Stand: 27. Juli 2026. Allgemeine fachliche Einordnung; der konkrete Umfang hängt vom Einzelfall ab und ersetzt keine individuelle Prüfung.* --- Kanonische Version: