KI-Code-Review-Tools haben den Engpass verschoben, nicht entfernt
KI-Code-Review-Tools sollten die Zeit zwischen dem Öffnen eines Pull Requests und dem Mergen drastisch verkürzen. Für einen begrenzten Satz an Prüfungen haben sie das geschafft. Aber bei der Kernaufgabe eines Reviewers — zu entscheiden, ob eine Änderung tatsächlich korrekt und sicher ist — berichten die meisten Teams, die diese Tools im großen Maßstab einsetzen, dass sie einen Engpass gegen einen anderen getauscht haben: Die Zeit, die früher mit dem Lesen eines Diffs verbracht wurde, wird jetzt damit verbracht, zu entscheiden, welche Bot-Kommentare es wert sind, gelesen zu werden.
Die Akzeptanz hat die Wirksamkeitsnachweise überholt
Die Stack-Overflow-Entwicklerbefragung 2025 ergab, dass 47% der professionellen Entwickler im Vorjahr KI-gestützte Code-Review genutzt hatten. Die JetBrains-Umfrage desselben Zyklus kam auf 44%. Diese Zahlen stiegen schnell — beide Umfragen zeigten gegenüber zwei Jahren zuvor etwa eine Verdopplung. Die Akzeptanz ist, mit anderen Worten, nicht mehr die interessante Frage. Ob die Tools tatsächlich die wichtigen Bugs erkennen, ohne sie im Rauschen zu begraben, ist es.
Das Problem der Falsch-Positiven ist real, und Anbieterzahlen sollten skeptisch gelesen werden
Ein Benchmark von Signal65 aus dem März 2026, der fünf kommerzielle Review-Tools gegen echte historische Bugs in sechs Open-Source-Repositories testete, schrieb CodeRabbit eine Präzision von 95,88% zu. Diese Zahl stammt aus einer vom Anbieter beauftragten Studie und sollte entsprechend gewichtet werden — Präzisionswerte aus Benchmarks, die um die Stärken eines einzelnen Sponsors herum entworfen wurden, überleben selten den Kontakt mit einer unabhängigen Codebasis.
Von Entwicklern verfasste Berichte erzählen eine chaotischere Geschichte. Unabhängige Berichte, die unter Engineering-Teams kursieren, beschreiben unkonfigurierte KI-Review-Tools mit Falsch-Positiv-Raten von 15 bis 25 Prozent bei typischen Pull Requests, die erst nach wochenlanger Anpassung des Tools an die jeweilige Codebasis, den Styleguide und bekannte sichere Muster auf etwa 7 bis 12 Prozent sinken. Diese Anpassungskosten sind der Teil, den Anbieter-Pitches gerne auslassen.
Wo die Tools wirklich funktionieren
Die klarsten Erfolge sind eng gefasst und mechanisch: das Markieren fest codierter Geheimnisse, das Erkennen von SQL-Injection-Mustern, die Durchsetzung eines Styleguides und das Aufspüren der spezifischen Kategorie von Nullzeiger- und Off-by-One-Fehlern, die ständig in Diffs auftauchen. Das sind Mustererkennungsprobleme, und LLM-basierte Tools sind gut darin, Muster über den gesamten Kontext eines Diffs hinweg abzugleichen, auf eine Weise, die ein Linter nicht kann.
Die klarsten Fehlschläge liegen bei Ermessensentscheidungen — ob eine Änderung tatsächlich den zugrunde liegenden Bug behebt oder nur ein Symptom überdeckt, ob eine neue Abhängigkeit ein vernünftiger Kompromiss ist, ob ein Refactoring ein Verhalten bewahrt, das nicht von Tests abgedeckt ist. Das erfordert ein Verständnis der Absicht, und Absicht ist genau das, was ein Diff, losgelöst von dem Gespräch, das es erzeugt hat, einem Modell nicht zuverlässig vermittelt — genauso wenig wie einem Menschen, der zu schnell überfliegt.
Was den Engpass tatsächlich reduziert
Teams, die eine netto Zeitersparnis berichten und keinen bloßen Austausch, teilen einige Praktiken. Erstens begrenzen sie den KI-Reviewer auf eine feste Kategorie von Prüfungen — Sicherheitsmuster, Stil und bekannte Bug-Klassen — statt ihn um eine breite Korrektheitsprüfung zu bitten. Zweitens behandeln sie den ersten Monat der Einführung als Anpassungszeitraum, indem sie Falsch-Positive zurückmelden, bis die Rauschrate sinkt, statt sofortige Präzision zu erwarten. Drittens, und am häufigsten genannt, behalten sie bei allem, was Authentifizierung, Zahlungen oder Datenlöschung betrifft, einen Menschen als letzte Freigabeinstanz, unabhängig davon, was der KI-Reviewer sagt, weil das die Kategorien sind, in denen ein falsch Negatives teuer genug ist, um die Kosten der zusätzlichen Prüfung zu rechtfertigen.
Das Muster bei allen drei Praktiken ist dasselbe: KI-Code-Review funktioniert als Filter, der einschränkt, was ein Mensch sorgfältig betrachten muss, nicht als Ersatz für diesen letzten Blick. Teams, die es mit der gegenteiligen Erwartung einführten, sind diejenigen, die jetzt berichten, dass die Review genauso lange dauert wie zuvor — die Zeit hat sich nur vom Lesen des Codes zum Lesen des Bots verschoben.