Von Vibe Code zu Enterprise-Software: Die Production-Readiness-Checkliste
Die Erwartungslücke im Enterprise-Geschäft
Du hast dein Produkt mit KI-gestützten Tools ausgeliefert. Die Demo lief hervorragend. Erste Kunden nutzen es. Dann zeigt ein mittelständisches Unternehmen echte Kaufabsicht, und dessen Einkaufsteam schickt einen Sicherheitsfragebogen. Der Fragebogen fragt nach Audit-Logs, SSO-Unterstützung, Penetrationstest-Ergebnissen, SLA-Garantien, Datenaufbewahrungsrichtlinien und Disaster-Recovery-Prozeduren.
Die meisten vibe-codierten Produkte können die Hälfte dieser Fragen nicht beantworten.
Das ist die Erwartungslücke im Enterprise-Geschäft. KI-Tools sind exzellent darin, Code zu generieren, der die funktionalen Anforderungen vor ihnen erfüllt. Sie sind nicht dafür gebaut, Software zu produzieren, die die nicht-funktionalen Anforderungen des Enterprise-Einkaufs erfüllt: Audit-Trails, Compliance-Nachweise, betriebliche Stabilität und die Art von Dokumentation, für die ein CTO seinen Ruf einsetzen kann.
Diese Lücke zu schließen erfordert keinen Neuanfang. Es erfordert eine systematische Bewertung dessen, was fehlt, und einen disziplinierten Behebungsaufwand. Diese Production-Readiness-Checkliste deckt die 30 Bereiche ab, in denen vibe-codierte Anwendungen bei der Bewertung durch Enterprise-Kunden am konsistentesten durchfallen.
Warum Enterprise-Kunden anders prüfen
Enterprise-Einkäufer haben schlechte Erfahrungen gemacht. Sie haben Software eingeführt, die unter Spitzenlast versagte, in einem nicht behebbaren Vorfall Daten verlor oder eine Sicherheitslücke einführte. Ihr Einkaufsprozess spiegelt diese schmerzhaften Lektionen wider.
Der Enterprise-Einkauf bewertet Software entlang mehrerer Dimensionen, die Vibe Coding völlig ignoriert: betriebliche Stabilität (versagt das hier kontrolliert?), Sicherheitslage (können wir dem unsere Kundendaten anvertrauen?), Wartbarkeit (kann unser Team die Verantwortung übernehmen, wenn der Anbieter verschwindet?), Compliance-Fähigkeit (kann das die Audit-Nachweise produzieren, die unsere Prüfer verlangen?) und Integrationsrobustheit (verhält sich das vorhersehbar, wenn es mit unseren anderen Systemen verbunden wird?).
Die beim Vibe Coding verwendeten KI-Tools generieren Code, der das funktionale Briefing erfüllt. Sie modellieren keine Angreifer, keine betrieblichen Fehlerszenarien und nicht die Bedürfnisse einer künftigen Entwicklerin, die die Codebasis nie gesehen hat.
Die Production-Readiness-Checkliste
Sicherheit
1. Authentifizierung härten. JWT-Tokens sollten kurze Ablauffenster haben (15 Minuten für Access-Tokens, 7 Tage für Refresh-Tokens mit Rotation). Passwort-Reset-Tokens müssen ablaufen. Login-Endpunkte brauchen Rate-Limiting und Konto-Sperre nach fehlgeschlagenen Versuchen.
2. Autorisierung an jedem Endpunkt durchsetzen. Die Zugriffskontrolllogik muss auf dem Server liegen, nicht im Client. Teste jeden Endpunkt, indem du Anfragen mit Tokens unterschiedlicher Nutzer stellst und sicherstellst, dass kein nutzerübergreifender Datenzugriff möglich ist.
3. Eingabevalidierung und Ausgabe-Escaping. Jedes vom Nutzer gelieferte Datum, das ins System gelangt, sollte gegen ein explizites Schema validiert werden. Jeder nutzergenerierte Inhalt, der ins Frontend gerendert wird, sollte escaped werden. SQL- und NoSQL-Abfragen müssen ausschließlich parametrisierte Eingaben verwenden.
4. Secrets-Management. Keine Zugangsdaten, API-Schlüssel oder Tokens im Quellcode oder in der Git-Historie. Verwende Umgebungsvariablen mit einem Secrets-Manager (AWS Secrets Manager, HashiCorp Vault oder ein cloud-natives Äquivalent). Rotiere jedes Secret, das jemals committet wurde, auch nur kurz.
5. Dependency-Audit. Führe npm audit und composer audit (oder Äquivalente) aus und behebe alle kritischen und hochgradigen Schwachstellen. Implementiere automatisiertes Dependency-Scanning in deiner CI-Pipeline, damit neue Schwachstellen erkannt werden, bevor sie die Produktion erreichen.
6. Security-Header. Konfiguriere Content Security Policy, Strict-Transport-Security, X-Content-Type-Options und X-Frame-Options. Beschränke CORS auf bekannte, vertrauenswürdige Origins. Diese Header fehlen in vibe-codierten Anwendungen oft, weil sie auf der Infrastruktur-Ebene und nicht auf der Anwendungs-Ebene liegen.
7. Datenverschlüsselung im Ruhezustand und bei der Übertragung. TLS überall für Daten bei der Übertragung. Sensible Datenfelder (personenbezogene Daten, Zahlungsinformationen, Gesundheitsdaten) auf Datenbank-Spaltenebene im Ruhezustand verschlüsselt, wenn die Compliance es verlangt.
Observability
8. Strukturiertes Logging. Anwendungs-Logs sollten maschinenlesbares JSON mit konsistenten Feldern sein: Zeitstempel, Log-Level, Correlation-ID, Nutzer-ID (wo zutreffend) und Ereignisbeschreibung. Vermeide unstrukturiertes printf-artiges Logging, das nicht durchsucht oder mit Alerts versehen werden kann.
9. Error-Tracking. Integriere einen Error-Tracking-Dienst (Sentry, Bugsnag oder Äquivalent), damit jede nicht behandelte Ausnahme erfasst, gruppiert und an das Engineering-Team weitergeleitet wird. Ohne das sind Produktionsfehler unsichtbar, bis Nutzer sie melden.
10. Request-Tracing. Implementiere verteiltes Tracing mit einer Correlation-ID, die einer Anfrage durch jeden Dienst, jede Queue und jeden Background-Job folgt. Wenn eine Nutzerin meldet, dass "etwas schiefgelaufen" ist, musst du genau nachvollziehen können, was passiert ist.
11. Application Performance Monitoring. Verfolge Request-Latenz, Datenbank-Abfragezeiten, Cache-Trefferraten und Background-Job-Durchsatz. Setze Schwellenwerte und alarmiere, bevor Nutzer die Verschlechterung bemerken. Diese Instrumentierung ist in vibe-codierten Anwendungen fast nie vorhanden.
12. Infrastruktur-Metriken. CPU-, Speicher-, Festplatten- und Netzwerkmetriken mit Alerting. Das ist Grundausstattung, doch vibe-codierte Anwendungen werden oft ohne jedes betriebliche Dashboard ausgeliefert.
13. Health-Check-Endpunkte. Stelle /health- und /ready-Endpunkte bereit, die Datenbankkonnektivität, Cache-Verfügbarkeit und externe Dienstabhängigkeiten prüfen. Diese Endpunkte sind für Load-Balancer, Container-Orchestrierung und Monitoring-Systeme erforderlich.
Fehlerbehandlung und Zuverlässigkeit
14. Graceful Degradation. Wenn eine nicht-kritische externe Abhängigkeit ausfällt (ein Analytics-Dienst, ein Benachrichtigungsanbieter, ein Anreicherungsschritt im Hintergrund), sollte die Anwendung ihre Kernfunktion weiter bedienen. Kritische Pfade dürfen nicht von nicht-kritischen Diensten abhängen.
15. Aussagekräftige Fehlermeldungen für Nutzer. Produktions-Fehlerantworten sollten informativ sein, ohne Systeminterna preiszugeben. Keine Stacktraces, keine SQL-Fehlermeldungen, keine internen IDs in nutzergerichteten Antworten. "Wir konnten deine Zahlung nicht verarbeiten, bitte versuche es erneut oder kontaktiere den Support" ist korrekt. Eine Doctrine-Ausnahme mit Query-Dump ist es nicht.
16. Retry-Logik für externe Aufrufe. HTTP-Anfragen an externe Dienste sollten exponentielles Backoff mit Jitter implementieren. Background-Jobs sollten konfigurierbare Retry-Limits mit Dead-Letter-Queuing für Jobs haben, die ihre Retries aufbrauchen.
17. Timeout-Konfiguration. Jeder externe HTTP-Aufruf, jede Datenbankabfrage und jeder Background-Job sollte ein explizites Timeout haben. Nicht konfigurierte Timeouts bedeuten, dass ein langsamer Upstream-Dienst Verbindungen unbegrenzt offen halten kann, bis dein Connection-Pool erschöpft ist und die Anwendung lahmlegt.
18. Transaktionsintegrität. Operationen, die mehrere Datensätze verändern, sollten in Datenbanktransaktionen gekapselt sein, die bei einem Fehler zurückrollen. Vibe-codierte Anwendungen führen häufig mehrstufige Schreibvorgänge ohne Transaktionsschutz aus und hinterlassen Daten in inkonsistenten Zuständen, wenn mitten in der Operation Fehler auftreten.
Betrieb und Skalierbarkeit
19. Datenbank-Connection-Pooling. Eine produktive PHP- oder Node.js-Anwendung, die sich ohne Connection-Pooling direkt mit einer Datenbank verbindet, erschöpft die Datenbank-Verbindungslimits schon unter moderater paralleler Last. PgBouncer, ProxySQL oder RDS Proxy sollten in jedem nicht-trivialen Produktions-Setup zwischen Anwendung und Datenbank sitzen.
20. Zuverlässigkeit von Background-Jobs. Background-Jobs sollten idempotent sein (gefahrlos zweimal ausführbar, ohne Seiteneffekte), Retry mit Backoff implementieren und Job-Ergebnisse in ein persistentes Log schreiben. Fehlgeschlagene Jobs sollten in eine Dead-Letter-Queue zur Inspektion und erneuten Ausführung geleitet werden. Symfony Messenger erledigt das gut, wenn es korrekt konfiguriert ist, doch vibe-codierte Anwendungen führen Jobs oft synchron oder ganz ohne diese Infrastruktur aus.
21. Strategie zur Cache-Invalidierung. Caches ohne explizite Invalidierungsstrategie produzieren Stale-Data-Bugs, die berüchtigt schwer zu reproduzieren sind. Dokumentiere den Invalidierungsansatz für jedes gecachte Datenset und teste ihn explizit.
22. Backup- und Restore-Prozeduren. Dokumentiere, wie Backups erstellt werden, wie häufig, wo sie gespeichert werden und, entscheidend, wie sie wiederhergestellt werden. Enterprise-Kunden werden fragen, ob du eine Wiederherstellung aus dem Backup getestet hast. Die meisten vibe-codierten Anwendungen haben nie eine Restore-Prozedur durchlaufen.
23. Rate-Limiting und Throttling. API-Endpunkte sollten Rate-Limits pro Nutzer und pro IP anwenden. Endpunkte, die teure Operationen auslösen (Reporterstellung, Massen-Datenexporte, E-Mail-Kampagnen), brauchen strengere Limits, um Ressourcenerschöpfung durch einen einzelnen fehlerhaften Client zu verhindern.
Wartbarkeit und Dokumentation
24. API-Dokumentation. Alle nach außen gerichteten API-Endpunkte sollten mit Request- und Response-Schemata, Authentifizierungsanforderungen, Fehlercodes und Beispiel-Payloads dokumentiert sein. Aus dem Code generierte OpenAPI/Swagger-Spezifikationen sind manuell gepflegten Dokumenten vorzuziehen, die mit der Zeit auseinanderdriften.
25. Architecture Decision Records. Dokumentiere die wesentlichen technischen Entscheidungen, die während der Entwicklung getroffen wurden: warum eine bestimmte Datenbank gewählt wurde, warum eine Queue statt synchroner Verarbeitung verwendet wird, warum eine bestimmte Bibliothek ausgewählt wurde. Diese Aufzeichnungen sind unbezahlbar, wenn die ursprüngliche Entwicklerin nicht verfügbar ist, was bei vibe-codierten Produkten, in denen eine einzelne Person alle Entscheidungen traf, oft der Fall ist.
26. Operatives Runbook. Dokumentiere, wie man deployt, zurückrollt, einen neuen Tenant hinzufügt, Nutzer-Zugangsdaten zurücksetzt und die drei oder vier wahrscheinlichsten Produktionsvorfälle behandelt. Diese Dokumentation sollte detailliert genug sein, dass eine Entwicklerin, die das System nie gesehen hat, diese Prozeduren um 2 Uhr nachts unter Druck ausführen kann.
27. Testabdeckung auf kritischen Pfaden. Enterprise-Kunden fragen womöglich nach Testabdeckungs-Reports. Wichtiger noch: Anwendungen ohne Tests auf ihren kritischen Pfaden (Authentifizierungsflüsse, Zahlungsabwicklung, Datenexport) sind anfällig beim Refactoring. Strebe hohe Abdeckung auf geschäftskritischem Code an, statt einem willkürlichen Gesamtprozentsatz hinterherzujagen.
Compliance und Auditierbarkeit
28. Audit-Log für sensible Operationen. Jede bedeutende Aktion (Login, Rechteänderung, Datenexport, Konfigurationsänderung, Finanztransaktion) sollte einen unveränderlichen Audit-Log-Eintrag erzeugen, der Akteur, Zeitstempel und Vorher/Nachher-Zustand festhält. Enterprise-Kunden verlangen das für Compliance. Es schützt dich auch rechtlich, falls eine Kundin bestreitet, was in ihrem Konto geschah.
29. Datenaufbewahrung und -löschung. Dokumentiere, wie lange Daten aufbewahrt werden, wo sie gespeichert sind und wie sie gelöscht werden, wenn ein Nutzer sein Recht auf Löschung nach DSGVO ausübt. Implementiere Datenlöschungs-Workflows, die tatsächlich funktionieren. Viele vibe-codierte Anwendungen speichern Nutzerdaten an mehreren Stellen und löschen sie nur aus der primären Tabelle, sodass Kopien in Logs, Backups und Analytics-Speichern verbleiben.
30. Datenschutz-Compliance-Dokumentation. Pflege ein Verzeichnis der Verarbeitungstätigkeiten personenbezogener Daten. Stelle sicher, dass Betroffenenrechte (Auskunft, Berichtigung, Löschung, Übertragbarkeit) technisch umsetzbar sind und nicht nur in der Datenschutzerklärung versprochen werden. Wenn du personenbezogene Daten von EU-Bürgern verarbeitest, ist das eine gesetzliche Anforderung, die von Aufsichtsbehörden durchgesetzt wird, kein optionaler Standard.
Von der Checkliste zur Enterprise-Reife
Diese Liste auf einer vibe-codierten Anwendung abzuarbeiten offenbart typischerweise eine Mischung aus schnellen Erfolgen (Security-Header hinzufügen, Error-Tracking konfigurieren, strukturiertes Logging aktivieren) und strukturellen Lücken, die sorgfältigere Arbeit erfordern, etwa das Nachrüsten von Transaktionsintegrität, das Implementieren von Audit-Logs oder das Etablieren von Backup-Restore-Prozeduren.
Die Reihenfolge zählt. Beginne mit den kritischen Sicherheitspunkten: Authentifizierung härten, Autorisierung durchsetzen und Secrets-Management. Diese tragen das höchste Risiko, wenn sie unbehandelt bleiben, und sind häufig die expliziten Blocker in Enterprise-Sicherheitsfragebögen. Wende dich dann der Observability zu, denn du kannst ein System, das du nicht sehen kannst, nicht sicher verbessern. Arbeit an Zuverlässigkeit und Wartbarkeit baut auf einem stabilen, beobachtbaren Fundament auf. Compliance-Dokumentation kommt zuletzt, weil sie festhält, was das System bereits tut, statt neue Fähigkeiten zu erfinden.
Ein Code-Quality-Audit, das eine erfahrene Entwicklerin vor deinem ersten Enterprise-Verkaufsgespräch durchführt, spart deutlich mehr Zeit, als es kostet. Ein Audit legt die Lücken offen, priorisiert sie nach realem Risiko und produziert eine Behebungs-Roadmap, die dein Team mit Zuversicht abarbeiten kann. Für vibe-codierte Anwendungen, die ohne Enterprise-Anforderungen im Blick gebaut wurden, kann ein Projekt zur Legacy-Code-Optimierung die Lücken systematisch schließen, ohne dass ein Rewrite nötig ist.
Das Ziel ist ein Softwaresystem, das Enterprise-Einkaufsteams mit Zuversicht bewerten können: eines, das Fehler kontrolliert behandelt, Nutzerdaten schützt, die von Compliance-Teams geforderten Audit-Nachweise produziert und von Entwicklern gewartet und erweitert werden kann, die nicht am Bau beteiligt waren.
Wenn du deine Anwendung auf den Enterprise-Verkauf vorbereitest und eine objektive Einschätzung willst, wo sie im Vergleich zu Produktionsstandards steht, bietet Wolf-Tech eine kostenlose Erstberatung. Kontaktiere uns unter hello@wolf-tech.io oder besuche wolf-tech.io.