Warum Vibe-Coded Apps Demos bestehen, aber Audits scheitern: Die Lücken unter einer funktionierenden UI

Die Demo lief perfekt. Jeder Button klickte, jedes Formular wurde abgeschickt, jeder Success-Toast erschien auf Stichwort. Der Investor nickte. Der Enterprise-Interessent fragte nach einem Pilotprojekt. Du bist mit Rückenwind aus dem Termin gegangen.

Dann kam die Audit-Anfrage.

Das ist eines der prägenden Vibe Coding Risiken des Jahres 2026: KI-gestützte Entwicklungswerkzeuge sind außergewöhnlich gut darin, Anwendungen zu produzieren, die produktionsreif aussehen, bevor sie es sind. Eine polierte UI und ein funktionierender Happy Path erzeugen eine überzeugende Illusion von Vollständigkeit. Auditoren, Security-Teams und Enterprise-Einkaufsabteilungen sind darauf trainiert, hinter diese Illusion zu schauen. Was sie darunter finden, kostet regelmäßig Deals, verzögert Launches und löst teure Sanierungsprojekte aus.

Dieser Beitrag zeigt die strukturellen Lücken, die eine funktionierende UI zuverlässig verdeckt, und erklärt, warum sie so leicht zu übersehen sind, bis jemand gezielt danach sucht.

Warum Demos und Audits Unterschiedliches messen

Eine Demo ist eine kuratierte Reise durch das beste Verhalten der Anwendung. Du kontrollierst die Daten, das Timing und die Reihenfolge der Aktionen. Nichts Unerwartetes passiert, weil du den Weg geprobt hast.

Ein Audit ist eine gegnerische Erkundung aller Wege, die du nicht geprobt hast. Ein technischer Auditor fragt: Was passiert, wenn die Datenbank langsam ist? Was, wenn ich ein fehlerhaftes Payload schicke? Komme ich an die Daten eines anderen Nutzers, indem ich eine ID in der URL ändere? Was passiert, wenn ein Background-Job still fehlschlägt?

Vibe-Coded Anwendungen sind standardmäßig auf den Demo-Pfad optimiert. Werkzeuge zur KI-Codegenerierung produzieren den kürzesten funktionierenden Weg zu dem im Prompt beschriebenen Ergebnis. Dieser Weg deckt den erwarteten Fall gut ab. Die unerwarteten Fälle deckt er selten überhaupt ab.

Das Ergebnis ist eine strukturelle Asymmetrie: Die Anwendung ist so stark wie ihr bester Fall und so schwach wie jeder Fall, der nie beschrieben wurde.

Lücke 1: Fehlerbehandlung, die am Happy Path endet

Öffne den Network-Tab während einer typischen Demo einer Vibe-Coded App und du siehst saubere 200er-Antworten. Öffne ihn während einer Audit-Simulation und du siehst häufig rohe Stack Traces, nichtssagende 500er-Fehler oder stille Fehlschläge, die die UI in einem inkonsistenten Zustand zurücklassen.

KI-Codegenerierung behandelt Fehler so, wie die meisten Entwickler sie anfangs behandeln: mit einem generischen Try-Catch-Block, der die Exception schluckt und nichts Brauchbares zurückgibt. Das erzeugt mehrere Probleme im Produktivbetrieb. Nutzer bekommen kein umsetzbares Feedback, wenn etwas schiefgeht. Support-Teams bekommen kein Signal, dass überhaupt etwas passiert ist. Engineers, die einen Incident debuggen, haben nichts, womit sie arbeiten können.

Noch kritischer: Unbehandelte Fehler in Background-Jobs und asynchronen Prozessen scheitern typischerweise still. Ein Payment-Webhook, der beim dritten Retry fehlschlägt, zeigt in der UI nichts an. Eine E-Mail-Queue, die aufhört zu verarbeiten, alarmiert niemanden. Die App sieht gesund aus, bis ein Kunde meldet, dass seine Bestellung nie angekommen ist.

Vor jedem echten Deployment braucht jeder Fehlerpfad dieselbe Aufmerksamkeit wie der Erfolgspfad: aussagekräftige Meldungen für Nutzer, strukturierte Logs für den Betrieb und Alerting für alles, was nicht still fehlschlagen darf.

Lücke 2: Eine Angriffsfläche, die die Demo nie betritt

