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.

Die zitierten Prozentwerte stammen aus unterschiedlichen Datensätzen und Methoden von 2025-2026. Sie dürfen weder zu einem universellen Multiplikator noch zu einer Einsparzusage kombiniert werden. Erzeugungsdurchsatz, Verständnis, Review-Kapazität, Verifikationskapazität und Merge-Verantwortung sind getrennte Variablen. Reality Graph zeichnet Checks und Belege auf; es garantiert weder Review-Tempo noch Qualität oder Freigabe.