Quality Gates für AI-generierten Code

Wenn Code schneller entsteht, als er gelesen werden kann, verschiebt sich die Qualitätssicherung notgedrungen in die Automatisierung. Die Frage ist dann nicht mehr, ob Gates nötig sind, sondern welche – und wie sie schnell genug bleiben, dass niemand sie umgeht.

1. Warum Gates jetzt entscheiden

Ein Review, das früher implizit funktionierte, weil jemand über jede Zeile nachgedacht hatte, funktioniert bei generiertem Code nicht mehr auf dieselbe Weise. Menschliche Aufmerksamkeit ist die knappste Ressource im Prozess – sie sollte für Absicht, Architektur und Risiko reserviert bleiben. Alles Formalisierbare gehört in die Pipeline.

2. Der Minimalsatz

Diese Prüfungen sollten in jedem Projekt den Merge blockieren – unabhängig davon, wer oder was den Code erzeugt hat:

build            # compiles / packages, no errors
unit-tests       # deterministic, fast, no external services
contract-tests   # implementation still matches the published API contract
architecture     # module boundaries and dependency rules hold
lint + format    # no style discussion inside code review
sast             # static application security testing
dependency-scan  # known vulnerabilities and license policy
secret-scan      # no credentials in the diff

Bemerkenswert daran ist, wie wenig davon KI-spezifisch ist. Diese Liste ist schlicht das, was ein solider Entwicklungsprozess ohnehin haben sollte – KI macht aus „sollte“ ein „muss“.

3. Reihenfolge und Laufzeit

Die Reihenfolge entscheidet über die Akzeptanz. Billige, häufig scheiternde Prüfungen gehören nach vorne, damit Rückmeldung schnell kommt:

1. Sekunden: Format, Lint, Secret-Scan, Commit-Konvention.
2. Wenige Minuten: Build, Unit-Tests, Architektur- und Contract-Tests.
3. Vor dem Merge: Integrationstests, SAST, Dependency- und Lizenzprüfung.
4. Nach dem Merge: End-to-End, Last, tiefe Sicherheitsprüfungen.

Als Faustregel gilt: Rückmeldung auf einen Push innerhalb von zehn Minuten. Darüber beginnt Kontextwechsel – und mit ihm der Druck, Ausnahmen zu erlauben. Mehr dazu im Deep Dive CI/CD für AI-gestützte Softwareentwicklung.

4. Testqualität statt Coverage

Zeilenabdeckung ist bei generiertem Code ein besonders schwaches Signal: Sie ist mühelos hoch zu bekommen und sagt wenig über die Prüftiefe. Aussagekräftiger sind:

• Herkunft der Testfälle. Aus der Anforderung abgeleitet, nicht aus der frisch erzeugten Implementierung.
• Fehler- und Berechtigungspfade, nicht nur der Erfolgsfall.
• Grenzwerte und Randfälle – leer, null, maximal, gleichzeitig.
• Mutationstests für kritische Module, wo der Aufwand vertretbar ist: Sie messen, ob Tests Fehler tatsächlich bemerken.

Eine sinnvolle Gate-Regel ist deshalb nicht „85 % Coverage“, sondern: keine Verschlechterung gegenüber dem Zielzweig, plus verpflichtende Tests für neue öffentliche Schnittstellen.

5. Sicherheitsprüfungen

Drei Prüfungen decken den Großteil der praktisch relevanten Fälle ab:

• Secret-Scan auf dem Diff – der billigste Gate mit der höchsten Trefferquote.
• Statische Analyse mit einem auf das Projekt zugeschnittenen Regelsatz. Ein unkonfiguriertes Werkzeug erzeugt so viele Fehlmeldungen, dass es ignoriert wird.
• Abhängigkeitsprüfung auf bekannte Schwachstellen und Lizenzverträglichkeit.

Ergänzend lohnt eine explizite Prüfung der Autorisierungslogik im Review – das ist die Stelle, an der generierter Code am häufigsten zu kurz greift.

6. Abhängigkeiten und Lizenzen

Neue Abhängigkeiten sind bei generiertem Code häufiger als bei handgeschriebenem – und nicht immer die etablierten. Drei Regeln:

• Nur Pakete aus einer kuratierten Quelle oder einem internen Spiegel.
• Lizenz-Positivliste, automatisch geprüft.
• Neue Abhängigkeiten sichtbar machen – als eigener Hinweis im Merge Request, nicht versteckt im Lockfile-Diff.

7. Schwellenwerte festlegen

8. Ausnahmen ohne Dammbruch

Ausnahmen wird es geben – die Frage ist, ob sie sichtbar bleiben. Was funktioniert:

• Begründung im Repository, nicht im Chat.
• Ablaufdatum für jede Ausnahme, danach greift das Gate wieder.
• Freigabe durch eine zweite Person, nicht durch die einreichende.
• Regelmäßige Durchsicht der aktiven Ausnahmen – eine wachsende Liste ist ein Signal, kein Zustand.

9. Gates betreiben

Gates sind Software und altern entsprechend. Was zum Betrieb gehört: Regelsätze aktuell halten, Fehlmeldungen abbauen statt zu ignorieren, instabile Tests beheben oder entfernen, und die Laufzeit im Blick behalten. Ein Gate, dem niemand glaubt, ist schlimmer als keines – es kostet Zeit und erzeugt trotzdem keine Sicherheit.

Checkliste: Quality Gates

Fazit

Quality Gates sind der Punkt, an dem aus KI-Geschwindigkeit ausgelieferter Wert wird – oder eben nicht. Sie müssen nicht besonders raffiniert sein: Der Minimalsatz, schnell ausgeführt und verbindlich durchgesetzt, deckt den überwiegenden Teil ab.

Der Rest ist Betriebsdisziplin: Rauschen abbauen, Laufzeit kurz halten, Ausnahmen sichtbar machen. Ein Gate, das man umgehen muss, um Termine zu halten, wird umgangen – und dann ist es kein Gate mehr, sondern eine Verzögerung.