Sicherheit ist die Lücke, die Auditoren am zuverlässigsten finden, und sie ist die Lücke, die in Vibe-Coded Anwendungen am wahrscheinlichsten auftaucht. Der Grund ist strukturell: Sicherheit erfordert, darüber nachzudenken, was ein Angreifer versuchen wird, nicht was ein legitimer Nutzer tut. KI-Modelle generieren Code für legitime Nutzer.

Die häufigsten Befunde in einem Code-Quality-Audit von Vibe-Coded Anwendungen gruppieren sich um wenige Muster.

Autorisierung wird auf der UI-Ebene umgesetzt, aber nicht auf der API-Ebene durchgesetzt. Die Buttons, die ein Nutzer nicht sehen soll, sind im Frontend versteckt, aber die API-Endpunkte, die diese Buttons aufrufen, sind ungeschützt. Ein Request, der direkt mit der ID eines anderen Nutzers gesendet wird, geht durch.

Eingabevalidierung ist im Formular vorhanden, im Controller aber nicht. Client-seitige Validierung verhindert, dass schlechte Daten über die UI abgeschickt werden. Sie hält einen POST-Request aus einem Skript in keiner Weise auf.

Authentifizierungs-Tokens werden im localStorage gespeichert, der von jedem JavaScript auf der Seite gelesen werden kann. Eine einzige XSS-Schwachstelle gibt einem Angreifer Zugriff auf jede aktive Session.

Rate Limiting existiert auf sensiblen Endpunkten nicht. Ein automatisiertes Skript kann in Minuten Tausende Login-Kombinationen durchprobieren oder ein nutzungsbasiertes API-Limit ausschöpfen.

Keine dieser Schwachstellen zeigt sich in einer Demo. Alle zeigen sich in einem Security-Audit.

Lücke 3: Datenintegritätsprobleme, die erst im echten Betrieb auftauchen

KI-generierte Datenbankinteraktionen sind typischerweise auf Korrektheit im Einzelnutzerfall optimiert. Der erste Nutzer, der sich registriert, bekommt eine saubere Erfahrung. Was passiert, wenn zwei Nutzer dieselbe Aktion gleichzeitig ausführen, ist oft undefiniert.

Race Conditions in Vibe-Coded Anwendungen sind verbreitet. Zwei parallele Requests, die eine begrenzte Ressource beanspruchen, sind häufig beide erfolgreich, weil Prüfung und Schreibvorgang zwei getrennte Datenbankoperationen ohne Locking dazwischen sind. Die Anwendungslogik ist isoliert betrachtet korrekt und unter Nebenläufigkeit falsch.

Schema-Migrationen sind ein weiteres wiederkehrendes Problem. Vibe-Coded Anwendungen sammeln oft Schema-Änderungen an, die direkt auf der Entwicklungsdatenbank angewendet wurden statt über versionierte Migrationsdateien. Wird die Anwendung in einer neuen Umgebung deployt oder von einer externen Partei geprüft, gibt es keinen verlässlichen Weg, das Schema zu reproduzieren. Die Demo-Datenbank hat Monate manueller Änderungen, die nirgendwo festgehalten sind.

Fehlende Datenbankindizes sind weniger dramatisch, erzeugen aber ernsthafte Probleme bei Skalierung. Eine Anwendung, die mit 500 Testdatensätzen akzeptabel läuft, läuft bei Abfragen über 500.000 Produktivdatensätze in einen Timeout. Die Demo hat das nie gezeigt, weil sie nie gegen echte Datenmengen lief.

Lücke 4: Tests, die den Happy Path bestätigen statt ihn zu hinterfragen

Vibe-Coded Anwendungen haben häufig Testsuites. Das kann ein falsches Sicherheitsgefühl erzeugen. Die Frage ist nicht, ob Tests existieren, sondern was sie tatsächlich prüfen.

Wenn eine KI Tests zusammen mit dem Anwendungscode generiert, neigt sie dazu, Tests zu schreiben, die das bestehende Verhalten bestätigen, statt die Annahmen dahinter zu hinterfragen. Ein Test für einen Endpunkt zur Nutzeranlage prüft, dass ein valider POST-Request eine 201-Antwort liefert. Er prüft nicht, was bei einer doppelten E-Mail-Adresse, einem SQL-Injection-Versuch, einem Payload ohne Pflichtfelder oder einem Request eines bereits authentifizierten Nutzers passiert.

Kennzahlen zur Testabdeckung melden, welche Codezeilen während des Testlaufs ausgeführt wurden. Sie melden nicht, ob die Tests etwas Sinnvolles geprüft haben. Eine Anwendung mit 80 Prozent Line Coverage und Tests, die nur den Happy Path ablaufen, hat eine grüne Testsuite und ein ungeprüftes Sicherheitsmodell.

