# houck-dx-what-are-code-reviews-for-2026-08-05

## Veille

Ausgabe des Newsletters **Engineering Enablement** von **DX**, verfasst von **Brian Houck**, veröffentlicht am **5. August 2026**, Umfang etwa **13.000 Zeichen**. Der Text beginnt mit einer quantifizierten Beobachtung: Bei **Meta** stieg die Zahl signifikanter Codezeilen pro von einem Menschen gemergtem Diff in einem Jahr um **106 %** und die Zahl der Diffs pro Entwickler und Monat um **51 %**, wobei mehr als **80 %** dieses Wachstums auf agentische KI zurückgehen, während der Anteil der innerhalb von 24 Stunden überprüften Diffs sinkt; die Analyse von DX misst ihrerseits eine um **64 %** gestiegene mediane Pull-Request-Größe, während Entwickler nur etwa **7 %** ihrer Zeit für Reviews aufwenden möchten. (A) Bevor er das Review an KI übergibt, formuliert Houck die Nutzungsfrage neu: *„Welches Problem hat Code Review gelöst, bevor KI aufkam?“* Wenn die Antwort Fehlererkennung ist, wird vollständige Automatisierung unvermeidlich; die Studie von **Bacchelli & Bird** (*Modern Code Review*, ICSE 2013) zeigt, dass fehlerbezogene Kommentare nur **14 %** der tatsächlich verfassten Kommentare ausmachen. (B) Ein Teil der Last ist *selbstverschuldet*: Die Microsoft-Studie von 2016 mit **911 Entwicklern** identifizierte bereits Durchlaufzeit, Review-Größe und das Verständnis der Änderungsmotivation als die drei größten Hindernisse, und nur **26 %** verfassten noch eine detaillierte Beschreibung. (1) **RADAR** bei Meta dient als Referenzimplementierung für die Risikostratifizierung. (2) Drei aufeinanderfolgende Schritte: die Grundlagen in Ordnung bringen, KI um das menschliche Urteilsvermögen herum gestalten, das schützen, was Review unsichtbar hervorbringt. Der Korpus umfasst bereits [[monperrus-end-of-code-review-agents-supersede-2026-06-11]], der die Automatisierung bis zum Ersatz vorantreibt, und [[laycock-thoughtworks-reviewing-all-this-code-2026-09-02]], die direkte Antwort auf diesen Text.

## Titre Article

What are code reviews even for?

## Date

2026-08-05

## URL

https://newsletter.getdx.com/p/what-are-code-reviews-even-for

## Keywords

Code-Review, Code-Review, Review-Warteschlange, Pull-Request-Größe, Diff, agentischer Durchsatz, Review-Kapazität, Bikeshedding, Änderungsbeschreibung, Risikostratifizierung, RADAR, Meta, automatisiertes Review, Eignung, menschliche Verantwortlichkeit, Wissenstransfer, kollektive Eigentümerschaft, gemeinsames mentales Modell, kognitive Schuld, Absichtsschuld, Bacchelli & Bird, Modern Code Review, AI Where It Matters, DX, Engineering Enablement, Review-Gesundheit, Revert-Rate, Produktionsvorfälle, mediane Abschlusszeit

## Authors

Brian Houck, signataire de l'édition, sur la newsletter Engineering Enablement de DX ; fonction non affichée par la page.

## Ton

Profil: Ausgabe eines Newsletters zur angewandten Forschung, moderate Ich-Perspektive, gestützt auf interne Datensätze, analytisches Register, das sich gegen Ende präskriptiv zuspitzt, mittleres technisches Niveau, Zielgruppe Engineering-Führungskräfte und Teams für Developer-Productivity-Plattformen. Der Aufbau funktioniert durch eine Umkehrung der gestellten Frage: Statt „wie überprüft man schneller“ fragt der Autor „Welches Problem hat Code Review gelöst, bevor KI aufkam?“ und macht alles Folgende von dieser Antwort abhängig. Die Argumentation verläuft über klar getrennte Evidenzebenen — interne Telemetrie (Meta, DX), zugeschriebene akademische Literatur (Bacchelli & Bird ICSE 2013, die Microsoft-Studie von 2016 mit 911 Entwicklern), interne qualitative Forschung *AI Where It Matters*, zitiert in wörtlichen Entwickleraussagen, dann eine namentlich genannte industrielle Implementierung (RADAR). Die Zugeständnisse sind explizit und stehen vor den Empfehlungen: Ein Teil des Problems ist *selbstverschuldet*, und dem RADAR-Team selbst wird zugeschrieben, seinen eigenen Zielkonflikt — die mögliche Erosion des Wissenstransfers — einzugestehen. Der Text vermeidet sowohl das Register der Resignation als auch das der Begeisterung: KI ist weder Ursache noch Heilmittel, sie *erbt* eine Situation und verstärkt sie. Wörtlich zitierbar: „Das sichtbare Ergebnis von Code Review ist besserer Code. Das unsichtbare Ergebnis ist eine bessere Engineering-Organisation“; die Formel zur Bewertung eines KI-Review-Tools — nicht die Frage „Funktioniert es?“, sondern „Wie maximiert es die Zeit und den Wert menschlichen Urteilsvermögens?“; die wörtliche Aussage eines Entwicklers „meine Freigabe setzt meinen Namen darunter“; und der Schlusssatz: „KI sollte die Zeit, die wir mit dem Review von Code verbringen, unbedingt verkürzen. Sie sollte nur nicht verkürzen, wie viel wir dabei lernen.“

