Der Review-Engpass

Jede Delivery-Pipeline hat genau eine engste Stelle. Jahrzehntelang war das das Schreiben des Codes, und die ganze Disziplin optimierte darum herum: Reviews waren schnell, weil Diffs klein waren, verfasst von einer Kollegin, deren Urteil man kannte, in einem Kontext, den man teilte. KI-Generierung hat die Schreib-Engstelle beseitigt – und die Engstelle tat, was Engstellen tun: Sie wanderte flussabwärts zur nächstknappsten Ressource, menschlichem Lesen und Urteilen.

Was diesen Engpass härter macht als eine normale Kapazitätsklemme: Das neue Volumen ist pro Einheit auch noch schwerer. 38 % der Entwickler sagen, das Review von KI-Code koste mehr Aufwand als das von Kollegen-Code – kein Autor zum Fragen, keine geteilte Absicht zum Anlehnen, subtilere Fehlermodi.

Das METR-Ergebnis verdient seinen Platz in dieser Tabelle: In einer randomisierten Studie waren erfahrene Open-Source-Entwickler 19 % langsamer mit KI-Unterstützung auf vertrauten Codebasen – bei gleichzeitig gefühlter Beschleunigung. Gefühltes und geliefertes Tempo divergieren, und die Differenz versteckt sich in genau der Prüfarbeit, um die es auf dieser Seite geht.

• Durchwinken. Freigaben fließen im alten Takt gegen das neue Volumen – was nur geht, wenn nicht wirklich gelesen wird. Das Review existiert als Ritual; Korrektheit shipped auf Vertrauen. Das ist Verification Debt in Maximalgeschwindigkeit, mit grünem Häkchen obendrauf.
• Stau-Kollaps. Reviews bleiben gründlich, also stauen sie sich. PRs warten Tage, Autoren bündeln mehr Änderungen pro PR (+51 % PR-Größe ist zum Teil genau das), und größere PRs sind schwerer zu reviewen – eine Rückkopplung, die damit endet, dass das Team langsamer ist als vor der KI.

Die meisten Teams pendeln zwischen beidem – deshalb sehen reine Durchsatz-Dashboards gut aus, während die Schulden-Kennzahlen kippen.

An einem Engpass, der mit dem Tooling skaliert, kann man nicht vorbei-hiren. Die Entlastung kommt daher, zu ändern, was den Reviewer erreicht:

1. Schriftlicher Auftrag pro Aufgabe – damit die Verifikation eine Referenz hat und der Reviewer aufhört, Anforderungen aus Diffs zu rekonstruieren (prüfbare Vorgaben).
2. Eine Maschinen-Phase vor der Menschen-Phase – Typen, Tests, Grenzen und der Soll-Abgleich laufen pro Änderung in der CI, damit menschliche Minuten Urteil kaufen statt Mechanik (Zwei-Phasen-Review).
3. Belege an jeder Änderung – der Reviewer liest, was verifiziert wurde, statt es nachzubauen.

Reality Graph greift den Engpass an der Ursache an: Jede Änderung kommt vorgeprüft an – gegen schriftlichen Auftrag und Grenzen abgeglichen, mit Validierung, die das Modell nicht verfasst hat, und einem Prüfbericht im Anhang – damit das menschliche Review wieder auf die Urteilsarbeit schrumpft, die nur Menschen können.