Wenn Teams KI-Coding-Tools einführen, ändert sich als Erstes nicht der Code. Es ändert sich die Menge an Code, die zum Review eintrifft.
Wer früher vier Pull Requests am Tag gesehen hat, sieht jetzt zehn. Und jeder davon wirkt fertig. Der Diff ist sauber, die Tests sind grün, die Beschreibung ist gut geschrieben. Alles sagt „bereit zum Merge“. Und genau hier erodiert die Qualität, ohne dass es jemand merkt.
Wir begleiten Entwicklungsteams durch diesen Übergang, und das Bild ist immer dasselbe. KI senkt die Qualität einer einzelnen Änderung kaum. Sie erhöht das Tempo, mit dem Änderungen eintreffen, und sie lässt jede einzelne vertrauenswürdiger aussehen, als die Prüfung dahinter es rechtfertigt. Review wird zur einzigen Kontrolle zwischen mehr Output und einer langsameren, fragileren Codebasis.
Die Frage, die uns interessiert, ist deshalb nicht „soll KI Code schreiben“. Sie lautet: Wie hält Review das Niveau, wenn mehr davon eintrifft und alles gut aussieht?
Warum gerade das Review sich verändert
Drei Dinge verschieben sich auf einmal.
- Das Volumen steigt. Mehr Änderungen pro Reviewer und Tag, bei gleicher Zahl an Reviewern.
- Der äußere Feinschliff nimmt zu. KI-Output wirkt souverän. Die Benennung ist konsistent, Kommentare sind da, die Struktur sieht durchdacht aus.
- Der Kontext beim Autor sinkt. Wer Code selbst schreibt, hat ein Bild davon im Kopf, warum jede Zeile existiert. Wer ihn von einem Modell schreiben lässt und dann übernimmt, hat dieses Bild nur in dünner Form. Der Autor kann erklären, was der Code tut, aber nicht immer, warum genau das die richtige Lösung ist.
Der letzte Punkt ist der gefährliche. Review hat sich immer darauf verlassen, dass der Autor seine eigene Änderung versteht. KI untergräbt diese Annahme, ohne es anzukündigen.
Der typische Fehler, den wir am häufigsten sehen
Das häufigste Problem ist nicht, dass schlechter Code durchrutscht, sondern dass das Review zur reinen Durchsatzübung verkommt.
Wenn zehn polierte PRs warten, tut jemand unter Zeitdruck das Naheliegende: prüfen, dass es läuft, den Rest überfliegen, freigeben. Auf dem Papier hat das Review stattgefunden. In der Sache nicht. Niemand hat beschlossen, dass das so falsch ist. Die Anreize haben den oberflächlichen Weg schlicht zum bequemsten gemacht.
Der gegenteilige Fehler kostet genauso viel: Review wird zum Engpass. Reviewer nehmen sich jede Zeile jeder KI-Änderung vor, als hätten sie selbst nichts beigetragen, und die Warteschlange staut sich, bis die Geschwindigkeit, die KI eigentlich bringen sollte, in Wartezeit verpufft.
Beide Fehler kommen aus derselben Wurzel: Das Team hat seinen alten Review-Prozess beibehalten und ihn einfach auf mehr Code losgelassen.
Mehr beim Autor verlangen, nicht beim Reviewer
Den größten Hebel hat man vor dem Review. Wer eine KI-gestützte Änderung einreicht, sollte zum Review schon die Arbeit erledigt haben, die dem Modell nicht zu überlassen ist.
Konkret bitten wir Autoren darum,
- jede Zeile, die sie einreichen, zu lesen und zu verstehen, und erklären zu können, warum sie da ist, nicht nur, was sie tut
- die PR-Beschreibung selbst zu schreiben und darin Absicht und Risiko zu benennen, statt eine vom Modell erzeugte Zusammenfassung hineinzukopieren
- die Stellen zu markieren, bei denen sie am unsichersten sind, damit der Reviewer seine Aufmerksamkeit dorthin lenkt, wo sie gebraucht wird
- die Tests laufen zu lassen und zu lesen, auch mit Blick darauf, ob die Tests das neue Verhalten wirklich abdecken oder nur grün werden
Das ist keine Bürokratie. Es stellt die Annahme wieder her, von der Review lebt: dass ein Mensch diese Änderung verantwortet und versteht. Eine Änderung, deren Autor sie sichtlich verstanden hat, geht ein Reviewer zügig durch. Bei einer, die niemand verstanden hat, geht das nicht ohne Risiko.
Review-Aufmerksamkeit nach Risiko steuern, nicht nach Zeilenzahl
Bei höherem Volumen scheitert man genau daran, alle Änderungen gleich zu behandeln. Die Lösung: den Review-Aufwand nach Risiko verteilen.
| Änderungstyp | Was sie berührt | Review-Tiefe |
|---|---|---|
| Geringes Risiko | Tests, Doku, isolierte UI-Texte, interne Tools | Leicht, schnell, dem Autor vertrauen |
| Standard | Feature-Code mit klarem Wirkungsbereich | Normales Review, Fokus auf Absicht und Randfälle |
| Hohes Risiko | Auth, Zahlungen, Datenverarbeitung, Migrationen, öffentliche APIs | Tiefes Review, eine namentlich benannte zweite Person, kein Zeitdruck |
Es geht darum, die knappe Kapazität für tiefes Review dort einzusetzen, wo ein Fehler teuer wird, und sie nicht mehr gleichmäßig zu verstreuen. KI erhöht das Volumen in allen drei Zeilen, aber die Hochrisiko-Zeile ist die, in der oberflächliches Review wirklich wehtut.
Was der Reviewer bei KI-Änderungen weiterhin prüfen sollte
Für alles oberhalb von geringem Risiko soll die Checkliste des Reviewers gezielt das benennen, was KI leicht durchgehen lässt:
- Löst das wirklich das richtige Problem, oder ein plausibles benachbartes, zu dem das Modell abgedriftet ist?
- Gibt es Randfälle, die der Happy-Path-Code und die Happy-Path-Tests beide überspringen?
- Hat die Änderung eine Abhängigkeit, ein Muster oder eine Abstraktion eingeschleppt, die die Codebasis gar nicht brauchte?
- Gibt es doppelte Logik, die das Modell neu erzeugt hat, statt Vorhandenes wiederzuverwenden?
- Prüfen die Tests echtes Verhalten, oder bestätigen sie nur, dass der Code tut, was er tut?
Gerade die letzte Sorte, Tests, die durchlaufen, ohne etwas zu beweisen, sehen wir in KI-gestützter Arbeit deutlich häufiger. Ein Modell ist sehr gut darin, einen Test zu erzeugen, der grün wird. Weniger verlässlich ist es darin, einen zu erzeugen, der fehlschlagen würde, wenn das Verhalten falsch wäre.
Das Review-System messen, nicht nur den Code
Sobald das Volumen oben ist, lässt sich das nicht mehr aus dem Bauch steuern. Ein paar Signale zeigen Ihnen, ob das Review noch trägt.
| Signal | Was es Ihnen sagt |
|---|---|
| Review-Zeit pro Änderung, nach Risikostufe | Ob tiefes Review tatsächlich dort stattfindet, wo es soll |
| Change-Failure-Rate (Defekte, Rollbacks) | Ob oberflächliches Review Probleme bis in die Produktion durchlässt |
| Verweildauer in der Review-Warteschlange | Ob Review stattdessen selbst zum Engpass geworden ist |
| Anteil der PRs mit vom Autor formulierter Absicht | Ob die vorgelagerte Disziplin echt ist oder übersprungen wird |
Steigen Failure-Rate und Review-Warteschlange beide, ist das System überlastet. Steigt die Failure-Rate, während die Review-Zeit sinkt, wird nur noch abgenickt. Beide zusammen sagen mehr aus als jedes Signal für sich.
Damit hängt ein grundsätzlicher Punkt zur Einführung zusammen: Geschwindigkeit ist nur dann ein echter Gewinn, wenn die Qualität hält. Ein Team, das doppelt so schnell liefert und doppelt so oft zurückrollen muss, hat nichts gewonnen außer Stress.
Unsere Sicht
KI-gestütztes Coding macht Review nicht überflüssig. Es rückt Review ins Zentrum dessen, wie über Qualität entschieden wird, und erschwert es zugleich, weil es schwache Änderungen hinter einer polierten Oberfläche versteckt.
Teams, die das gut hinbekommen, ändern drei Dinge, nicht eines. Sie schieben das Verstehen zurück auf den Autor, damit Review von einer Änderung ausgeht, die wirklich jemand verantwortet. Sie steuern die Review-Tiefe nach Risiko, damit knappe Aufmerksamkeit dort landet, wo Fehler teuer sind. Und sie messen das Review-System selbst, damit sie den Unterschied zwischen „schnell und in Ordnung“ und „schnell und fragil“ erkennen, bevor die Produktion ihn ihnen zeigt.
Nichts davon braucht ein neues Tool. Es braucht die bewusste Entscheidung, dass der Anspruch nicht sinkt, nur weil das Volumen gestiegen ist.
Quellen
- Google Engineering Practices,
Code Review Developer Guide, abgerufen am 2026-06-10 - DORA,
Accelerate State of DevOps, zu Change-Failure-Rate und Lieferleistung, abgerufen am 2026-06-10 - OWASP,
OWASP Top 10 for Large Language Model Applications, abgerufen am 2026-06-10
</content> </invoke>
Häufige Fragen
- Warum wird Code-Review durch KI-gestütztes Coding schwieriger statt einfacher?
- KI erhöht das Tempo, mit dem Änderungen eintreffen, und lässt jede einzelne vertrauenswürdiger aussehen, als die Prüfung dahinter es rechtfertigt. Der entscheidende Punkt: Der Kontext beim Autor sinkt. Wer Code vom Modell schreiben lässt und ihn dann übernimmt, kann erklären, was der Code tut, aber nicht immer, warum genau das die richtige Lösung ist — und genau darauf hat Review sich immer verlassen.
- Wie verhindert man, dass Code-Review bei steigendem PR-Volumen zum Engpass wird?
- Indem man den Review-Aufwand nach Risiko verteilt, nicht nach Zeilenzahl. Änderungen mit geringem Risiko — Tests, Doku, isolierte UI-Texte, interne Tools — können schnell und mit wenig Tiefe durchlaufen. Hochrisiko-Änderungen in Bereichen wie Auth, Zahlungen, Datenverarbeitung oder öffentlichen APIs brauchen tiefes Review, eine namentlich benannte zweite Person und keinen Zeitdruck. Gleichzeitig muss mehr Verantwortung auf den Autor verlagert werden: Wer eine KI-gestützte Änderung einreicht, sollte jede Zeile verstanden haben und die Absicht selbst formulieren können.
- Woran erkennt man, ob das Team bei KI-generiertem Code nur noch abnickt statt wirklich zu prüfen?
- Zwei Signale zusammen sind aussagekräftig: Steigt die Change-Failure-Rate (Defekte, Rollbacks), während die Review-Zeit sinkt, wird nur noch abgenickt. Steigen hingegen Failure-Rate und Review-Warteschlange gleichzeitig, ist das System überlastet. Ergänzend zeigt der Anteil der PRs mit einer vom Autor selbst formulierten Absicht, ob die vorgelagerte Disziplin wirklich gelebt wird.
- Welche Aspekte von KI-generiertem Code übersehen Reviewer am häufigsten?
- Besonders häufig werden Tests nicht hinterfragt: Ein Modell erzeugt gut Tests, die grün werden, aber nicht unbedingt solche, die fehlschlagen würden, wenn das Verhalten falsch wäre. Daneben driftet KI leicht zu einem plausiblen, aber falschen Problem hin, schleppt unbenötigte Abhängigkeiten oder Abstraktionen ein und regeneriert doppelte Logik statt Vorhandenes wiederzuverwenden. Die Reviewer-Checkliste sollte genau diese Punkte explizit benennen.
