Sobald KI einen größeren Teil Ihres Codes schreibt, ist die CI-Pipeline die erste automatische Instanz, die standhalten muss. Menschliches Review stößt durch die schiere Menge an seine Grenzen, also verlagert sich mehr Last auf die Gates, die bei jeder Änderung greifen. Das Problem: Die meisten Pipelines wurden für eine Welt gebaut, in der ein Mensch den Code geschrieben und verstanden hat. KI bricht diese Annahme auf eine Weise, auf die Ihre bestehenden Gates nie ausgelegt waren.
Wir begleiten Entwicklungsteams dabei, ihre Pipelines für KI-gestützte Arbeit neu zu justieren, und das Muster wiederholt sich überall. Die alten Gates sind weiterhin wichtig, aber für sich allein wiegen sie in falscher Sicherheit. Denn KI ist ungewöhnlich gut darin, Code zu produzieren, der sauber durch die Gates kommt und trotzdem subtil falsch ist. Es geht nicht darum, mehr Gates aufzustellen. Es geht darum, die Gates so zu schärfen, dass sie genau die Fehler abfangen, die KI tatsächlich einschleppt.
Wie KI verändert, was die Pipeline abfangen muss
Drei Verschiebungen sind speziell für die CI entscheidend.
- Das Volumen steigt. Mehr Änderungen pro Tag laufen durch dieselbe Pipeline. Was sie übersieht, übersieht sie also nun viel häufiger.
- Der Feinschliff steigt. KI-Output ist sauber, einheitlich benannt und gut kommentiert. Style- und Lint-Gates passiert er mühelos, und genau das macht diese grünen Häkchen weniger aussagekräftig, als sie wirken.
- Die typischen Fehler verschieben sich. KI neigt zu ganz bestimmten Patzern: Tests, die bestehen, ohne wirklich etwas zu prüfen; plausibel klingende, aber falsche Lösungen für ein verwandtes Problem; neu generierte Logik, die längst Vorhandenes dupliziert; und überflüssige neue Abhängigkeiten. Eine Pipeline, die auf menschliche Fehler ausgelegt ist, fängt diese nicht von selbst ab.
Der rote Faden: KI ist sehr gut darin, Prüfungen zu bestehen. Genau deshalb müssen die Prüfungen die Substanz testen, nicht die Oberfläche.
Die Gates, die ihren Platz verdienen
Ordnen Sie jedem Gate einen konkreten KI-Fehler zu, den es abfangen soll. Fängt ein Gate nichts ab, was KI falsch macht, ist es Hygiene, keine echte Sicherheitskontrolle.
| Gate | KI-Fehler, den es abfängt | Warum es jetzt mehr wiegt |
|---|---|---|
| Testabdeckung mit Mutation Testing | Tests, die bestehen, ohne echtes Verhalten zu prüfen | KI schreibt für ihr Leben gern einen Test, der grün wird. Mutation Testing prüft, ob der Test bei fehlerhaftem Code überhaupt fehlschlagen würde. |
| Abhängigkeits- und Lizenz-Scan | Überflüssige oder ungeprüfte Pakete, Copyleft-Kontamination | KI bindet Abhängigkeiten und Patterns großzügig ein; das deckt auf, was sie hinzugefügt hat, ohne dass es jemand bewusst entschieden hätte. |
| Secret-Scanning | Hartcodierte Zugangsdaten im generierten Code | Modelle reproduzieren secret-artige Muster aus Training und Kontext; das gehört als hartes Gate konfiguriert, nicht als bloße Warnung. |
| Security-/SAST-Scanning | Plausibler Code mit echten Schwachstellen | Glatter Output verdeckt Injection-, Auth- und Datenverarbeitungslücken, die beim Lesen unauffällig wirken. |
| Duplikatserkennung | Neu generierte Logik statt Wiederverwendung des Vorhandenen | KI löst längst Gelöstes noch einmal; das macht den Wildwuchs sichtbar, bevor die Codebasis aufbläht. |
Achten Sie darauf, worauf es hier ankommt: nicht ob Tests vorhanden sind, sondern ob sie etwas beweisen. Der Abdeckungsgrad ist die Kennzahl, die KI am leichtesten austrickst, denn es ist trivial, einen Test zu erzeugen, der eine Zeile zwar ausführt, aber nicht prüft, was sie tut.
Die Gates, die trügerische Sicherheit geben
Manche Prüfungen fühlen sich nach Quality Gate an und sind es größtenteils nicht mehr, sobald KI im Spiel ist.
- Reiner Abdeckungsgrad. Eine Zahl, die steigt, während die Qualität der Prüfungen sinkt. Nutzen Sie sie als Mindestschwelle, nie als Beleg dafür, dass die Änderung getestet ist. Ohne Mutation Testing daneben führt sie Sie in die Irre.
- Bestandene Lint- und Format-Prüfung. KI-Output kommt hier mühelos durch. Ein grünes Lint-Häkchen sagt heute fast nichts mehr über Korrektheit aus; behandeln Sie es als Selbstverständlichkeit, nicht als Signal.
- „Die Tests sind grün.“ Der gefährlichste Punkt, weil er sich so endgültig anfühlt. Grüne Tests beweisen, dass die Tests durchgelaufen sind, nicht, dass sie bei falschem Verhalten fehlgeschlagen wären. Schreibt die KI die Tests, klafft diese Lücke weiter als je zuvor.
Nichts davon sollten Sie abschaffen. Stufen Sie es herab: notwendig, aber nicht hinreichend, und niemals das, was eine Änderung unbeobachtet durchwinkt.
Nach Risiko prüfen, nicht über einen Kamm
Jedes Gate bei jeder Änderung in voller Tiefe laufen zu lassen, ist der sichere Weg, die Pipeline selbst zum Engpass zu machen, also genau zu dem, was KI eigentlich auflösen sollte. Richten Sie die Tiefe der Gates danach aus, was die Änderung berührt.
| Änderungstyp | Berührt | Tiefe der Gates |
|---|---|---|
| Geringes Risiko | Doku, Tests, isolierte UI-Texte | Nur schnelle Gates; vertrauen und weitermachen |
| Standard | Feature-Code mit klar absehbarer Tragweite | Volle automatische Suite, normale Schwellen |
| Hohes Risiko | Auth, Zahlungen, Datenverarbeitung, Migrationen, öffentliche APIs | Volle Suite plus Mutation Testing, tieferes SAST, verpflichtendes menschliches Review |
Der Punkt ist, die langsamen, teuren Gates dort einzusetzen, wo ein Durchrutscher teuer wird. KI hebt das Volumen in jeder Zeile; in der Hochrisiko-Zeile richten schwache Gates aber echten Schaden an.
Das menschliche Gate behalten und gezielt ausrichten
Automatische Gates ersetzen kein Review; sie entscheiden, worauf das Review seine Aufmerksamkeit richten sollte. Die eigentliche Aufgabe der Pipeline ist es, die mechanischen Fragen abzuräumen (baut der Code, gibt es Secrets, prüfen die Tests wirklich etwas, ist etwas Neues hereingekommen), damit die prüfende Person ihre knappe Aufmerksamkeit der einen Frage widmen kann, die kein Gate beantwortet: *Löst das überhaupt das richtige Problem, und versteht jemand, warum es funktioniert?*
Wenn die CI das mechanische Prüfen sauber erledigt, wird das Review schneller und besser, weil die prüfende Person nicht mehr nach fehlenden Tests oder versprengten Secrets sucht. Sie liest auf die Absicht hin. Diese Arbeitsteilung ist der ganze Sinn der Sache.
Unsere Sicht
KI erlaubt es Ihnen nicht, Qualität zu automatisieren. Sie verändert, wonach die Automatisierung suchen muss. Die Pipeline, die funktionierte, als Menschen den Code schrieben und verstanden, gibt trügerische Sicherheit, sobald ein Modell ihn schreibt. Denn KI ist ungewöhnlich gut darin, Code zu produzieren, der grün ist und trotzdem falsch.
Justieren Sie die Gates auf die Fehler, die KI tatsächlich macht: Tests, die nichts prüfen, plausible, aber falsche Logik, eingeschleuste Abhängigkeiten, verborgene Schwachstellen. Und stufen Sie die Prüfungen, die KI mühelos besteht, von „Beleg“ auf „Hygiene“ herab. Prüfen Sie nach Risiko, damit die Pipeline nicht zum Engpass wird. Und behalten Sie die prüfende Person für die eine Frage, die keine Automatisierung beantworten kann.
Grünes CI sollte heißen: Die Änderung kann sicher gemergt werden. Mit KI stimmt das nur noch, wenn Ihre Gates die Substanz testen statt der Oberfläche. Genau das sicherzustellen, ist die eigentliche Arbeit.
Quellen
- DORA,
Accelerate State of DevOps, zu Change Failure Rate und Continuous Delivery, abgerufen am 2026-06-11 - OWASP,
OWASP Top 10 for Large Language Model Applications, abgerufen am 2026-06-11 - Google Engineering Practices,
Code Review Developer Guide, abgerufen am 2026-06-11
Häufige Fragen
- Welche Quality Gates sollte man für KI-generierten Code ergänzen?
- Gates, die KIs tatsächliche Fehlermodi fangen: Mutation Testing, um zu bestätigen, dass Tests bei falschem Code fehlschlagen würden, Abhängigkeits- und Lizenz-Scans für hereingezogene Pakete, Secret-Scanning für hartcodierte Zugangsdaten, SAST für plausiblen-aber-verwundbaren Code und Duplikatserkennung für Logik, die neu erzeugt statt wiederverwendet wurde.
- Bedeutet bestandene Tests, dass KI-generierter Code sicher ist?
- Nein. Grüne Tests beweisen, dass die Tests bestanden – nicht, dass sie bei falschem Verhalten fehlgeschlagen wären. KI ist sehr gut darin, einen Test zu produzieren, der grün wird, ohne etwas Echtes zuzusichern. „Die Tests sind grün“ ist also notwendig, aber nicht hinreichend. Koppeln Sie Abdeckung mit Mutation Testing, um zu prüfen, ob die Tests wirklich etwas beweisen.
- Warum ist Testabdeckung bei KI-generiertem Code irreführend?
- Abdeckung misst, welche Zeilen ein Test ausführt, nicht ob der Test prüft, was diese Zeilen tun. Es ist trivial für ein Modell, einen Test zu erzeugen, der eine Zeile ausführt, ohne ihr Verhalten zuzusichern – so kann die Abdeckung steigen, während die echte Testqualität fällt. Nutzen Sie sie als Untergrenze, nie als Beleg, dass eine Änderung getestet ist.
- Wie verhindert man, dass CI mit KI-Code zum Engpass wird?
- Gaten Sie nach Risiko statt einheitlich. Lassen Sie auf risikoarmen Änderungen wie Doku und isolierten UI-Texten nur schnelle Gates laufen, auf Standard-Feature-Code die volle automatische Suite und die tiefsten Gates – Mutation Testing, tieferes SAST, verpflichtendes menschliches Review – nur auf Hochrisiko-Änderungen an Auth, Zahlungen, Datenverarbeitung, Migrationen und öffentlichen APIs.
