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

## Veille

Issue of the **Engineering Enablement** newsletter from **DX** signed by **Brian Houck**, published on **August 5, 2026**, approximately **13,000 characters**. The text opens with a quantified observation: at **Meta**, significant lines per diff merged by a human increased by **106%** in one year and diffs per developer per month by **51%**, with more than **80%** of this growth coming from agentic AI, while the share of diffs reviewed within 24 hours declines; DX's analysis for its part measures a median pull request size up **64%**, while developers want to devote about **7%** of their time to review. (A) Before handing review over to AI, Houck reframes the usage question: *"What problem was code review solving before AI arrived?"* If the answer is defect detection, full automation becomes inevitable; the **Bacchelli & Bird** study (*Modern Code Review*, ICSE 2013) shows that defect-related comments account for only **14%** of comments actually written. (B) Part of the burden is *self-inflicted*: the 2016 Microsoft study of **911 developers** already identified turnaround time, review size, and understanding the motivation for the change as the top three obstacles, and only **26%** still wrote a detailed description. (1) **RADAR** at Meta serves as the reference deployment for risk stratification. (2) Three ordered moves: fix the fundamentals, design AI around human judgment, protect what review invisibly produces. The corpus already includes [[monperrus-end-of-code-review-agents-supersede-2026-06-11]], which pushes automation to the point of replacement, and [[laycock-thoughtworks-reviewing-all-this-code-2026-09-02]], the direct response to this 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 queue, pull request size, diff, agentic throughput, review capacity, bikeshedding, change description, risk stratification, RADAR, Meta, automated review, eligibility, human accountability, knowledge transfer, collective ownership, shared mental model, cognitive debt, intent debt, Bacchelli & Bird, Modern Code Review, AI Where It Matters, DX, Engineering Enablement, review health, revert rate, production incidents, median closure time

## Authors

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

## Ton

Profile: applied-research newsletter issue, moderate first-person voice backed by in-house datasets, analytical register turning prescriptive toward the end, medium technical level, target audience engineering leaders and developer-productivity platform teams. The construction proceeds by flipping the question asked: rather than "how to review faster," the author asks "What problem was code review solving before AI arrived?" and makes everything that follows depend on the answer. The argument proceeds through clearly separated tiers of evidence — internal telemetry (Meta, DX), attributed academic literature (Bacchelli & Bird ICSE 2013, the 2016 Microsoft study of 911 developers), in-house qualitative research *AI Where It Matters* cited in developer verbatims, then a named industrial deployment (RADAR). The concessions are explicit and placed before the recommendations: part of the problem is *self-inflicted*, and the RADAR team itself is credited with acknowledging its own trade-off, the possible erosion of knowledge transfer. The text avoids both the register of resignation and that of enthusiasm: AI is neither the cause nor the cure, it *inherits* a situation and amplifies it. Quotable as-is: "The visible output of code review is better code. The invisible output is a better engineering organization"; the formula for evaluating an AI review tool — not asking "Does it work?" but "How does it maximize the time and value of human judgment?"; a developer's verbatim "my approval puts my name on it"; and the closing line, "AI should absolutely reduce the time we spend reviewing code. It just shouldn't reduce the amount we learn from it."

## Pense-betes

