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

Ein KI-unterstützter Prototyp aus Lovable, Cursor, Claude Code, Replit oder einem anderen Tool kann schnell eine Demo erreichen. Produktionsreife hängt aber von vorgesehenen Nutzern, Daten, Exposition, Architektur und Evidenz ab. Die Lücke zwischen "läuft auf meinem Bildschirm" und "erfüllt definierte Qualitäts-, Sicherheits- und Betriebsanforderungen" muss verifiziert werden, statt aus der Codeherkunft abgeleitet zu werden. Dies ist ein risikobasierter QA-Prozess für KI-unterstützte Builds vor dem Release.

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.

KI-Prototyp ausgeliefert?

Production-Readiness-Review buchen

Warum kann KI-generierter Code in Produktion scheitern?

Ein Coding Assistant kennt nur die bereitgestellten Anforderungen und den verfügbaren Kontext. Sein Output kann unsichere Muster, erfundene Dependencies oder Annahmen enthalten, die nicht zum ausgelieferten System passen. Menschengeschriebener Code kann dieselben Fehlerklassen enthalten. Behandle generierten Code als nicht vertrauenswürdig, bis Architektur, Abhängigkeiten, Datenflüsse und Verhalten gegen explizite Anforderungen geprüft wurden.

Das Risiko hängt von Anwendung und Exposition ab. Nutze Threat Modeling und einen Verifikationsstandard, statt entweder Unsicherheit vorauszusetzen oder eine erfolgreiche Demo mit Produktionsreife gleichzusetzen.

Was bricht tatsächlich an KI-generiertem Code?

Dies sind verbreitete Prüffelder, keine gemessene Defektrangliste für alle KI-unterstützten Builds. Passe sie an System und Zielrisiko an.

Authentifizierung und Autorisierung. Teste Objekt-, Funktions-, Eigenschafts- und Tenant-Grenzen in vertrauenswürdigem serverseitigem Code. Ein funktionierender Login beweist nicht, dass Nutzer A keinen Zugriff auf Daten von Nutzer B hat.
Ein- und Ausgabehandling. Definiere Typen, Längen, Formate, Encodings, erlaubte Werte und Ablehnungsverhalten an jeder Vertrauensgrenze. Sanitisierung ist kontextspezifisch und kein universeller Ersatz für Validierung und sichere APIs.
Zugangsdaten und sensible Konfiguration. Prüfe Source, Historie, Build-Artefakte, Logs und Client-Bundles. Widerrufe oder rotiere offengelegte Zugangsdaten und verlagere privilegierte Operationen hinter vertrauenswürdige Grenzen.
Ausnahmebedingungen. Teste Timeouts, Teilausfälle, Retries, leere Ergebnisse, fehlerhafte Antworten, Ressourcenerschöpfung und Recovery, ohne sensible Details preiszugeben.
Performance und Ressourcenlimits. Profile repräsentative Datenmengen und Concurrency. Suche nach unbegrenzten Reads, wiederholten Queries, fehlenden Limits und teurer Arbeit durch nicht vertrauenswürdige Eingaben.
Concurrency und Replay. Teste doppelte und parallele Requests für zustandsändernde Operationen und erzwinge transaktionales oder idempotentes Verhalten, wo die Geschäftsregel es verlangt.
Dependencies und Build-Integrität. Inventarisiere direkte und transitive Komponenten, prüfe soweit möglich Paketidentität und Herkunft, unterstützte Versionen, Advisories und Lizenzpflichten.
Zustandsabgleich. Stelle sicher, dass sichtbarer Zustand dem maßgeblichen Backend-Zustand folgt und asynchrone oder fehlgeschlagene Operationen abgeglichen werden können.

"Der Generator ist nicht die Assurance-Grenze. Definiere das Ziel, prüfe das System, reproduziere wesentliche Findings und bewahre Evidenz auf, dass die Kontrollen funktionieren."

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

Dies ist die Struktur eines Wavect-Erstdurchgangs, geprüft am 2. September 2026. Sie ist kein vollständiger Testplan für jedes System. Wähle Kontrollen anhand von Architektur, Exposition, Threat Model, Regulierung und Servicelevel.