Ein Projekt zur Legacy-Code-Optimierung deckt oft auf, dass die kritischsten Pfade der Anwendung gar keine Tests haben, weil sie iterativ hinzugefügt wurden und die KI nie gebeten wurde, sie zu testen.

Lücke 5: Keine Observability darüber, was die Anwendung tatsächlich tut

In einer Demo siehst du alles, weil du auf den Bildschirm schaust. Im Produktivbetrieb läuft die Anwendung durchgehend, ohne dass jemand zuschaut. Der einzige Weg zu wissen, was passiert, führt über Logs, Metriken und Traces.

Vibe-Coded Anwendungen sind fast durchgängig unzureichend instrumentiert. Logging beschränkt sich oft auf Konsolenausgaben, die in einer containerisierten Umgebung nirgendwo landen. Es gibt keine strukturierten Log-Events, die während eines Incidents ein Filtern nach Nutzer-ID oder Transaktions-ID erlauben würden. Es gibt keine Performance-Metriken, die erfassen, wie lange Datenbankabfragen dauern. Es ist kein Alerting konfiguriert, das jemanden benachrichtigt, wenn Fehlerraten steigen.

Das ist keine kleine betriebliche Unannehmlichkeit. Es bedeutet, dass der Debugging-Prozess bei einem Produktionsproblem bei nahezu null Information startet. Enterprise-Kunden und deren Security-Teams merken das in einem Audit. Strukturierte Observability ist eine Grunderwartung an Produktivsoftware, keine optionale Erweiterung.

Lücke 6: Wildwuchs bei Abhängigkeiten und ungeprüfte Pakete

Werkzeuge zur KI-Codegenerierung ziehen Bibliotheken herein, die das unmittelbare Problem lösen. Die Wahl ist auf Bequemlichkeit und Verfügbarkeit optimiert, nicht auf Security-Historie, Wartungsstand oder Lizenzkompatibilität.

Ein Dependency-Audit einer Vibe-Coded Codebasis fördert oft Pakete zutage, die seit Jahren nicht aktualisiert wurden, Pakete mit bekannten CVEs in der installierten Version, Pakete mit GPL- oder AGPL-Lizenzen, die für kommerzielle Software Compliance-Probleme erzeugen, und Pakete, die für ein Problem installiert wurden, das später anders gelöst wurde, aber nie entfernt wurden.

Enterprise-Einkaufsabteilungen prüfen das. Dependency-Audits sind ein Standardbestandteil der technischen Due Diligence vor einer Übernahme oder einem größeren Enterprise-Vertrag. Eine Codebasis mit Dutzenden veralteter oder ungeprüfter Abhängigkeiten wirft Fragen auf, die Deals verlangsamen oder beenden.

Die Lücke schließen, bevor das Audit sie findet

Der Abstand zwischen demo-reif und audit-reif ist real, aber überbrückbar. Der wirksamste Weg ist ein strukturiertes Review, das gezielt nach den obigen Kategorien sucht, bevor eine externe Partei es tut.

Dieses Review deckt ab: Durchsetzung der Autorisierung auf API-Ebene, Eingabevalidierung und Output-Encoding durchgängig, Nebenläufigkeits- und Datenintegritätskontrollen, Migrations- und Schema-Management, Testabdeckung der Fehlerpfade, Observability-Infrastruktur und den Zustand der Abhängigkeiten. Das ist die Art von Arbeit, die ein Code Quality Consulting Projekt oder ein Tech-Stack-Strategie Review abdeckt, je nachdem, wie früh im Entwicklungsprozess die Probleme gefunden werden.

Eine funktionierende UI ist kein Beleg für ein solides System. Sie ist ein Beleg dafür, dass der Happy Path funktioniert. Von dort zu etwas zu kommen, das einer Prüfung standhält, erfordert einen bewussten Prozess, und diese Arbeit vor dem Audit zu erledigen ist deutlich günstiger als danach.

Wenn deine Vibe-Coded Anwendung vor einem Audit, einem Enterprise-Piloten oder einer Finanzierungsrunde mit technischer Due Diligence steht, melde dich unter hello@wolf-tech.io. Wir haben eine beachtliche Zahl KI-generierter Codebasen bei wolf-tech.io geprüft und können dir schnell sagen, womit du es zu tun hast.