Code Review skaliert nicht mehr: die Rechnung, die nach jedem KI-Rollout aufgeht
Code zu erzeugen ist billig geworden. Ihn zu lesen nicht. Dieses eine verschobene Verhältnis erklärt fast alles, was Entwicklungsorganisationen seit dem Rollout von Assistenzsystemen erleben — und es erklärt auch, warum mehr Disziplin das Problem nicht löst.
Nach einem KI-Rollout steigt die Zahl der Änderungen, die Prüfkapazität bleibt gleich. Bei 60 Entwicklern mit 4 Änderungen pro Woche und 25 Minuten je ernsthaftem Review stehen 100 Stunden Prüfbedarf gegen 48 Stunden Kapazität. Kapazität proportional aufzustocken verbraucht den Produktivitätsgewinn; die Prüfung wegzulassen fällt erst im Betrieb auf, weil Überfliegen in der Statistik wie Prüfen aussieht. Der dritte Weg prüft Eigenschaften statt Zeilen zu lesen.
Die Rechnung
Sechzig Entwicklerinnen und Entwickler, vier Änderungen pro Person und Woche: zweihundertvierzig Änderungen. Bei fünfundzwanzig Minuten für ein Review, in dem man die Änderung wirklich versteht, sind das hundert Stunden Prüfbedarf. Sechs Reviewer mit acht Stunden Reviewzeit pro Woche haben achtundvierzig. Zweiundfünfzig Stunden fehlen, jede Woche, und die Zahl steigt mit jedem weiteren Prozent Produktivitätsgewinn.
Ausweg eins: aufstocken
Man kann die Prüfkapazität proportional mitwachsen lassen. Dann ist der Produktivitätsgewinn genau dort wieder verbraucht, wo er entstanden ist — nur mit dem Unterschied, dass jetzt mehr Menschen Code lesen statt ihn zu schreiben. Für Organisationen, die Assistenzsysteme wegen des Fachkräftemangels eingeführt haben, ist das keine Option.
Ausweg zwei: weglassen
Man kann die Prüfung faktisch aufgeben und formal beibehalten. Das passiert meistens von selbst: Bei zwanzig Zeilen liest man, bei achthundert überfliegt man, und ab einem gewissen Volumen hört man auf, sich das einzugestehen. Der Haken im Werkzeug sieht danach genauso aus wie vorher, die Statistik zeigt hundert Prozent Reviewquote, und der Unterschied fällt erst im Betrieb auf.
Der dritte Weg
Die Frage, die ein Review beantworten soll, ist nicht „sieht dieser Code aus, wie ich ihn geschrieben hätte", sondern „tut die Software, was sie soll — fachlich richtig, sicher, schnell genug". Für jede dieser Fragen gibt es Methoden, die sie besser beantworten als ein Mensch, der Zeilen liest: Eigenschaftstests statt Beispieltests, Vertragstests an den Schnittstellen, Abhängigkeits- und Lizenzprüfung bei jedem Build, Performance-Budgets als Gate, Architekturregeln als ausführbarer Test.
Was mit den Menschen passiert
Sie werden nicht überflüssig, sie werden verschoben. Weg vom Zeilenlesen, hin zu der Frage, welche Eigenschaften überhaupt gelten müssen — und zu den Entscheidungen, die kein Test treffen kann: wo die Modulgrenze verläuft, ob eine fachliche Regel so stimmt, welches Risiko tragbar ist. Das ist die Arbeit, für die man Ingenieure eingestellt hat.
Häufige Fragen
Ist Code Review damit überflüssig?
Nein, aber es ist nicht mehr die Hauptkontrolle. Menschliche Prüfung bleibt dort, wo ein Fehler teuer ist und wo eine Entscheidung getroffen werden muss, die kein Test treffen kann. Für den Rest übernehmen automatische Prüfmechanismen — und zwar auf jeder Änderung statt stichprobenartig.
Wie merkt man, dass der Review zum Durchwinken geworden ist?
An der Größe der Änderungen im Verhältnis zur Reviewdauer. Wenn Pull Requests mit mehreren hundert Zeilen im Schnitt in wenigen Minuten freigegeben werden, ist die Frage beantwortet. Diese Zahl steht in jedem gängigen Werkzeug und wird selten ausgewertet.
Reicht es nicht, kleinere Pull Requests zu verlangen?
Kleinere Änderungen helfen, lösen die Rechnung aber nicht: Bei gleicher Gesamtmenge steigt nur ihre Anzahl. Der Aufwand pro Zeile sinkt etwas, der Gesamtaufwand bleibt in derselben Größenordnung.
Was ist der erste Schritt?
Die eigene Rechnung aufmachen: Änderungen pro Woche, Reviewer, tatsächlich verfügbare Reviewstunden, Minuten je ernsthaftem Review. Erst danach über Werkzeuge sprechen — die Reihenfolge entscheidet, ob man ein Problem löst oder ein Produkt kauft.
Rechnen Sie Ihre Review-Lücke aus.
Vierzehn Fragen, fünf Minuten. Ihre Zahlen, kein Login.
Engineering-Check starten →