- **The number that frames the problem is not generation speed but the capacity gap**: at Meta, +**106%** in significant lines per humanly merged diff and +**51%** in diffs per developer per month in one year, more than **80%** of which is attributed to agentic AI; on the DX side, median PR size +**64%**. Against this, developers report wanting to devote ~**7%** of their time to review. Houck concludes that asking for more review is not a sustainable answer: "The math doesn't work."
- **The gap between stated motivation and actual practice is the central argument.** The *Modern Code Review* study (Bacchelli & Bird, ICSE 2013) finds that defect detection is the most frequently cited motivation, but that defect-related comments represent only **14%** of comments written; more than half of developers report using review to explore alternative solutions. If review does not do what we believe it does, automating what we believe it does does not replace it.
- **The liability predates AI.** The 2016 Microsoft study of **911 developers** already ranked turnaround time, review size, and understanding the motivation for the change at the top; only **26%** still wrote a detailed description, and *bikeshedding* was among the most frequent failures. The article's formula: AI did not create the situation, it inherited it and amplified it. Operational corollary: audit the fundamentals (PR size, description of the *why*, protected review time, automated checks already in place) **before** buying an AI review tool.
- **RADAR (Risk Aware Diff Auto Review), Meta** — the reference deployment cited: a combination of static analysis, *machine learning*, LLM review, and deterministic validation, applied to a subset of low-to-medium-risk changes, with riskier diffs routed to humans. Figures cited: more than **535,000** diffs reviewed, more than **331,000** merged, a revert rate about **one-third** that of non-RADAR diffs, a production incident rate **fifty times** lower, a median closure time **3.3×** faster (~70% reduction). The RADAR team is credited with naming the trade-off itself: as automation expands, knowledge transfer through human review may suffer.
- **What developers want from AI in review, and what they refuse** (DX research *AI Where It Matters*): detect security and compliance issues, flag high-risk changes, generate test scaffolding, expose a change's impact across the codebase, absorb routine volume. Explicitly refused: auto-merge, auto-commit, and taking on final accountability — "I can't fully delegate the final code review to AI — my approval puts my name on it."
- **Cognitive debt and intent debt**: Houck borrows from **Margaret-Anne Storey** the name for this slow-building risk — the growing gap between what the system does and what the organization collectively understands about the *why*. These debts appear on no dashboard and surface months later, at an incident, a handover, or a rewrite. The mechanism described is incremental: a series of individually reasonable decisions ("this change is low-risk," "this review can be automated").
- ⚠️ **What the text does not provide**: no operational metric for "review health" beyond throughput, even though the third recommendation is to measure whether juniors are learning and whether architectural knowledge is spreading — the article sets the goal without instrumenting the indicator. The RADAR figures are reported, not audited, and one reader flags a questionable percentage formulation in the comments.
- **Related**: [[williams-adlc-4-prosecution-not-code-review-2026-06-12]] (review reconceived as prosecutorial case-building rather than inspection) and [[osmani-cognitive-surrender-comprehension-debt-2026-05-05]] (the same comprehension debt, named differently).

## RésuméDe400mots

Brian Houck publishes, on August 5, 2026, in DX's Engineering Enablement newsletter, a text that approaches the review-queue crisis from an angle other than tooling. The quantified observation is stark: at Meta, significant lines per diff merged by a human increased by 106% in one year, diffs per developer per month by 51%, with more than 80% of this growth coming from agentic AI; DX's analysis measures a median pull request size up 64%. Meanwhile, the share of diffs reviewed within 24 hours declines, and some large organizations accumulate thousands of pending reviews. Yet developers want to devote about 7% of their time to review. Asking for more is not an answer: the math doesn't work.

Before calling in AI as a rescue, Houck reframes the usage question: what problem was code review solving before AI? If it was solely finding defects, full automation is inevitable and desirable. But the Modern Code Review study by Bacchelli and Bird (ICSE 2013) establishes that defect-related comments account for only 14% of comments actually written, even though defect detection is the most frequently cited motivation; more than half of developers report using review to explore alternative solutions, transfer knowledge, and know what their colleagues are building.

Part of the burden is, he writes, self-inflicted. The 2016 Microsoft study of 911 developers already identified turnaround time, review size, and understanding the motivation as the top three obstacles; only 26% still wrote a detailed description. AI did not create this situation: it inherited it and amplified it.

Once the fundamentals are in place, AI has a real role to play. DX's AI Where It Matters research shows that developers want it to detect security and compliance issues, flag risky changes, and absorb routine volume — but reject auto-merge, auto-commit, and the transfer of accountability. Meta's RADAR system is presented as the most accomplished implementation of this line: automation of a subset of low-to-medium-risk diffs, routing the rest to humans, with claimed net results and an acknowledged trade-off on knowledge transfer.

The conclusion borrows from Margaret-Anne Storey the notion of cognitive debt and intent debt: the question is not choosing between human review and AI review, but deciding which parts of review are too valuable to automate.

## 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/en/fiches/houck-dx-what-are-code-reviews-for-2026-08-05/