Das Vibe Code Audit: Ein strukturierter Review-Prozess für KI-generierte Codebasen vor dem Produktionsstart

Du hast dir einen KI-Pair-Programmer geholt - Cursor, Claude Code, GitHub Copilot - und nach zwei Wochen stand ein funktionierender SaaS-Prototyp. Schnelle Feature-Lieferung, vernünftige Struktur, Tests auf Grün. Dann kamen echte Nutzer.

Ein Vibe Code Audit ist der Weg, die Probleme zu finden, bevor sie deine Nutzer finden.

Das ist der strukturierte Review-Prozess, den Wolf-Tech einsetzt, wenn ein Founder oder CTO mit einer KI-unterstützten Codebasis zu uns kommt und fragt: "Können wir das wirklich ausliefern?" Das Audit umfasst sieben Dimensionen. Jede deckt eine andere Kategorie von Fehlern auf, die KI-Codegenerierung in großem Maßstab produziert.

Warum KI-generierter Code ein eigenes Audit-Framework braucht

Klassische Code-Review-Checklisten wurden für von Menschen geschriebenen Code entworfen. Sie setzen voraus, dass ein Entwickler bewusste Architekturentscheidungen getroffen und die Konsequenzen verstanden hat. KI-Assistenten arbeiten anders: Sie optimieren auf plausibel aussehenden Code, der den unmittelbaren Prompt erfüllt, nicht auf langfristige Kohärenz.

Die daraus resultierenden Muster sind eigenständig genug für eine eigene Checkliste. Du wirst selten einen einzelnen katastrophalen Bug finden. Stattdessen findest du Dutzende kleiner Entscheidungen - jede für sich technisch vertretbar - die sich zu einem System kombinieren, das schwer erweiterbar ist, unter Last fragil wird und nachträglich teuer abzusichern ist.

Ein Vibe Code Audit ist kein allgemeines Code-Review. Es ist eine gezielte Suche nach genau den Fehlermodi, die LLM-generierter Code am zuverlässigsten produziert.

Dimension 1: Architektonische Kohärenz

Als Erstes prüfen wir, ob die Codebasis eine konsistente innere Logik hat oder ob sie aussieht, als hätten mehrere Entwickler daran gearbeitet, die nie miteinander gesprochen haben.

KI-Assistenten haben kein Gedächtnis über Sessions hinweg. Bitte Cursor am Montag, ein Authentifizierungsmodul zu bauen, und es trifft zehn kleine Entscheidungen - wo Session-State liegt, wie Service-Klassen heißen, wie Fehler behandelt werden. Bitte es am Freitag um ein Billing-Modul, und es trifft zehn andere kleine Entscheidungen. Bei einem Dutzend Features enthält die Codebasis drei oder vier implizite Architekturstile, die gegeneinander kämpfen.

Worauf du achten solltest:

• Inkonsistente Modulgrenzen. Ruft der Authentifizierungscode den Billing-Service direkt auf? Hat das Notification-Modul Datenbankzugriff? Module, die ihre eigenen Grenzen verletzen, sind ein Zeichen für Prompt-für-Prompt-Entwicklung ohne übergreifende Architektur.
• Widersprüchliche Namenskonventionen. Eine Codebasis, die UserService, user_repository, UserManager und UserHelper für gleichwertige Abstraktionen mischt, wurde nicht entworfen - sie wurde zusammengesetzt.
• Mehrere Fehlerbehandlungsstrategien. Exceptions an manchen Stellen, Return-Codes an anderen, nackte console.error-Aufrufe an dritten. Die KI nutzt das Muster, das im nächstgelegenen Kontext auftauchte.

Die Behebung ist an diesem Punkt architektonisch: Du musst entscheiden, welches Muster gewinnt, es dokumentieren und systematisch darauf hin refaktorieren. Werkzeuge wie PHPStan (für PHP), TypeScript im Strict Mode und ESLint erzwingen Konsistenz für die Zukunft, können die angesammelte Divergenz aber nicht rückwirkend beheben.

