Welcome to the latest issue of Engineering Enablement, a weekly newsletter sharing research and perspectives on developer productivity.
DX’s Q2 AI Impact Report is now available with the latest research on AI’s impact across engineering organizations. Read the full report.
Something is straining in the review queue.
Over the past year at Meta, significant lines of code per human-landed diff increased by 106%. Diffs per developer per month rose 51%. More than 80% of that growth came from agentic AI. Meanwhile, the percentage of diffs reviewed within 24 hours is declining. In some large groups, reviewers are staring down thousands of pending reviews.
This isn’t a Meta-specific problem. Across the industry, AI coding tools are producing code faster than humans can meaningfully evaluate it. Our own DX analysis found that AI is increasing both the number of pull requests and the size of each one (median pull request size grew by 64%). Without a corresponding increase in reviewer capacity, the review process will eventually buckle under its own weight.
Unfortunately, we don’t have more hours in the day, and even if we did, we wouldn’t want to spend them reviewing code written by AI. In previous research, we found developers ideally only want to spend about 7% of their time reviewing code. Asking developers to review more isn’t a sustainable answer.
The math doesn’t work.
But before we ask AI to solve this problem, it’s worth asking a different question:
What problem was code review solving before AI arrived?
If the answer were as simple as “finding defects,” then a fully automated review starts to sound inevitable (and appealing).
But if code review was also how teams shared knowledge, built collective ownership, spread architectural understanding, and taught junior engineers how experienced developers think, then the answer becomes much less obvious.
That’s the mistake I think many organizations are about to make, and the reason we need to rethink what code review is actually for.
We’ve known better for years
Here’s an uncomfortable truth: a significant portion of the review burden we’re feeling right now is self-inflicted.
The frustrating part is that none of this is new. The research on what makes code review effective has been unambiguous. Keep changes small. Write a meaningful description of what changed and why. Run automated checks before asking a human to look. Review frequently, in bounded sessions, focused on substance over style. Select reviewers who actually know the code, but avoid concentrating review responsibility on the same small group of experts whenever possible.
A 2016 Microsoft study of 911 developers found that timely feedback, review size, and understanding the motivation for a change were the top three challenges in code review. Those challenges should sound familiar. The research had already identified many of the practices that improve review quality, yet only 26% of developers said they always wrote a detailed description of the code being reviewed. “Bikeshedding”—disputing minor issues while more serious ones went unexamined—remained one of the most common review failures. We didn’t need new guidance. We needed to consistently apply what we already knew.
AI didn’t create this situation. It inherited it, and then amplified it. Larger PRs, higher review volume, less context per change, these aren’t new symptoms. They’re old ones, scaled up.
Before asking AI to fix your code review process, ask whether your team has built the habits that make code review effective in the first place. Small, well-explained changes. Protected reviewer time. Automated routine checks so humans can focus on judgment.
AI can absolutely improve code review. But it can’t compensate for a review culture that was already struggling. It doesn’t eliminate bad review habits. It amplifies them.
AI can help, if we use it wisely
Once the fundamentals are in place, AI has a real role to play in code review. That’s exactly what we found in our AI Where It Matters research. Developers don’t want code review to disappear. They want AI to remove the parts of review that don’t require human judgment so reviewers can spend more time on the parts that do.
What they want AI to do: catch security and compliance issues, flag high-risk changes, generate test scaffolding, surface the impact of a change across the codebase, and handle the high-volume routine so human attention can go where it matters. As one developer put it: “Should be able to detect high risk changes and derisk them.”
What they explicitly don’t want: AI that auto-merges, auto-commits, or takes final accountability. “I don’t want AI to just act as a red-light / green-light. It should raise issues… and still require human review.” Developers aren’t asking for a replacement, they’re asking for a better collaborator.
Interestingly, one of the most sophisticated production deployments I’ve seen tries to walk that line.
Meta’s RADAR (Risk Aware Diff Auto Review) system automates review for a carefully selected subset of low-to-medium risk changes while routing higher-risk diffs to human reviewers. It combines static analysis, machine learning, LLM-based review, and deterministic validation before anything lands.
The results are striking: more than 535,000 diffs reviewed, over 331,000 landed, a revert rate roughly one-third that of non-RADAR diffs, a production incident rate one-fiftieth as high, and a 3.3x faster median time to close (roughly a 70% reduction).
RADAR isn’t simply “AI reviewing code.” It’s a carefully engineered system built around the principle that scarce human attention should be reserved for changes where human judgment and accountability matter most.
Just as importantly, the RADAR team also acknowledges a trade-off. Automated review can dramatically improve efficiency, but as automation expands, the knowledge transfer provided by human review could suffer. They identify this as something engineering organizations should actively monitor.
That’s the distinction I think many organizations miss. AI shouldn’t eliminate human review. It should make human review more valuable. AI-enabled review should have discipline around it: clear eligibility criteria, thoughtful risk stratification, and a deliberate decision about which changes deserve human attention, and why.
If you’re evaluating an AI review system, don’t start by asking, “Does it work?” Start by asking, “How does it maximize the time and value of human judgment?”
Don’t lose what review was actually doing
Here’s the part that gets left out of the AI review conversation: code review was never just about finding defects.
A landmark Microsoft study found that while most developers identified defect detection as a primary motivation for code review, defect-related comments made up only 14% of actual review comments. In practice, code review serves many other purposes. More than half of developers said they use reviews to explore alternative solutions, while many also pointed to knowledge transfer and gaining awareness of what their teammates are building.
The visible output of code review is better code. The invisible output is a better engineering organization.
Code review is how teams build shared understanding of a system. It’s how junior developers learn from experienced ones. It’s how architectural intent gets surfaced, questioned, and refined. It’s how one engineer’s mental model gradually becomes the team’s mental model. Organizations don’t become resilient because one person understands a subsystem. They become resilient because many people do.
This is why the stakes around AI review are so high. Automate the review of a diff, and you may have successfully reviewed that diff. But you haven’t transferred any knowledge. You haven’t built shared ownership. You haven’t given a newer engineer a window into how a more experienced teammate reasons about trade-offs. You haven’t surfaced the design rationale that someone will need six months from now when they’re trying to respond to customer feedback.
Developers in our AI Where It Matters research understood this instinctively. One participant wrote, “I can’t fully delegate the final code review to AI—my approval puts my name on it.” Another warned, “Intellectual offloading can result in errors that eventually no one understands.” That’s the slow-moving risk. The gradual erosion of a team’s ability to reason about its own software.
Margaret-Anne Storey’s recent work gives this phenomenon a name. As AI accelerates software development, teams don’t just accumulate technical debt. They accumulate cognitive and intent debt—a growing gap between what the system does and what the organization collectively understands about why it does it. Those debts don’t appear on a dashboard. They surface months later, during an outage, a handoff, or a redesign, when nobody remembers the reasoning that once lived inside a code review conversation. By then, recovering that understanding is far more expensive than preserving it would have been.
This future isn’t inevitable. But it also won’t arrive all at once. It will emerge through a series of individually reasonable decisions: this change is low risk, this review can be automated, this approval can be skipped. Each decision saves a little time. Taken together, they may slowly eliminate one of the primary ways engineering teams build shared understanding.
The challenge isn’t choosing between AI and human review. It’s deciding which parts of code review are too valuable to automate away.
What to actually do
Three things, in order.
Fix the basics first. Audit your current review process. Are pull requests small enough to review meaningfully? Do change descriptions explain why, not just what? Are reviewers protected from overload? Are automated tools already handling the routine work they should (e.g. formatting, linting, and obvious style issues)?
Design AI around human judgment. Developers consistently describe code review as high-value, high-accountability work. They don’t want AI making the decision; they want AI helping them make better ones. That means risk stratification instead of blanket automation. It means AI that surfaces issues, not AI that silently resolves them. It means conservative eligibility thresholds, auditability, and clear human accountability.
Protect what review is actually building. The easiest thing to measure about code review is defects. The most valuable thing it produces is shared understanding. Measure review health beyond throughput. Are junior developers learning? Is architectural knowledge spreading across the team? Are reviewers engaging with substance or simply rubber-stamping? Design your AI review strategy so automation absorbs the routine while humans spend more time on the conversations that create understanding, ownership, and better engineering judgment.
Code review is one of the highest-leverage practices in software engineering, and right now it’s under pressure from every direction. The answer isn’t to make it faster by making it shallower. It’s to get serious about doing it well—with or without AI—and then use AI deliberately, in the places where it earns trust and preserves what the practice was accomplishing all along.
AI should absolutely reduce the time we spend reviewing code. It just shouldn’t reduce the amount we learn from it.
That’s it for this week. Thanks for reading.
-Brian
Your article captures my biggest concern about AI so far. Emphasis on "so far".
I worry the rush to implement AI for efficiency gains will prove to be incredibly short-sighted. AI is replacing many of the tasks that help junior experts become better experts, and how the organisation learns in general. Efficiency is obtained over the short term, but there is a risk to the long-term capability of an organisation that doesn't stop to think about how they are going to compensate for the impact on their talent pipeline.
And I completely agree with "The visible output of code review is better code. The invisible output is a better engineering organization."
The invisible output can be much more important over time. A junior expert watches how the senior expert thinks, what they notice, which evidence they ignore, where they challenge an assumption, and why a similar problem is actually an exception.
I've written previously about the importance of deliberate practice in developing expertise. Expertise isn't simply accumulated knowledge. It develops through repeated experience, feedback, and opportunities to make increasingly difficult judgments.
If we automate something because its visible output can be produced faster, do we actually know what invisible developmental work we've just removed?
“…reduced by more than 330%” ?