Autorisierungs-Audit. Bestätige für jede geschützte Operation und jeden Datenpfad, dass eine vertrauenswürdige serverseitige oder serverlose Grenze Akteur und Aktion prüft. Client-Checks können die UX unterstützen, sind aber keine Sicherheitsgrenze.
Eingabegrenzen-Test. Teste fehlerhafte, übergroße, feindliche und unerwartete Eingaben an relevanten Eintrittspunkten. Bestätige sichere Ablehnung oder Verarbeitung.
Secret-Sweep. Repo und Client-Bundle nach Keys, Tokens und Credentials scannen. Alles Geleakte rotieren und serverseitig verlagern.
Fehlerpfad-Abdeckung. Simuliere wesentliche externe Ausfälle und bestätige definiertes Retry-, Fallback-, Nutzerhinweis-, Logging- und Recovery-Verhalten.
Last- und Query-Review. Profile repräsentative Workloads und Datenmengen. Begrenze Reads und behebe wiederholte oder unerwartet teure Queries.
Concurrency-Test. Parallele und doppelte Requests an alles feuern, das Geld oder State schreibt. Idempotenz ergänzen, wo sie fehlt.
Dependency- und Lizenzprüfung. Nutze automatisches Inventar und Advisory-Checks und prüfe relevante Findings, Herkunft, Supportstatus und Lizenzpflichten. Ein Scanner beweist nicht, dass jede Dependency sicher oder kompatibel ist.
Regressionsevidenz. Ergänze angemessene automatisierte und manuelle Tests für kritisches Verhalten, damit spätere Änderungen gegen eine Baseline geprüft werden können. Testgetriebene Entwicklung ist eine Möglichkeit, ausführbare Erwartungen zu strukturieren.

Wenn KI beim Erstellen und Warten dieser Regressionstests helfen soll, braucht sie einen getrennten Assurance-Rahmen. Unser Pilotleitfaden zu agentischem Testen und Testautomatisierung zeigt, welche Aufgaben ein Agent übernehmen darf, welche Assertions deterministisch bleiben müssen und wie du 30 Tage misst.

Das ist der Kern unseres Software-QA-Service. Deliverables hängen vom Umfang ab und können Findings, reproduzierte Evidenz, Fixes, Tests, Deployment-Kontrollen und Hinweise zu Restrisiken enthalten. Kein Review beweist die Abwesenheit von Fehlern.

Kann ich die KI einfach ihren eigenen Code reparieren lassen?

Teilweise. KI-Tools können Tests und Fixes vorschlagen, ein Repository durchsuchen und über bereitgestellten Architektur- oder Issue-Kontext argumentieren. Sie können auch den Umfang verfehlen, Regressionen einführen, veraltetes Schwachstellenwissen nutzen oder eigene Annahmen bestätigen. Bewahre eine unabhängige Assurance-Grenze: Menschen verantworten Anforderungen und Risikoakzeptanz; generierte Findings und Patches brauchen reproduzierbare Tests und Review. Für einen engen Discovery-Schritt zeigt unser Cisco-Antares-Review zur lokalen CWE-basierten Schwachstellenlokalisierung, warum Kandidatendateien weiterhin einen Security Reviewer brauchen.

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

Es gibt keine belastbare universelle Dauer. Der Umfang hängt von Zielarchitektur, Code- und Testqualität, Daten, Exposition, Integrationen, Deployment, Regulierung, Spezialtests, Repository-Zugang und Remediation-Tiefe ab. Beginne mit einem begrenzten Review, nenne seine Grenzen und schätze Hardening erst nach der Evidenzsammlung.

Wann ist der Code nicht mehr zu retten?

Vergleiche Remediation und Ersatz, wenn Defekte systemisch sind, die Architektur Anforderungen nicht erfüllen kann, Dependencies nicht unterstützt werden oder Migrationsrisiken dominieren. Ein Rebuild ist nicht automatisch günstiger: Er bringt Risiken bei Feature-Parität, Migration, Cutover, Umschulung und neuen Defekten. Halte Annahmen, Optionen, Akzeptanzkriterien, Rollback und Restrisiko vor der Entscheidung fest.

Fazit

Leite Softwarequalität nicht daraus ab, ob Mensch oder Modell den ersten Entwurf schrieb. Definiere das Produktionsziel, mappe Vertrauensgrenzen und Dependencies, wähle risikobasierte Verifikation, reproduziere wesentliche Findings und bewahre Evidenz zu Fixes und Restrisiken auf.

Nutze diese Checkliste als Startpunkt, nicht als Zertifizierung. Systeme mit hoher Wirkung können tiefere Architekturprüfungen, Penetrationstests, Datenschutz- oder Sicherheitsbewertungen, Branchenspezialisten und Betriebsübungen verlangen. Release erst, wenn die Evidenz die für das reale System gesetzten Akzeptanzkriterien erfüllt.

KI-Prototyp ausgeliefert?

Production-Readiness-Review buchen

Primärquellen für den Verifikationsansatz

Diese Quellen stützen risikobasierte sichere Entwicklung und Verifikation. Sie belegen keine Defektraten für KI-generierten Code und zertifizieren keine konkrete Anwendung.