## Pense-betes

- **Die Zahl, die das Problem rahmt, ist nicht die Generierungsgeschwindigkeit, sondern die Kapazitätslücke**: Bei Meta +**106 %** bei signifikanten Codezeilen pro von einem Menschen gemergtem Diff und +**51 %** bei Diffs pro Entwickler und Monat innerhalb eines Jahres, wovon mehr als **80 %** auf agentische KI zurückgeführt werden; auf Seiten von DX mediane PR-Größe +**64 %**. Dem gegenüber geben Entwickler an, nur etwa **7 %** ihrer Zeit für Reviews aufwenden zu wollen. Houck folgert, dass mehr Review zu fordern keine nachhaltige Antwort ist: „Die Rechnung geht nicht auf.“
- **Die Kluft zwischen genannter Motivation und tatsächlicher Praxis ist das zentrale Argument.** Die Studie *Modern Code Review* (Bacchelli & Bird, ICSE 2013) stellt fest, dass Fehlererkennung die am häufigsten genannte Motivation ist, fehlerbezogene Kommentare jedoch nur **14 %** der verfassten Kommentare ausmachen; mehr als die Hälfte der Entwickler gibt an, Review zu nutzen, um alternative Lösungen zu erkunden. Wenn Review nicht das tut, was wir glauben, ersetzt die Automatisierung dessen, was wir glauben, es nicht.
- **Das Problem geht der KI voraus.** Die Microsoft-Studie von 2016 mit **911 Entwicklern** stufte Durchlaufzeit, Review-Größe und das Verständnis der Änderungsmotivation bereits an oberster Stelle ein; nur **26 %** verfassten noch eine detaillierte Beschreibung, und *Bikeshedding* gehörte zu den häufigsten Schwachstellen. Die Formel des Artikels: KI hat die Situation nicht geschaffen, sie hat sie geerbt und verstärkt. Operative Konsequenz: die Grundlagen prüfen (PR-Größe, Beschreibung des *Warum*, geschützte Review-Zeit, bereits vorhandene automatisierte Prüfungen) **bevor** man ein KI-Review-Tool anschafft.
- **RADAR (Risk Aware Diff Auto Review), Meta** — die zitierte Referenzimplementierung: eine Kombination aus statischer Analyse, *Machine Learning*, LLM-Review und deterministischer Validierung, angewendet auf eine Teilmenge von Änderungen mit niedrigem bis mittlerem Risiko, wobei riskantere Diffs an Menschen weitergeleitet werden. Genannte Zahlen: mehr als **535.000** überprüfte Diffs, mehr als **331.000** gemergt, eine Revert-Rate von etwa **einem Drittel** derjenigen von Nicht-RADAR-Diffs, eine um das **Fünfzigfache** niedrigere Rate an Produktionsvorfällen, eine mediane Abschlusszeit, die **3,3×** schneller ist (~70 % Reduktion). Dem RADAR-Team wird zugeschrieben, den Zielkonflikt selbst benannt zu haben: Mit zunehmender Automatisierung kann der Wissenstransfer durch menschliches Review leiden.
- **Was Entwickler von KI im Review erwarten und was sie ablehnen** (DX-Studie *AI Where It Matters*): Sicherheits- und Compliance-Probleme erkennen, riskante Änderungen markieren, Test-Gerüste generieren, die Auswirkungen einer Änderung auf die gesamte Codebasis aufzeigen, Routinevolumen abfangen. Ausdrücklich abgelehnt: Auto-Merge, Auto-Commit und die Übernahme der endgültigen Verantwortung — „Ich kann das abschließende Code Review nicht vollständig an KI delegieren — meine Freigabe setzt meinen Namen darunter.“
- **Kognitive Schuld und Absichtsschuld**: Houck entlehnt **Margaret-Anne Storey** die Bezeichnung für dieses langsam wachsende Risiko — die zunehmende Kluft zwischen dem, was das System tut, und dem, was die Organisation gemeinsam über das *Warum* versteht. Diese Schulden erscheinen auf keinem Dashboard und treten erst Monate später zutage, bei einem Vorfall, einer Übergabe oder einem Rewrite. Der beschriebene Mechanismus ist inkrementell: eine Reihe von einzeln betrachtet vernünftigen Entscheidungen („diese Änderung ist risikoarm“, „dieses Review lässt sich automatisieren“).
- ⚠️ **Was der Text nicht liefert**: keine operative Kennzahl für „Review-Gesundheit“ jenseits des Durchsatzes, obwohl die dritte Empfehlung lautet, zu messen, ob Junior-Entwickler lernen und ob sich architektonisches Wissen verbreitet — der Artikel setzt das Ziel, ohne den Indikator zu instrumentieren. Die RADAR-Zahlen werden berichtet, nicht geprüft, und ein Leser weist in den Kommentaren auf eine fragwürdige Prozentformulierung hin.
- **Verwandt**: [[williams-adlc-4-prosecution-not-code-review-2026-06-12]] (Review neu gedacht als staatsanwaltlicher Fallaufbau statt als Inspektion) und [[osmani-cognitive-surrender-comprehension-debt-2026-05-05]] (dieselbe Verständnisschuld, anders benannt).