Dimension 2: Sicherheitsoberfläche

Das ist die Dimension, in der vibe-codierte Projekte das höchste Risiko für unmittelbaren, ernsten Schaden tragen.

LLMs generieren Code, der auf dem Happy Path funktioniert. Sicherheit ist fast immer eine Anforderung aus einem separaten Prompt - was bedeutet, dass sie nur dort umgesetzt wird, wo explizit danach gefragt wurde. Die Lücken sind vorhersehbar:

SQL-Injection bleibt der häufigste Fund. KI-Assistenten nutzen Query-Builder oder ORMs oft falsch und fallen auf String-Interpolation zurück, sobald eine Query komplex wird. Schon eine einzige Raw-Query mit nutzergesteuertem Input reicht.

CSRF-Schutz fehlt häufig auf zustandsändernden Endpoints mit Custom Headers (weil der Entwickler der KI sagte, es sei eine API, und die KI annahm, APIs bräuchten keinen CSRF-Schutz - was nur für zustandslose, token-authentifizierte APIs stimmt, nicht für session-basierte Hybrid-Apps).

Hartkodierte Zugangsdaten und Secrets tauchen in KI-generiertem Code regelmäßig auf, weil der schnellste Weg zu einem funktionierenden Proof of Concept ist, den API-Key direkt in den Quellcode zu schreiben. Diese überleben den Übergang vom Prototyp zur Produktion erstaunlich oft unverändert.

Rechteausweitung ist in Multi-Tenant-Anwendungen verbreitet. KI-Assistenten generieren oft Lookup-Code, der Ressourcen per Primärschlüssel lädt, ohne zu prüfen, ob der authentifizierte Nutzer Zugriff auf diese Ressource hat. Der Check wird für die offensichtlichsten Endpoints ergänzt und beim Rest vergessen.

Verwundbare Dependencies verdienen einen eigenen Abschnitt (Dimension 4), aber unsichere Defaults in direkten Abhängigkeiten - veraltete Kryptoalgorithmen, permissive CORS-Konfiguration, fehlende Security-Header - sind Sicherheitsprobleme, die mit dem ersten npm install ins Haus kommen.

Wir lassen automatisierte Scanner (Semgrep, npm audit, Rector-Security-Regeln) als Basis laufen, aber das manuelle Review von Authentifizierungsflüssen und Multi-Tenant-Ressourcenzugriffen ist nicht ersetzbar. Für Kunden, die Wolf-Techs Code-Qualitätsberatung in Betracht ziehen, ist die Sicherheitsoberfläche immer das erste Deliverable.

Dimension 3: Testabdeckungs-Audit

Testsuiten in vibe-codierten Projekten laufen häufig mit 80-90% Coverage durch und bieten trotzdem kaum Schutz. Der Grund: KI-Assistenten schreiben Tests, die die gerade geschriebene Implementierung verifizieren, nicht das Verhalten, das das System haben soll.

Ein Test, der calculateTotal() aufruft und prüft, dass das Ergebnis dem Wert entspricht, den dieselbe Funktion mit denselben Eingaben zurückgibt, ist kein Test - er ist eine Tautologie. Wir sehen dieses Muster ständig. Die Coverage-Zahl ist echt; das Sicherheitsnetz ist es nicht.

Was ein echtes Testabdeckungs-Audit untersucht:

• Verhaltens- vs. strukturelle Abdeckung. Deckt die Testsuite die Geschäftsregeln ab - die Bedingungen, unter denen eine Zahlung erstattet wird, die Zustandsübergänge, die nicht passieren dürfen, die Invarianten, die die Domäne erzwingt? Oder deckt sie Codepfade ab?
• Randfall-Abdeckung. Leere Eingaben, Grenzwerte, Nebenläufigkeitsszenarien. KI testet tendenziell den Happy Path.
• Mutation-Testing-Scores. Ein Mutation-Testing-Tool (Infection für PHP, Stryker für JS/TS) zeigt, ob Tests Codeänderungen tatsächlich bemerken. Eine Suite, die durchläuft, nachdem ein Mutationstool 40% der Bedingungslogik verändert hat, schützt dich nicht.
• Integrations- vs. Unit-Mix. Vibe-codierte Projekte haben oft viele Unit-Tests und keine Integrationstests. Ein System kann perfekte Unit-Test-Abdeckung haben und komplett kaputtes Verhalten zwischen den Modulen.

