Audit von Vibe-Coded Software: Was vor dem Launch bricht

Du hast dich per Prompt zu funktionierender Software gebracht. Sie meldet Leute an, zeigt die richtigen Screens, sieht in der Demo gut aus. Und du hast den Code, der sie ausführt, nie gelesen. Genau für diese Situation ist ein Vibe-Coded-Audit gemacht. Die unbequeme, aber einfache Wahrheit darunter: du kannst Code nicht vertrauen, den du nie gelesen hast. Bevor echtes Geld oder echte Nutzer ihn berühren, muss jemand, der beruflich Code liest, anschauen, was das Modell tatsächlich geschrieben hat, nicht, was es zu tun scheint.

Das ist kein Argument gegen das Bauen mit KI. Sie hat dir schneller ein Produkt verschafft als jeder andere Weg. Es ist ein Argument dafür, dieses Produkt genauso zu prüfen, wie du alles prüfen würdest, das gleich Kundendaten hält und Zahlungen entgegennimmt.

Was ist ein Vibe-Coded-Audit?

Ein Vibe-Coded-Audit ist ein strukturiertes Lesen von KI-generiertem Code auf die Risiken, die das Modell übersprungen hat. Es ist kein Feature-Review. Ein Feature-Review fragt "tut es, was der Nutzer will". Ein Audit stellt die Fragen, die der Prompt nie gestellt hat: Wer darf diese Daten lesen, was passiert, wenn dieser Aufruf fehlschlägt, wo ist dieses Secret gelandet, was bricht bei tausend Nutzern statt bei zehn.

Der Unterschied zählt, weil die Fehler hier von außen unsichtbar sind. Das Produkt sieht fertig aus. Die Lücken sitzen in den Teilen, die keine Demo durchspielt: der Pfad, in dem das Netz wegbricht, der Request, der zweimal ankommt, der Nutzer, der die URL editiert, um den Datensatz eines anderen zu lesen. Wir lesen den Code, um die zu finden, bevor es ein Nutzer tut.

Die sieben Dinge, die wir zuerst prüfen

Jedes Audit beginnt an denselben Stellen, weil Vibe-Coded-Software an denselben Stellen bricht. Das sind die Findings, die wir am häufigsten aufdecken.

• Security und Autorisierung. Der Login funktioniert. Die Prüfung, die Nutzer A daran hindert, die Daten von Nutzer B zu lesen, fehlt oder lebt im Frontend, wo jeder darum herumgehen kann. Das ist das häufigste schwere Finding und das teuerste, das man übersieht.
• Datenintegrität. Writes, die halb durchlaufen können. Ein Datensatz, gespeichert ohne den zugehörigen Datensatz, von dem er abhängt. State, den die Datenbank nicht wirklich garantieren kann, sodass die Zahlen mit der Zeit driften und niemand weiß warum.
• Geleakte Secrets. API-Keys, Datenbank-URLs und Tokens hartkodiert im Client-Code oder ins Repo committet. Das Modell schreibt sie inline, weil das Beispiel dann läuft. Jeder, der das Bundle öffnet, kann sie lesen.
• Error-Handling. Der Happy Path ist abgedeckt. Ein fehlgeschlagener Aufruf, ein Timeout oder ein leeres Ergebnis wirft eine unbehandelte Exception und der Screen wird weiß, ohne Meldung, ohne Wiederherstellung.
• Skalierbarkeit und Queries. Ein Datenbankaufruf, in ein Render geschleift, oder eine ganze Tabelle gezogen, um ihre Zeilen zu zählen. Okay bei zehn Datensätzen in der Demo, fatal bei hunderttausend in Produktion.
• Dependencies und Lizenzen. Pakete, die veraltet, verwaist oder mit bekannten Schwachstellen behaftet sind, dazu Lizenzen, die die kommerzielle Nutzung, die du planst, still verbieten.
• Testabdeckung. Meist keine. Nichts hält die nächste Änderung davon ab, KI-geschrieben oder nicht, still zu brechen, was schon funktioniert.

