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 entwickelt. Die Demo lief hervorragend. Erste Kunden nutzen es. Dann zeigt ein mittelgroßes Unternehmen echtes Kaufinteresse - und das Procurement-Team schickt einen Sicherheitsfragebogen. Darin geht es um Audit-Logs, SSO-Support, Ergebnisse von Penetrationstests, SLA-Garantien, Richtlinien zur Datenaufbewahrung und Disaster-Recovery-Prozesse.
Die meisten vibe-gecodeten Produkte können nicht einmal die Hälfte dieser Fragen beantworten.
Das ist die Erwartungslücke im Enterprise-Geschäft. KI-Tools sind hervorragend darin, Code zu generieren, der die funktionalen Anforderungen vor ihnen erfüllt. Sie sind nicht dafür gemacht, Software zu produzieren, die die nicht-funktionalen Anforderungen von Enterprise-Procurement erfüllt - Audit-Trails, Compliance-Nachweise, betriebliche Stabilität und die Art von Dokumentation, auf die ein CTO seinen Ruf setzen kann.
Diese Lücke zu schließen erfordert keinen Neustart. Es erfordert eine systematische Bestandsaufnahme dessen, was fehlt, und eine disziplinierte Nacharbeit. Diese Production-Readiness-Checkliste deckt die 30 Bereiche ab, in denen vibe-gecodete Anwendungen am häufigsten durchfallen, wenn Enterprise-Kunden sie bewerten.
Warum Enterprise-Kunden anders prüfen
Enterprise-Käufer haben Lehrgeld bezahlt. Sie haben Software eingeführt, die unter Spitzenlast ausgefallen ist, Daten in einem nicht wiederherstellbaren Vorfall verloren hat oder eine Sicherheitslücke verursacht hat. Ihr Beschaffungsprozess spiegelt diese harten Lektionen wider.
Enterprise-Procurement bewertet Software entlang mehrerer Dimensionen, die Vibe Coding komplett ignoriert: betriebliche Stabilität (fällt das System kontrolliert aus?), Sicherheitslage (können wir dem System Kundendaten anvertrauen?), Wartbarkeit (kann unser Team die Verantwortung übernehmen, falls der Anbieter verschwindet?), Compliance-Fähigkeit (kann das System die Audit-Nachweise liefern, die unsere Prüfer verlangen?) und Integrationsrobustheit (verhält sich das System vorhersehbar, wenn es mit unseren anderen Systemen verbunden wird?).
Die in Vibe Coding eingesetzten KI-Tools generieren Code, der die funktionale Aufgabenstellung erfüllt. Sie modellieren keine Angreifer, keine betrieblichen Ausfallszenarien und nicht die Bedürfnisse eines zukünftigen Entwicklers, der die Codebasis noch nie gesehen hat.
Die Production-Readiness-Checkliste
Sicherheit
1. Härtung der Authentifizierung. JWT-Tokens sollten kurze Ablaufzeiten 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 eine Kontosperre nach fehlgeschlagenen Versuchen.
2. Autorisierung auf jedem Endpunkt erzwingen. Zugriffskontrolllogik muss auf dem Server liegen, nicht im Client. Teste jeden Endpunkt, indem du Requests mit Tokens verschiedener Nutzer schickst und verifizierst, dass nutzerübergreifender Datenzugriff unmöglich ist.
3. Eingabevalidierung und Ausgabe-Escaping. Jedes nutzergenerierte Datum, das ins System gelangt, sollte gegen ein explizites Schema validiert werden. Jeder nutzergenerierte Inhalt, der im Frontend gerendert wird, sollte escaped werden. SQL- und NoSQL-Abfragen müssen ausschließlich parametrisierte Eingaben verwenden.
4. Secrets-Management. Keine Zugangsdaten, API-Keys oder Tokens im Quellcode oder in der Git-Historie. Nutze Umgebungsvariablen mit einem Secrets-Manager (AWS Secrets Manager, HashiCorp Vault oder ein Cloud-natives Äquivalent). Rotiere alle Secrets, die jemals committet wurden, auch wenn 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 in Produktion gehen.
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-gecodeten Anwendungen oft, weil sie auf der Infrastrukturebene leben statt auf der Anwendungsebene.
7. Datenverschlüsselung at rest und in transit. TLS überall für Daten in transit. Sensible Datenfelder - PII, Zahlungsinformationen, Gesundheitsdaten - werden at rest auf Spaltenebene der Datenbank verschlüsselt, wenn Compliance das verlangt.
Observability
8. Strukturiertes Logging. Anwendungslogs sollten maschinenlesbares JSON mit konsistenten Feldern sein: Zeitstempel, Log-Level, Korrelations-ID, Nutzer-ID (wo zutreffend) und Ereignisbeschreibung. Vermeide unstrukturiertes printf-artiges Logging, das sich weder durchsuchen noch für Alerts nutzen lässt.
9. Error-Tracking. Integriere einen Error-Tracking-Dienst (Sentry, Bugsnag oder Äquivalent), damit jede unbehandelte Exception erfasst, gruppiert und an das Engineering-Team weitergeleitet wird. Ohne das bleiben Produktionsfehler unsichtbar, bis Nutzer sie melden.
10. Request-Tracing. Implementiere Distributed Tracing mit einer Korrelations-ID, die einem Request durch jeden Service, jede Queue und jeden Background-Job folgt. Wenn ein Nutzer meldet, dass "etwas schiefgelaufen" ist, musst du exakt nachvollziehen können, was passiert ist.
11. Application Performance Monitoring. Verfolge Request-Latenz, Datenbank-Query-Zeiten, Cache-Hit-Raten und den Durchsatz von Background-Jobs. Setze Schwellenwerte und alarmiere, bevor Nutzer eine Verschlechterung bemerken. Diese Instrumentierung fehlt in vibe-gecodeten Anwendungen fast immer.
12. Infrastruktur-Metriken. CPU-, Speicher-, Disk- und Netzwerk-Metriken mit Alerting. Das ist die Grundausstattung, aber vibe-gecodete Anwendungen werden oft ohne jegliche Betriebs-Dashboards ausgeliefert.
13. Health-Check-Endpunkte. Stelle /health- und /ready-Endpunkte bereit, die Datenbankverbindung, Cache-Verfügbarkeit und externe Service-Abhä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 unkritische externe Abhängigkeit ausfällt - ein Analytics-Dienst, ein Benachrichtigungsanbieter, ein Anreicherungsschritt im Hintergrund - sollte die Anwendung ihre Kernfunktion weiter erfüllen. Kritische Pfade dürfen nicht von unkritischen Services abhängen.
15. Aussagekräftige Fehlermeldungen für Nutzer. Fehlermeldungen in Produktion sollten informativ sein, ohne Systeminterna preiszugeben. Keine Stack-Traces, keine SQL-Fehlermeldungen, keine internen IDs in nutzerseitigen Antworten. "Wir konnten deine Zahlung nicht verarbeiten - bitte versuche es erneut oder kontaktiere den Support" ist richtig. Eine Doctrine-Exception mit Query-Dump ist es nicht.
16. Retry-Logik für externe Aufrufe. HTTP-Requests an externe Services sollten Exponential Backoff mit Jitter implementieren. Background-Jobs sollten konfigurierbare Retry-Limits mit Dead-Letter-Queuing für Jobs haben, die alle Wiederholungen ausgeschöpft haben.
17. Timeout-Konfiguration. Jeder externe HTTP-Aufruf, jede Datenbankabfrage und jeder Background-Job sollte ein explizites Timeout haben. Fehlende Timeouts bedeuten, dass ein langsamer Upstream-Service Verbindungen unbegrenzt offen halten kann, was irgendwann den Connection-Pool erschöpft und die Anwendung lahmlegt.
18. Transaktionsintegrität. Operationen, die mehrere Datensätze verändern, sollten in Datenbanktransaktionen gekapselt sein, die bei Fehlern zurückgerollt werden. Vibe-gecodete Anwendungen führen häufig mehrstufige Schreibvorgänge ohne Transaktionsschutz aus und hinterlassen inkonsistente Datenzustände, wenn mitten in der Operation ein Fehler auftritt.
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 Verbindungslimits der Datenbank schon bei 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 (zweimaliges Ausführen ohne Nebenwirkungen), Retry mit Backoff implementieren und Job-Ergebnisse in ein persistentes Log schreiben. Fehlgeschlagene Jobs sollten in eine Dead-Letter-Queue wandern, wo sie inspiziert und erneut ausgeführt werden können. Symfony Messenger löst das gut, wenn es richtig konfiguriert ist - aber vibe-gecodete Anwendungen führen Jobs oft synchron oder ganz ohne diese Infrastruktur aus.
21. Cache-Invalidierungsstrategie. Caches ohne explizite Invalidierungsstrategie produzieren Stale-Data-Bugs, die notorisch schwer zu reproduzieren sind. Dokumentiere den Invalidierungsansatz für jeden gecachten Datensatz 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 fragen, ob du die Wiederherstellung aus einem Backup getestet hast. Bei den meisten vibe-gecodeten Anwendungen wurde noch nie eine Restore-Prozedur durchgeführt.
23. Rate-Limiting und Throttling. API-Endpunkte sollten Limits pro Nutzer und pro IP anwenden. Endpunkte, die teure Operationen auslösen - Berichtserstellung, Massendaten-Exporte, E-Mail-Kampagnen - brauchen strengere Limits, damit ein einzelner fehlerhafter Client nicht alle Ressourcen aufbraucht.
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 wichtigen technischen Entscheidungen aus der Entwicklung: warum eine bestimmte Datenbank gewählt wurde, warum eine Queue statt synchroner Verarbeitung eingesetzt wird, warum eine bestimmte Library ausgewählt wurde. Diese Aufzeichnungen sind unbezahlbar, wenn der ursprüngliche Entwickler nicht verfügbar ist - was bei vibe-gecodeten Produkten oft der Fall ist, weil ein einzelner Entwickler alle Entscheidungen getroffen hat.
26. Betriebs-Runbook. Dokumentiere, wie man deployt, zurückrollt, einen neuen Tenant anlegt, Nutzer-Zugangsdaten zurücksetzt und die drei oder vier wahrscheinlichsten Produktionsvorfälle behandelt. Diese Dokumentation sollte so detailliert sein, dass ein Entwickler, der das System noch nie gesehen hat, diese Prozeduren um 2 Uhr nachts unter Druck ausführen kann.
27. Testabdeckung auf kritischen Pfaden. Enterprise-Kunden fragen unter Umständen nach Testabdeckungsberichten. Wichtiger noch: Anwendungen ohne Tests auf ihren kritischen Pfaden - Authentifizierungs-Flows, Zahlungsabwicklung, Datenexport - sind fragil gegenüber Refactorings. Strebe hohe Abdeckung auf geschäftskritischem Code an, statt einer willkürlichen Gesamtprozentzahl hinterherzujagen.
Compliance und Auditierbarkeit
28. Audit-Log für sensible Operationen. Jede bedeutsame Aktion - Login, Berechtigungsä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 ihre Compliance. Es schützt dich auch rechtlich, wenn ein Kunde bestreitet, was in seinem Konto passiert ist.
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 Löschworkflows, die tatsächlich funktionieren - viele vibe-gecodete Anwendungen speichern Nutzerdaten an mehreren Stellen und löschen sie nur aus der Primärtabelle, während Kopien in Logs, Backups und Analytics-Speichern verbleiben.
30. Datenschutz-Dokumentation. Führe ein Verzeichnis von 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. Wer personenbezogene Daten von EU-Bürgern verarbeitet, hat hier eine gesetzliche Pflicht, die von Aufsichtsbehörden durchgesetzt wird - kein optionaler Standard.
Von der Checkliste zur Enterprise-Reife
Wer diese Liste an einer vibe-gecodeten Anwendung durcharbeitet, findet typischerweise eine Mischung aus Quick Wins - Security-Header ergänzen, Error-Tracking konfigurieren, strukturiertes Logging aktivieren - und strukturellen Lücken, die sorgfältigere Arbeit erfordern, etwa das Nachrüsten von Transaktionsintegrität, die Implementierung von Audit-Logs oder das Etablieren von Backup-Restore-Prozeduren.
Die Reihenfolge ist entscheidend. Beginne mit den kritischen Sicherheitsthemen: Härtung der Authentifizierung, Durchsetzung der Autorisierung und Secrets-Management. Sie bergen das höchste Risiko, wenn sie unbehandelt bleiben, und sind häufig die expliziten Blocker in Enterprise-Sicherheitsfragebögen. Kümmere dich danach um Observability, denn ein System, das du nicht sehen kannst, kannst du 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-Qualitäts-Audit durch einen Senior-Entwickler vor deinem ersten Enterprise-Verkaufsgespräch spart deutlich mehr Zeit, als es kostet. Ein Audit deckt die Lücken auf, priorisiert sie nach realem Risiko und liefert eine Roadmap zur Behebung, die dein Team mit Zuversicht umsetzen kann. Für vibe-gecodete Anwendungen, die ohne Enterprise-Anforderungen im Hinterkopf gebaut wurden, kann ein Engagement zur Legacy-Code-Optimierung die Lücken systematisch schließen, ohne dass ein Rewrite nötig ist.
Das Ziel ist ein Softwaresystem, das Enterprise-Procurement-Teams mit Vertrauen bewerten können: eines, das kontrolliert mit Fehlern umgeht, Nutzerdaten schützt, die Audit-Nachweise liefert, die Compliance-Teams verlangen, und das von Entwicklern gewartet und erweitert werden kann, die nicht am Aufbau beteiligt waren.
Wenn du deine Anwendung auf Enterprise-Vertrieb vorbereitest und eine objektive Einschätzung möchtest, wo sie gegenüber Produktionsstandards steht, bietet Wolf-Tech eine kostenlose Erstberatung an. Kontaktiere uns unter hello@wolf-tech.io oder besuche wolf-tech.io.