Das Audit empfiehlt nicht, die Testsuite neu zu schreiben. Es identifiziert die konkreten Verhaltenslücken - die ungetesteten Geschäftsregeln und die Integrationsgrenzen ohne Abdeckung - und priorisiert sie nach Risiko.

Dimension 4: Dependency-Hygiene

KI-Assistenten lösen Abhängigkeiten optimistisch auf: die Version, auf der sie trainiert wurden, mit --save installiert, weiter im Text. Bis du auslieferst, hat sich die Dependency-Landschaft verändert.

Das Dependency-Audit umfasst:

• Verwaiste Pakete. Abhängigkeiten ohne Releases seit 18+ Monaten, von ihren Maintainern deprecated oder komplett durch ein anderes Paket abgelöst. KI-Assistenten mit Trainingsdaten von 2023-2024 empfehlen weiterhin Pakete, die inzwischen archiviert wurden.
• Doppelte Dependencies. Besonders in JavaScript-Projekten installieren KI-generierte Codebasen häufig mehrere Pakete für dieselbe Aufgabe - zwei HTTP-Clients, zwei Datumsbibliotheken, zwei Validierungsschemata - weil verschiedene KI-Sessions verschiedene Lösungen für dasselbe Problem gewählt haben.
• Bekannte Schwachstellen. npm audit und composer audit liefern die Basis; die manuelle Arbeit besteht darin zu bewerten, ob dein Code die verwundbaren Pfade tatsächlich nutzt.
• Lizenzkompatibilität. KI-Assistenten prüfen keine Lizenzen. Ein GPL-lizenziertes Paket in einem proprietären SaaS kann rechtliche Risiken erzeugen. Das kommt öfter vor, als die meisten Founder erwarten.

Dependency-Hygiene ist die am schnellsten zu behebende Dimension und bringt oft unmittelbare Performance-Gewinne, einfach durch das Entfernen doppelter Dependencies und den Ersatz verwaister Pakete durch gepflegte Alternativen.

Dimension 5: Strictness-Lücken bei TypeScript und PHPStan

KI-Assistenten schreiben Code voller Typ-Unterdrückungen, sobald Typen schwierig werden. Die verräterischen Zeichen:

In TypeScript: as any, @ts-ignore, as unknown as SomeType und breite catch (e: any)-Blöcke. Jede Unterdrückung ist eine Stelle, an der das Typsystem aufhört, dich zu schützen, und ein Laufzeitfehler möglich wird.

In PHP: @phpstan-ignore, mixed Return-Types, Arrays als untypisierte Datencontainer und nullable Returns auf Methoden, die laut Dokumentation immer einen Wert liefern.

Wir lassen PHPStan auf maximaler Strictness und TypeScript im Strict Mode laufen und behandeln jede Unterdrückung als Befund, der eine dokumentierte Begründung braucht. Manche Unterdrückungen sind legitim (Typen von Drittbibliotheken, die schlicht falsch sind); die meisten nicht. Das Verhältnis von unterdrückt zu begründet gibt dir ein grobes Maß dafür, wie viel Schutz das Typsystem dir tatsächlich bietet.

Diese Dimension deckt oft echte Bugs auf - Stellen, an denen ein KI-Assistent per Typ-Unterdrückung einen Typfehler zum Schweigen brachte, der korrekt auf ein Laufzeitproblem hinwies.

Dimension 6: Performance-Hotspots

Performance-Probleme in vibe-codierten Anwendungen fallen in drei Kategorien, alle vorhersehbar.

