What are code reviews even for?

At Meta, the numbers tell a strange story. Lines of code per human-landed diff jumped 106% over the past year, diffs per developer climbed 51%, and more than 80% of that surge traces back to agentic AI tools. Reviewers aren't keeping pace. In some large groups, thousands of diffs are sitting in the queue, and the share reviewed within 24 hours keeps shrinking. This isn't unique to Meta either — pull request volume and size are both climbing industry-wide, with median PR size up 64% according to DX's own research.

The instinct is to throw AI at the review bottleneck too. But that misses a more basic question: what was code review actually for before AI showed up? If it was purely about catching bugs, full automation looks like an easy win. Except a 2013 Microsoft study by Bacchelli and Bird found defect-related comments made up just 14% of what reviewers actually wrote. Most of the value came from knowledge transfer, exploring alternative approaches, and keeping teammates aware of what everyone else was building.

A lot of the current strain is self-inflicted, too. A 2016 Microsoft study of 911 developers flagged review size, unclear motivation, and slow feedback as the top complaints — and only 26% of developers said they consistently wrote decent change descriptions. AI didn't invent sloppy review habits. It just scaled them up along with everything else.

Meta's own fix, a system called RADAR, offers a more disciplined model. It auto-reviews low-to-medium risk diffs using static analysis, machine learning, and LLM checks, while routing riskier changes to humans. The results are hard to argue with: over 535,000 diffs reviewed, a revert rate a third of non-RADAR diffs, incident rates 50 times lower, and median review time cut by roughly 70%. Even Meta's own team flags a catch, though — as automation expands, the informal knowledge transfer that used to happen during review starts to quietly disappear.

That's the real risk buried in all this efficiency. Researcher Margaret-Anne Storey calls it cognitive and intent debt: the growing gap between what a codebase does and what the team actually understands about why it does that. It doesn't show up on a dashboard. It shows up during an outage six months later, when nobody remembers the reasoning that used to live inside a review thread. Developers surveyed for DX's research seem to sense this already — one wrote that approving a change puts their name on it, no matter who wrote the code.

The practical path forward isn't choosing AI over humans or vice versa. It's fixing the basics — smaller diffs, real descriptions, protected reviewer time — then letting AI absorb the routine checks so human attention goes toward the judgment calls, the mentoring, and the design conversations that no model can fake.