QA für KI-generierten Code: Was vor dem Launch bricht und wie man es abfängt

Ein KI-Prototyp aus Lovable, Cursor, Claude Code oder Replit bringt dich an einem Wochenende zu einer funktionierenden Demo. Er bringt dich nicht in Produktion. Die Lücke zwischen "läuft auf meinem Bildschirm" und "übersteht echte Nutzer, echte Last und ein Security-Review" ist genau dort, wo KI-generierter Code still versagt. Das ist der QA-Prozess, den wir bei KI-gestützten Builds fahren, bevor sie live gehen, und die Fehlermuster, die wir am häufigsten sehen.

Nichts davon ist ein Argument gegen das Bauen mit KI. Wir bauen auch damit. Es ist ein Argument dafür, den Output genauso zu testen wie jeden anderen Code, der gleich echtes Geld, echte Daten und echte Nutzer berührt.

Warum bricht KI-generierter Code in Produktion?

KI-Coding-Tools optimieren auf eine Sache: etwas zu produzieren, das läuft und zum Prompt passt. Sie optimieren nicht auf die Dinge, die entscheiden, ob Software den Kontakt mit Nutzern übersteht. Das Modell hat keinen Blick auf dein Threat-Model, deine Datenmengen, deine Edge-Cases oder deine Compliance-Pflichten. Es schreibt den Happy Path gut und überspringt fast alles andere, weil niemand danach gefragt hat.

Das Ergebnis ist Code, der sauber demonstriert und vorhersehbar bricht. Die Brüche sind nicht zufällig. Sie sammeln sich jedes Mal an denselben Stellen, und genau das macht sie testbar.

Was bricht tatsächlich an KI-generiertem Code?

Hier ist die Liste, die wir bei jedem KI-gestützten Build durchgehen, sortiert danach, wie oft es zubeißt.

• Lücken bei Authentifizierung und Autorisierung. Der Login-Screen funktioniert. Die Prüfung, die Nutzer A daran hindert, die Daten von Nutzer B zu lesen, fehlt oder läuft nur im Frontend. Das ist der mit Abstand häufigste schwere Defekt, den wir finden.
• Eingaben, die nie validiert werden. Formulare nehmen alles an. Keine Längenlimits, keine Typ-Checks, keine Sanitisierung. Die Demo-Daten waren sauber, also fiel die Lücke nie auf.
• Secrets am falschen Ort. API-Keys, Datenbank-URLs und Tokens hartkodiert im Client-Code oder ins Repo committet. KI-Tools schreiben sie inline, weil das Beispiel dann läuft.
• Kein Error-Handling. Der Happy Path ist abgedeckt. Ein fehlgeschlagener Netzwerkaufruf, ein Timeout oder ein leeres Ergebnis wirft eine unbehandelte Exception und der Screen wird weiß.
• Queries, die nicht skalieren. Code, der einen Datenbankaufruf in ein Render schleift oder eine ganze Tabelle zieht, um Zeilen zu zählen. Okay bei 10 Datensätzen, fatal bei 100.000.
• Race Conditions und Doppel-Submits. Zwei Klicks erzeugen zwei Bestellungen. Zwei parallele Requests bestehen beide eine Saldo-Prüfung und buchen beide ab.
• Dependencies, die niemand geprüft hat. Das Modell zieht Pakete herein, die veraltet, verwaist oder mit bekannten Schwachstellen behaftet sind.
• State, der lügt. Die UI sagt, die Zahlung sei erfolgreich; das Backend hat sie nie erfasst. Optimistische Updates ohne Abgleich.

"KI schreibt nicht absichtlich unsicheren Code. Sie schreibt den Code, nach dem du gefragt hast, und nichts, was du zu fragen vergessen hast. Produktion ist die Summe von allem, was du zu fragen vergessen hast."

Die Production-Readiness-Checkliste für KI-gestützte Builds

Das ist die Struktur eines Wavect-Reviews. Einen ersten Durchgang kannst du selbst machen, bevor du jemanden anrufst.

1. Autorisierungs-Audit. Für jeden Endpunkt und jeden Datenzugriff bestätigen, dass der Server prüft, wer fragt und ob es erlaubt ist. Frontend-Checks zählen nicht.
2. Eingabegrenzen-Test. Wirf fehlerhafte, übergroße und feindliche Eingaben an jeden Eintrittspunkt. Bestätige, dass sie sauber abgewiesen und nicht geschluckt werden.
3. Secret-Sweep. Repo und Client-Bundle nach Keys, Tokens und Credentials scannen. Alles Geleakte rotieren und serverseitig verlagern.
4. Fehlerpfad-Abdeckung. Jeden externen Aufruf zum Scheitern zwingen und bestätigen, dass die App sanft degradiert statt abzustürzen.
5. Last- und Query-Review. Die Datenbank unter realistischen Datenmengen profilen. N+1-Queries und unbegrenzte Reads killen, bevor sie dich killen.
6. Concurrency-Test. Parallele und doppelte Requests an alles feuern, das Geld oder State schreibt. Idempotenz ergänzen, wo sie fehlt.
7. Dependency- und Lizenz-Scan. Jedes Paket auf bekannte Schwachstellen und inkompatible Lizenzen prüfen.
8. Regressions-Suite. Die Tests schreiben, die der Prototyp nie hatte, damit die nächste KI-gestützte Änderung nicht still bricht, was schon funktioniert. Siehe testgetriebene Entwicklung dafür, warum das wichtiger wird, nicht weniger, wenn KI den Code schreibt.

Das ist der Kern unseres Software-QA-Service. Das Ergebnis ist kein PDF voller Beschwerden. Es ist eine reparierte, getestete Codebasis und die Test-Suite, die sie repariert hält.

Kann ich die KI einfach ihren eigenen Code reparieren lassen?

Teilweise. Ein KI-Tool ergänzt gern einen Validierungs-Check oder wickelt einen Aufruf in Error-Handling, sobald du auf die Stelle zeigst. Was es nicht kann, ist entscheiden, wo es hinschauen soll. Es hat kein Modell deiner technischen Schulden, keine Erinnerung an die Reihenfolge, in der Dinge gebaut wurden, und kein Gespür für den Edge-Case, den ein echter Nutzer an Tag zwei trifft. Die Lücken zu finden ist menschliche Arbeit. Sie zu schließen ist zunehmend geteilte Arbeit. Genau so fahren wir diese Engagements.

Wie lange dauert es, KI-generierten Code produktionsreif zu machen?

Für ein typisches Vibe-Coded-MVP läuft ein fokussierter Review- und Hardening-Durchgang ein bis drei Wochen. Die Streuung wird von zwei Dingen getrieben: wie viel echtes Geld oder sensible Daten das Produkt berührt, und wie weit die KI ohne Aufsicht gelaufen ist. Ein Wochenend-Prototyp, der Zahlungen und personenbezogene Daten verarbeitet, braucht mehr als ein Wochenende QA. Ein read-only internes Tool braucht weit weniger. Wir scopen es nach einem ersten Blick, nicht davor.

Wann ist der Code nicht mehr zu retten?

Selten, aber es kommt vor. Wenn das Datenmodell grundlegend falsch ist oder dasselbe kaputte Muster über hundert Dateien kopiert wurde, ist der Kern neu zu bauen billiger, als ihn zu flicken. Das sagen wir dir am ersten Telefonat, statt dir einen Monat dafür zu berechnen, ein Fundament zu flicken, das neu gegossen werden muss. Ehrlichkeit ist hier für alle billiger.