N+1-Queries sind am häufigsten. KI-Assistenten generieren sauber aussehenden ORM-Code, der Schleifen über Datenbankaufrufe versteckt. Eine Produktliste, die 50 Einträge lädt und 51 Queries absetzt, sieht in der Entwicklung gut aus und kriecht in Produktion. Wir profilen mit aktiviertem Query-Logging und suchen nach Query-Zahlen, die linear mit der Größe des Result-Sets skalieren.

Fehlende Datenbank-Indizes folgen naturgemäß aus Prompt-für-Prompt-Entwicklung. Die KI erstellt ein Tabellenschema und macht weiter. Wenn später eine Query gegen diese Tabelle geschrieben wird, schaut die KI nicht auf das Schema zurück - sie schreibt einfach die Query. Indizes werden selten ergänzt, wenn nicht explizit danach gefragt wird.

Synchrones I/O in asynchronen Pfaden ist ein PHP- und Node.js-Problem. Blockierende Aufrufe - synchrone Dateizugriffe, synchrone HTTP-Requests, Datenbankaufrufe in Event-Handlern - lassen den Durchsatz unter Last einbrechen, auf eine Weise, die erst sichtbar wird, wenn der Traffic kommt.

Wir erwarten zum Audit-Zeitpunkt keine Performance-Perfektion. Wir suchen die Probleme, die bei moderater Skalierung (100-1.000 gleichzeitige Nutzer) zu Ausfällen führen, denn genau die schlagen ohne Vorwarnung zu und erzwingen Notfall-Fixes zum denkbar schlechtesten Zeitpunkt.

Wenn die Codebasis Muster aufweist, die tiefere architektonische Eingriffe erfordern - starke Kopplung, keine Query-Optimierungsschicht, monolithischer Datenzugriff - kennzeichnen wir das separat unter Wolf-Techs Service zur Legacy-Code-Optimierung, da sich der Behebungspfad von einem Greenfield-Projekt unterscheidet.

Dimension 7: Operative Reife

Die letzte Dimension ist die, die Founder am konsequentesten übersehen: Kannst du das Ganze tatsächlich in Produktion betreiben?

Logging. KI-generierter Code hat oft gar kein strukturiertes Logging, oder inkonsistente console.log-Aufrufe quer über die Codebasis ohne Log-Level, ohne Correlation-IDs und ohne Möglichkeit, einen Request über mehrere Services zu verfolgen. Wenn um 2 Uhr nachts etwas bricht, brauchst du Logs, die dir sagen, was passiert ist - kein Rauschen.

Fehlerbehandlung. Unbehandelte Promise-Rejections, ungefangene Exceptions, verschluckte Fehler, die HTTP 200 mit leerem Body zurückgeben. KI-Assistenten generieren häufig Code, in dem Fehlerzustände technisch behandelt (der Fehler wird gefangen), aber nicht kommuniziert werden (der Nutzer sieht nichts, der Entwickler hört nichts).

Graceful Shutdown. Behandelt die Anwendung SIGTERM korrekt? Beendet sie laufende Requests vor dem Schließen? Leert sie Message-Queues? Cloud-Deployments starten Container ständig neu; ein Prozess, der nicht sauber herunterfahren kann, verliert bei jedem Deploy Requests.

Konfigurationsmanagement. Liegen alle umgebungsspezifischen Werte in Umgebungsvariablen? Gibt es einen Startup-Check, der laut fehlschlägt, wenn Pflichtkonfiguration fehlt, statt halb konfiguriert zu laufen und mysteriöses Verhalten zu produzieren?

Health-Checks. Stellt die Anwendung /health- oder /ready-Endpoints mit aussagekräftigem Status bereit? Testet der Health-Check tatsächlich die Datenbankverbindung, oder gibt er nur HTTP 200 zurück?

Operative Reife ist die Dimension, die entscheidet, ob du in der ersten Woche mit echtem Traffic schlafen kannst. Sie ist auch die Dimension, die KI-Assistenten schlicht überspringen - niemand hat sie danach gefragt.

