Code Review Capacity Gap: RADAR and Knowledge Transfer

Key takeaways

1. 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."
2. 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.
3. 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.
4. 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.
5. 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."
6. 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").
7. ⚠️ 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.
8. 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).