## RésuméDe400mots

Brian Houck veröffentlicht am 5. August 2026 im Engineering-Enablement-Newsletter von DX einen Text, der sich der Krise der Review-Warteschlange aus einem anderen Blickwinkel als dem der Tools nähert. Die quantifizierte Beobachtung ist eindeutig: Bei Meta stieg die Zahl signifikanter Codezeilen pro von einem Menschen gemergtem Diff in einem Jahr um 106 %, die Zahl der Diffs pro Entwickler und Monat um 51 %, wobei mehr als 80 % dieses Wachstums auf agentische KI zurückgehen; die Analyse von DX misst eine um 64 % gestiegene mediane Pull-Request-Größe. Zugleich sinkt der Anteil der innerhalb von 24 Stunden überprüften Diffs, und manche großen Organisationen häufen Tausende ausstehender Reviews an. Dennoch möchten Entwickler nur etwa 7 % ihrer Zeit für Reviews aufwenden. Mehr Review zu fordern ist keine Antwort: Die Rechnung geht nicht auf.

Bevor er KI als Rettung heranzieht, formuliert Houck die Nutzungsfrage neu: Welches Problem hat Code Review gelöst, bevor es KI gab? Wenn es ausschließlich um das Finden von Fehlern ging, ist vollständige Automatisierung unvermeidlich und wünschenswert. Doch die Modern-Code-Review-Studie von Bacchelli und Bird (ICSE 2013) stellt fest, dass fehlerbezogene Kommentare nur 14 % der tatsächlich verfassten Kommentare ausmachen, obwohl Fehlererkennung die am häufigsten genannte Motivation ist; mehr als die Hälfte der Entwickler gibt an, Review zu nutzen, um alternative Lösungen zu erkunden, Wissen zu übertragen und zu erfahren, was ihre Kollegen entwickeln.

Ein Teil der Last ist, wie er schreibt, selbstverschuldet. Die Microsoft-Studie von 2016 mit 911 Entwicklern identifizierte bereits Durchlaufzeit, Review-Größe und das Verständnis der Motivation als die drei größten Hindernisse; nur 26 % verfassten noch eine detaillierte Beschreibung. KI hat diese Situation nicht geschaffen: Sie hat sie geerbt und verstärkt.

Sobald die Grundlagen stehen, hat KI eine echte Rolle zu spielen. Die Studie AI Where It Matters von DX zeigt, dass Entwickler von ihr erwarten, Sicherheits- und Compliance-Probleme zu erkennen, riskante Änderungen zu markieren und das Routinevolumen abzufangen — aber Auto-Merge, Auto-Commit und die Übertragung der Verantwortung ablehnen. Das RADAR-System von Meta wird als die ausgereifteste Umsetzung dieser Linie vorgestellt: Automatisierung einer Teilmenge von Diffs mit niedrigem bis mittlerem Risiko, Weiterleitung des Rests an Menschen, mit behaupteten Nettoergebnissen und einem eingestandenen Zielkonflikt beim Wissenstransfer.

