KI-generierter Code gehört absolut in die Produktion, hinter demselben Sicherheitsgurt, den menschlicher Code immer brauchte: Review-Gates, Tests und ein benannter Owner für jede gemergte Zeile, und die Teams, die das als Verbieten-oder-YOLO-Binärfrage behandeln, begehen beide Kunstfehler. KI-Coding 2026 zu verbieten heißt, sich ohne Sicherheitsgewinn für langsameres Liefern als jeder Wettbewerber zu entscheiden, Ihre Engineers nutzen es ohnehin, nur heimlich und ohne Standards. Unreviewten KI-Output zu mergen ist dieselbe Fahrlässigkeit mit umgekehrtem Vorzeichen. Herkunft war nie die Qualitätsmesslatte. Verifikation ist es.
Warum beide Extreme scheitern
- Das Verbot: verspielt eine echte 2-5-fache Beschleunigung bei Routinecode, wird binnen Wochen umgangen und hinterlässt Ihnen unreviewten KI-Code plus eine Kultur des Versteckens, das Schlechteste aus jeder Welt.
- Der YOLO-Merge: Der Fehlermodus der KI ist flüssige Falschheit, Code, der korrekt liest, kompiliert und einen subtilen Logik- oder Security-Fehler einbettet. Masse plus Plausibilität ist genau die Kombination, die müde Reviewer besiegt.
- Beide Extreme teilen denselben Grundfehler: die Herkunft des Codes als Qualitätssignal zu behandeln, statt die Verifikation, die er durchlaufen hat.
Der Sicherheitsgurt, spezifiziert
- 1Benannte Ownership: Der mergende Engineer verantwortet den Code exakt so, als hätte er ihn getippt. Diese eine Regel verändert das Review-Verhalten mehr als jedes Tool.
- 2Echte Review-Gates: KI-assistierte PRs bekommen dieselbe Prüfung wie menschliche, mit Reviewern, die explizit auf die Fehlermodi flüssiger Falschheit gebrieft sind.
- 3Test-Untergrenzen: KI-generierter Code kommt mit Tests, idealerweise vom Menschen geschrieben oder zumindest verifiziert, die die Edge Cases abdecken, die KI notorisch überspringt.
- 4Evals für KI-Features: Wo KI Code schreibt, der selbst Modelle aufruft, gaten Eval-Sets das Deployment, Qualität ist eine Zahl, kein Gefühl.
- 5Herkunfts-Ehrlichkeit: Engineers markieren stark KI-generierte Änderungen, damit die Review-Aufmerksamkeit dorthin geht, wo das Risiko liegt. Kein Stigma, kein Verstecken.
So bleibt es haften
- Sprechen Sie die Policy laut aus: „Wir erwarten, dass Sie KI nutzen, und Sie verantworten, was Sie mergen.“ Ambiguität produziert Heimlichkeit; Klarheit produziert Standards.
- Trainieren Sie Reviewer auf KI-Fehlermuster: halluzinierte APIs, plausible-aber-falsche Logik, still übersprungene Fehlerbehandlung, leise geschwächte Security.
- Beobachten Sie die Frühindikatoren: Incident-Raten und Review-Tiefe, nicht KI-Nutzung. Steigende Nutzung bei flachen Incidents ist der Zielzustand.
- In Incident-Reviews wird „die KI hat es geschrieben“ identisch zu „ich weiß es nicht“ behandelt, als Signal, dass die Ownership-Regel versagt hat, nicht als Entschuldigung.