Die Vibe-Code-Production-Readiness-Checkliste

Wenn du etwas mit Lovable, Cursor, Claude Code, Bolt, v0 oder Replit gebaut hast und echte User es gleich anfassen, lauf das zuerst durch. Es ist eine eigenständige Checkliste, sortiert danach, wie oft jeder Punkt zubeißt, die du selbst durcharbeiten kannst, bevor du jemanden anrufst. Eine Regel: ein Häkchen zählt nur, wenn der Server es erzwingt, nicht der Screen.

Das ist kein Seitenhieb auf Vibe-Coding. So fangen wir auch an. Es ist eine Karte der Arbeit, die nicht von selbst passiert, damit du die Lücken in KI-generiertem Code findest, bevor ein Incident es tut.

Woran erkenne ich, ob meine vibe-codete App produktionsreif ist?

Arbeite die zehn Checks unten der Reihe nach durch. Jeder ist eine Frage mit einer Pass-Bedingung. Wenn du nicht mit Beweis ja sagen kannst, ist er nicht erledigt. Die ersten drei werden zu Incidents, also überspring nicht.

Die Checkliste

1. Autorisierung auf dem Server. Prüft der Server bei jedem Endpoint und jedem Datenlesen, wer fragt und ob er darf? Eine Frontend-Prüfung zählt nicht. Pass: ändere eine User-ID in einem Request und bestätige, dass du eine Ablehnung bekommst, nicht die Daten von jemand anderem.
2. Tenant- und Row-Isolation. Wenn die App Multi-Tenant ist, kann ein Account physisch die Records eines anderen erreichen? Pass: Isolation wird auf Datenbank- oder Query-Ebene erzwungen, nicht in App-Logik, die du auf jedem Endpoint hinzufügen musst.
3. Keine Secrets auf dem Client. Sind API-Keys, Datenbank-URLs oder Tokens im Client-Bundle oder der Repo-Historie? Pass: ein Scan von Bundle und Git-Historie ist sauber, und alles je Exponierte wurde rotiert.
4. Input-Validierung an jedem Eingangspunkt. Lehnt jedes Formular und jeder Endpoint malformierten, übergroßen und feindseligen Input sauber ab? Pass: Müll daraufwerfen liefert einen sauberen Fehler, keinen Crash und kein stilles Schlucken.
5. Fehlerpfade abgedeckt. Wenn ein externer Call timed out, fehlschlägt oder leer zurückkommt, degradiert die App anmutig? Pass: zwinge jeden externen Call zum Fehlschlag und bestätige, dass der Screen nicht mit einer unbehandelten Exception leer wird.
6. Queries, die skalieren. Gibt es Datenbank-Calls in einem Render geloopt oder ganze Tabellen geladen, um Zeilen zu zählen? Pass: unter realistischen Datenmengen profiliert, mit N+1-Queries und unbegrenzten Reads entfernt.
7. Concurrency und Idempotenz. Erzeugen zwei Klicks zwei Bestellungen, oder bestehen zwei parallele Requests beide eine Saldoprüfung? Pass: alles, was Geld oder State schreibt, ist idempotent und behandelt doppelte und parallele Requests.
8. Eigener Daten-Layer mit Backups. Liegen die Daten in einer managed Datenbank, die du kontrollierst, mit Migrationen unter Versionskontrolle und automatisierten Backups? Pass: du hast mindestens einmal ein Backup wiederhergestellt. Ein Backup, das du nie wiederhergestellt hast, ist eine Hoffnung.
9. Dependencies und Lizenzen geprüft. Trägt ein Package eine bekannte Vulnerability oder eine Lizenz, die deine kommerzielle Nutzung verbietet? Pass: ein Dependency- und Lizenz-Scan ist sauber oder bewusst gewaivt.
10. Eine Regressions-Suite existiert. Gibt es Tests, damit die nächste Änderung, KI-geschrieben oder nicht, nicht still brechen kann, was funktioniert? Pass: eine Suite läuft bei jeder Änderung. Siehe testgetriebene Entwicklung, warum das mehr zählt, nicht weniger, wenn ein Modell den Code schreibt.

"Ein Modell schreibt den Code, nach dem du gefragt hast, und nichts, was du vergessen hast zu fragen. Diese Checkliste ist alles, was du vergessen hast zu fragen, in der Reihenfolge, in der es weh tut."

Welche Punkte blockieren einen Launch?

Nicht alle zehn sind gleich. Sortiere deine Fehlschläge in drei Buckets, damit du das Richtige zuerst behebst, statt an der ganzen Liste zu erstarren.

• Blocker. Alles, was Kundendaten exponiert, Geld verliert oder State korrumpiert: Punkte 1, 2, 3 und 7. Die warten nicht. Der Launch wartet auf sie.
• High. Echtes Risiko, das noch nicht zugebissen hat: Punkte 4, 5, 6 und eine bekannte CVE unter 9. Beheben, bevor du hineinwächst.
• Cleanup. Echt, aber überlebbar: dünne Validierung auf Low-Stakes-Inputs, fehlende Tests auf stabilem Code, der Rest von 8 und 10. Wert es zu tun, sicher zu planen.

Der Sinn der Aufteilung ist Ehrlichkeit über Dringlichkeit. Verkleide keinen Cleanup-Punkt als Blocker, und lass keinen echten Blocker in einer langen Liste verstecken.

Kann ich die KI nicht einfach bitten, das zu beheben?

Teilweise. Ein Modell fügt gerne eine Validierungsprüfung hinzu oder wickelt einen Call in Error-Handling, sobald du auf die Stelle zeigst. Was es nicht kann, ist entscheiden, wo es schauen soll. Es hat kein Modell deiner Technical Debt und keinen Instinkt für den Edge Case, den ein echter User an Tag zwei trifft. Die Lücken finden ist menschliche Arbeit. Sie schließen ist zunehmend geteilte Arbeit. Genau so machen wir es.

Was kostet es, die ganze Liste abzuarbeiten?

Das hängt davon ab, was fehlschlägt und wie viel Geld oder sensible Daten das Produkt berührt. Wir brechen die typischen Aufwandsspannen und wo die Zeit tatsächlich hingeht in was es kostet, eine vibe-codete App produktionsreif zu machen auf. Die Kurzfassung: das Audit, das diese Checkliste durchläuft, ist der günstige Teil, und es sagt dir die Größe des Hardenings, bevor du dich darauf festlegst. Das ist das Front-End unseres Software-Quality-Assurance-Service.