"Die Gefahr von Vibe-Coded-Software ist nicht, dass der Code schlecht ist. Es ist, dass ihn niemand gelesen hat. Vertrauen ist das eine, das ein Modell dir nicht geben kann, und es ist das Einzige, das entscheidet, ob du launchen kannst."

Severity: Was den Launch blockiert versus was warten kann

Nicht jedes Finding stoppt einen Launch, und sie alle so zu behandeln friert dich nur ein. Wir sortieren alles, was wir finden, in drei Eimer, damit du weißt, was du heute Abend fixt und was du planen kannst.

• Blocker. Alles, was Kundendaten freilegt, Geld verliert oder State korrumpiert. Eine kaputte Autorisierungsprüfung oder ein geleakter Zahlungs-Key wartet nicht. Der Launch wartet darauf.
• Hoch. Echtes Risiko, das noch nicht zugebissen hat. Die Query, die bei Skalierung stirbt, das fehlende Error-Handling auf einem Zahlungspfad, die verwaiste Dependency mit bekanntem CVE. Fixen, bevor du hineinwächst.
• Cleanup. Schulden, die echt, aber überlebbar sind. Inkonsistente Muster, dünne Validierung bei risikoarmen Eingaben, fehlende Tests auf stabilem Code. Lohnt sich, ist sicher planbar.

Der Sinn der Aufteilung ist Ehrlichkeit über Dringlichkeit. Wir verkleiden kein Cleanup-Item als Blocker, um die Arbeit aufzublähen, und wir lassen keinen echten Blocker in einer langen Liste verschwinden.

Was du tatsächlich bekommst

Das Ergebnis ist kein PDF voller Beschwerden, mit denen du nichts anfangen kannst. Es sind zwei Dinge. Erstens ein Findings-Report: jedes Problem, seine Severity und was es riskiert, so geschrieben, dass ein nicht-technischer Gründer entscheiden kann, was zählt. Zweitens ein reparierter Branch mit Tests: die Blocker geschlossen, die Hochs adressiert, soweit der Scope es zulässt, und eine Regressions-Suite, die die Fixes hält. Du bekommst funktionierenden Code zurück, keine Liste von Gründen, warum er kaputt ist. Wenn du die tiefere Mechanik dieses Hardening-Durchgangs willst, behandeln wir sie in QA für KI-generierten Code.

Audit versus volles QA versus Rebuild

Das sind drei verschiedene Entscheidungen, und die ehrliche Antwort hängt davon ab, was das Lesen zutage fördert.

• Audit. Die richtige Wahl, wenn das Produkt weitgehend funktioniert und du wissen musst, was sich versteckt, bevor du skalierst oder Zahlungen annimmst. Schnell, fokussiert, endet in einem Findings-Report und einem reparierten Branch.
• Volles QA. Die richtige Wahl, sobald das Produkt echt und laufend ist. Ein stehender Prozess aus Tests, Reviews und Hardening, der die nächste Änderung davon abhält, die letzte rückgängig zu machen. Das Audit ist oft der erste Schritt hinein.
• Rebuild. Manchmal zeigt das Lesen, dass der Kern selbst falsch ist, ein Datenmodell, das nicht halten kann, was du brauchst, oder dasselbe kaputte Muster über die ganze Codebasis kopiert. Wenn das passiert, ist der Kern neu zu bauen billiger, als ihn ewig zu flicken, und das sagen wir am ersten Telefonat, statt dir zu berechnen, ein Fundament zu flicken, das neu gegossen werden muss.

Kosten und Zeitrahmen

Ein Audit läuft von ein paar Tagen bis etwa zwei Wochen. Die Spanne ist ehrlich, nicht ausweichend, und zwei Dinge bewegen sie: wie groß die Codebasis ist und wie viel echtes Geld oder sensible Daten sie berührt. Ein read-only internes Tool sitzt am kurzen Ende. Ein Produkt, das Zahlungen annimmt und personenbezogene Daten hält, sitzt am langen Ende, weil genau das die Teile sind, die das genaueste Lesen brauchen. Wir scopen es nach einem ersten Blick, nicht davor, und wir nennen dir die Spanne vorab, statt sie auf deiner Rechnung zu entdecken. Das ist das Front-End unseres Software-QA-Service.