Der Audit-Fragebogen

Vor Beginn eines Vibe-Code-Audit-Engagements schickt Wolf-Tech den Kunden einen kurzen Fragebogen. Die Antworten bestimmen, wo wir Zeit investieren:

1. Wie wurde die Codebasis erzeugt? (Ein KI-Assistent, mehrere Sessions, Mensch-KI-Hybrid?)
2. Wurde sie bereits in Produktion deployt? Falls ja, welche Ausfälle gab es schon?
3. Existiert eine Testsuite? Was zeigt der Coverage-Report?
4. Gibt es bekannte Performance-Probleme oder Skalierungssorgen?
5. Welche Features haben das höchste Risiko? (Zahlungen, Authentifizierung, Datenexport, Multi-Tenant-Datenisolation?)
6. Gibt es eine Sicherheitsanforderung von Kunde, Investor oder Regulierer, die dieses Review antreibt?

Die Antworten bestimmen die Audit-Reihenfolge. Eine Codebasis, die vor einer Series-A-Due-Diligence geprüft wird, bekommt Sicherheit und Architektur zuerst. Eine Codebasis mit bestehendem Performance-Vorfall bekommt Performance-Hotspots als erstes Deliverable. Eine Codebasis, die einen Enterprise-Sicherheitsfragebogen bestehen muss, bekommt einen Output, der direkt auf dessen Kategorien gemappt ist.

Priorisierungsrahmen für die Behebung

Nicht alles, was ein Vibe Code Audit findet, wird sofort behoben. Eine pragmatische Behebungsreihenfolge:

Sofort (vor Produktion): SQL-Injection und andere Injection-Schwachstellen, hartkodierte Zugangsdaten, Umgehungspfade der Authentifizierung, fehlende Tenant-Isolationschecks.

Innerhalb von zwei Wochen: CSRF-Lücken, fehlende Berechtigungsprüfungen auf sekundären Endpoints, verwaiste Dependencies mit bekannten CVEs, N+1-Queries auf Pfaden mit hohem Traffic.

Innerhalb eines Sprints: Typ-Unterdrückungen, die echte Bugs verbergen, fehlende Indizes auf Query-Pfaden zahlender Kunden, Fehlerbehandlungslücken in Zahlungs- und Authentifizierungsflüssen.

Geplante technische Schuld: Architektonische Inkonsistenzen, Testabdeckungslücken in unkritischen Bereichen, Verbesserungen der operativen Reife (strukturiertes Logging, Health-Checks, Graceful Shutdown).

Der Priorisierungsrahmen ist kein Freibrief, Sicherheitsprobleme aufzuschieben. Er ist ein Werkzeug, um Stakeholdern zu vermitteln, dass "wir haben Befunde" nicht "wir können nicht ausliefern" bedeutet. Die meisten vibe-codierten Codebasen, die dieses Audit durchlaufen, sind mit zwei bis vier Wochen gezielter Behebung der Sofort-Kategorie auslieferbar.

Wann du ein Vibe Code Audit beauftragen solltest

Der richtige Zeitpunkt ist, bevor du zahlende Kunden hast - bevor die Kosten der Behebung Reputationsrisiken, SLA-Verpflichtungen und die Ablenkung durch Brandbekämpfung in Produktion einschließen.

Der zweitbeste Zeitpunkt ist, wenn du zahlende Kunden hast, aber bevor du deinen ersten Enterprise-Kunden onboardest, dein erstes nennenswertes Zahlungsvolumen verarbeitest oder eine SOC-2-Zertifizierung beantragst.

Wenn du eine Codebasis hast, die substanziell KI-generiert wurde und sich einem dieser Meilensteine nähert, ist ein strukturiertes Vibe Code Audit der schnellste Weg, deine tatsächliche Risikoposition zu verstehen.

Um zu besprechen, wie ein Review-Engagement für deine konkrete Codebasis aussieht, schreib an hello@wolf-tech.io oder besuche wolf-tech.io.