Bei Imprint dauert ein durchschnittlicher Pull-Request-Review heute 77 Minuten. Vor zwei Jahren lag der Median bei 33 Minuten. Die Zahl stammt aus einem Erfahrungsbericht des Unternehmens und zeigt einen neuen Engpass. Laut Will Larson mergt ein durchschnittlicher Engineer heute viermal so viele Pull Requests wie vor zwei Jahren, einzelne Teams zehnmal so viele; ein Engineer erreicht das 25-Fache des damaligen Durchschnitts. Gleichzeitig seien die Incidents um 42 Prozent gesunken, kritische Incidents um 78 Prozent, halbjährlich verglichen. Mehr Tempo bei besserer Softwarequalität also. Umso auffälliger ist die zweite Zahl: Die Review-Dauer ist nicht gesunken, sondern von 33 auf 77 Minuten gestiegen. Wer code review beschleunigen will, trifft hier auf ein Systemproblem, nicht auf mangelnde Motivation.
Warum die Merge-Rate steigt und Reviews zum Engpass werden
Die Merge-Rate ist im Bericht kein Selbstzweck. Sie zeigt, dass mehr Arbeit in kleineren Einheiten durch das System läuft. Will Larson nennt den Zusammenhang zwischen steigender Pull-Request-Zahl und längerer Review-Dauer eng. Die Mechanik ist einfach: Jede zusätzliche Änderung braucht einen Blick. Wächst die Zahl der Änderungen schneller als die Zahl der prüfenden Menschen, wird der Review zum Engpass. Naheliegend wäre, Review wegzulassen oder abzukürzen. Der Bericht verlagert die Prüfung stattdessen dorthin, wo sie automatisiert, regelbasiert oder wenigstens risikogerecht möglich ist. Geschwindigkeit in der Softwareentwicklung heißt dann nicht schneller tippen, sondern die Arbeit zwischen Mensch und System besser teilen.
Vier Gründe, warum Pull Requests überhaupt reviewt werden
Will Larson nennt vier Gründe für Reviews: Wissensaustausch, Fehlervermeidung, Schutz vor böswilligem Verhalten und Compliance. Wissensaustausch beschreibt er als apprenticeship, als Lernen am Beispiel erfahrener Engineers. Bei der aktuellen Menge müsse das eher über Cluster von Pull Requests laufen als über einzelne Änderungen. Fehler findet Review ohnehin spät; effektive CICD und Harness-Verfahren wie pstack hält er für wirksamer. Böswilliges Verhalten erkennt auch sorgfältiger Review selten, wenn es kompetent ausgeführt ist. Hier setzt der Bericht auf feste Regeln, Anti-Abuse-Mechanismen, Auditing und Audit-Logs. Für Compliance bleiben dokumentierte Kontrollen und unabhängige menschliche Prüfungen in einem Teil der Repositories vorerst bestehen. Review ist damit eine Kontrollschicht unter mehreren, keine Sonderrolle.
Was bei Imprint als small-change gilt
Das small-change-Konzept setzt dort an: CICD prüft, ob ein Pull Request die Kriterien erfüllt, und zeigt das Ergebnis als GitHub-Check. Ein Label dient nur der Sichtbarkeit; der Check bleibt unabhängig und nicht manuell veränderbar. Als small-change gilt eine Änderung nur, wenn sie unter 1.000 Codezeilen bleibt, keine p1- oder p2-Befunde des automatisierten Review-Bots ai-code-review hat und Larson mindestens zehn zuvor gemergte Pull Requests in den betroffenen Verzeichnissen vorweisen kann. Bei Änderungen über mehrere Services muss diese Erfahrung für alle beteiligten Services gelten. Außerdem darf die Änderung nur wenige Services betreffen: einen im Frontend-Monorepo und bis zu drei im Backend-Monorepo.
Shared Libraries und zentrale Utility-Dateien sind ausgenommen. Eine .small_change-Datei erlaubt pro Pfad Ausnahmen, etwa für Services mit Geldbewegungen. So entsteht ein risikobasierter Filter: nicht jede Änderung wird gleich behandelt, einfache Fälle werden sichtbar von heiklen getrennt. Beim code review verschwindet die Prüfung damit nicht. Ihre Intensität hängt am Risiko.
Operativ ergänzt Imprint den Filter durch Slack-Automatisierung: Jeder Pull-Request-Verweis bekommt eine Reaktion, die den Status anzeigt; eine eigene small-change-Reaktion markiert die Kandidaten. In einem internen Skills-Repository liegen zwei Werkzeuge: review-small-change prüft offene, nicht als Draft markierte small-changes und gibt bei Erfolg eine Freigabe, aber niemals einen Kommentar; review-pr-cluster betrachtet Stapel von Pull Requests und sucht nach gemeinsamen Themen. Die Freigabe ist bewusst binär: approven oder ignorieren. So soll die von Imprint so genannte „meat proxy review“ nicht befeuert werden. Zusätzlich gilt die soziale Regel, dass ein Fehler, der durch einen small-change entsteht, ein Systemfehler ist und in ai-code-review, CICD, Harness oder Verifikation behoben werden muss. Die Einführung habe etwa zwei Tage sporadischer Aufmerksamkeit gekostet; die Feinjustierung werde deutlich länger dauern.
Automatisierte Code-Review und die Grenzen von Meat-Proxy-Review
„Meat proxy review“ beschreibt Larson als Muster, das zunächst wie eine Lösung aussieht und die Lage dann verschlechtert. Ein Team ist mit Reviews überlastet, lässt Pull Requests von einem lokalen Harness prüfen und bekommt viele Kommentare. Unklar bleibt, welche relevant sind und welche die tatsächliche Meinung eines Menschen widerspiegeln. Danach antwortet das Team mit Harness-Kommentaren auf Harness-Kommentare. Der Review wird zur Simulation, aus der niemand lernt, und die andere Seite des Teams ist kaum noch beteiligt. Der Bericht empfiehlt stattdessen, in den zentralen Review-Mechanismus zu investieren, in die Harness-Schleife für Feedback und in eine schlichte Freigabe. Das betrifft automatisierte code-review und automatisierte Code-Analyse-Tools: Ein Bot, der immer mehr Kommentare produziert, ist nicht automatisch hilfreich. Hilfreich ist eine klare Entscheidung mit nachvollziehbarer Verantwortung.
Fleet, Verifikation und offene Fragen
Neben small-change beschreibt der Bericht den zentral orchestrierten Harness fleet, der Software in einer kontrollierten Cloud-Umgebung implementiert und verifiziert. Ähnlich wie Stripe’s Minions, aber nicht zwingend im One-Shot-Ansatz, soll fleet unabhängig bewerten, wie viele menschliche Reviewer eine Änderung braucht. Bei als sicher eingestuften Änderungen kann das ein einziger Reviewer sein. Die frühen Ergebnisse sind vorsichtig formuliert: Etwa zehn Prozent der Änderungen qualifizieren sich als small-change und werden dann meist schnell freigegeben, sofern sie kein Sicherheits- oder Geldthema berühren. Ob das Konzept trägt, hängt laut Autor davon ab, ob die Verifikationsmechanismen ausgeweitet werden können. In Software mit hoher Domänenkomplexität und geringer Skalierungskomplexität seien Techniken wie inkrementelle Rollouts weniger wirksam als in Produkten mit vielen gleichartigen Nutzern und hoher Skalierung.
Rezeption und was code review prozess optimieren heißt
Die Rezeption ist nicht einheitlich. Viele Kollegen seien nicht uniformly excited, schreibt Larson, weil der Ansatz von erlernten Best Practices abweicht. Unangenehm ist außerdem die Frage, ob eine lang gehegte Praxis inzwischen Dogma geworden ist. Wer code review prozess optimieren will, muss deshalb nicht nur Tools einführen, sondern auch lieb gewonnene Rituale infrage stellen. Zehn Prozent sind ein Anfang, nicht der Beweis, dass Reviews bald verschwinden. Ob es gelingt, mehr Änderungen verlässlich zu klassifizieren und Prüfungen dorthin zu verschieben, wo sie schneller und belastbarer sind, ist offen. Gelingt es nicht, bleibt small-change eine Express-Spur für wenige Fälle. Gelingt es, verändert sich der gesamte Review-Prozess.
Was das für Teams bedeutet, die code review beschleunigen wollen
Wer code review beschleunigen will, sollte nicht auf die 77 Minuten starren, sondern auf die Richtung der Verschiebung. Imprint prüft nicht alles gleich intensiv. Der Review ist eine Schleuse mit unterschiedlichen Spuren: kleine, vertraute Änderungen laufen durch automatisierte Checks und eine klare Freigabe; heikle Änderungen bleiben beim Menschen. Das lässt sich nicht einfach kopieren, weil die Kriterien von Erfahrung, Repo-Struktur und Verifikationsgrad abhängen. Die Denkweise ist übertragbar: Risiko klassifizieren, Automatisierung nicht mit Kommentarflut verwechseln und Fehler als Systemfehler behandeln. Die Dauer von pull request review zu reduzieren, wird damit zu einer Frage der Architektur des Prüfprozesses, nicht der Disziplin einzelner Reviewer.
Quelle: lethain.com