Das Fazit entlehnt Margaret-Anne Storey den Begriff der kognitiven Schuld und der Absichtsschuld: Die Frage ist nicht, zwischen menschlichem Review und KI-Review zu wählen, sondern zu entscheiden, welche Teile des Reviews zu wertvoll sind, um automatisiert zu werden.

## GrapheDeConnaissance

- DX —publie→ What are code reviews even for? (DOCUMENT, 0.97)
- Brian Houck —a_créé→ What are code reviews even for? (DOCUMENT, 0.96)
- Brian Houck —travaille_chez→ DX (ORGANISATION, 0.9)
- Meta —mesure→ lignes significatives par diff humainement fusionné +106 % et diffs par développeur et par mois +51 % en un an, dont plus de 80 % attribués à l'IA agentique (MESURE, 0.93)
- DX —mesure→ taille médiane des pull requests en hausse de 64 % sous l'effet des outils de codage IA (MESURE, 0.92)
- Brian Houck —affirme_que→ demander aux développeurs de revoir davantage n'est pas soutenable : ils souhaitent y consacrer environ 7 % de leur temps (AFFIRMATION, 0.92)
- Modern Code Review —mesure→ les commentaires liés aux défauts ne représentent que 14 % des commentaires réellement écrits en revue (MESURE, 0.94)
- revue de code —permet→ exploration de solutions alternatives, transfert de connaissance et conscience de ce que construisent les coéquipiers (CONCEPT, 0.93)
- Brian Houck —affirme_que→ la sortie visible de la revue est un meilleur code, sa sortie invisible une meilleure organisation d'ingénierie (CITATION, 0.95)
- IA agentique —s_applique_à→ une dysfonction de revue préexistante qu'elle amplifie sans l'avoir créée (AFFIRMATION, 0.91)
- étude Microsoft 2016 sur la revue de code —mesure→ délai de retour, taille de la revue et compréhension de la motivation en tête des obstacles ; 26 % seulement rédigent toujours une description détaillée (MESURE, 0.9)
- bikeshedding —observé_dans→ les échecs de revue les plus fréquents, où l'on dispute du détail pendant que le sérieux reste inexaminé (AFFIRMATION, 0.88)
- Meta —a_créé→ RADAR (TECHNOLOGIE, 0.95)
- RADAR —utilise→ analyse statique, machine learning, revue par LLM et validation déterministe combinées avant fusion (CONCEPT, 0.93)
- RADAR —mesure→ plus de 535 000 diffs revus, plus de 331 000 fusionnés, revert environ un tiers du taux hors RADAR, incidents de production cinquante fois plus bas, fermeture médiane 3,3× plus rapide (MESURE, 0.9)
- stratification par risque —s_oppose_à→ automatisation indifférenciée de la revue sur tous les changements (AFFIRMATION, 0.92)
- RADAR —réduit→ le transfert de connaissance assuré par la revue humaine, arbitrage reconnu par l'équipe elle-même (AFFIRMATION, 0.88)
- AI Where It Matters —affirme_que→ les développeurs veulent que l'IA détecte les risques et absorbe le routinier, mais refusent auto-merge, auto-commit et transfert de la redevabilité finale (AFFIRMATION, 0.92)
- redevabilité humaine —s_applique_à→ l'approbation finale d'un changement, que le développeur signe de son nom (CITATION, 0.9)
- Margaret-Anne Storey —a_créé→ dette cognitive et dette d'intention (CONCEPT, 0.9)
- dette cognitive et dette d'intention —mesure→ écart croissant entre ce que le système fait et ce que l'organisation comprend du pourquoi, invisible sur les tableaux de bord (AFFIRMATION, 0.89)
- Brian Houck —recommande→ réparer les fondamentaux, concevoir l'IA autour du jugement humain, puis mesurer la santé de la revue au-delà du débit (AFFIRMATION, 0.93)
- Brian Houck —recommande→ évaluer un outil de revue IA en demandant comment il maximise le temps et la valeur du jugement humain, pas s'il fonctionne (CITATION, 0.91)

---
Canonical: https://www.thekb.eu/de/fiches/houck-dx-what-are-code-reviews-for-2026-08-05/