Data recently reported on Martin Fowler's blog shows that the volume of AI-generated code is rapidly outpacing what human review can absorb. According to DX data, Meta's significant lines of code per landed diff per person rose 106% in a year, while median PR size grew 64% over the same period. The shift has set off a debate in the tech community over whether code review needs to be restructured.
Data lays bare the review pressure
The figures come from citations in the Martin Fowler blog post "Maybe We Shouldn't Be Reviewing All This Code." The author debated code review with Brian Houck of DX at a panel at a Code Remix event, and the two disagreed sharply. Houck later wrote "What are code reviews even for?", the post that prompted this response.
The post argues that AI is producing more code than humans can realistically review. Data cited by Houck shows Meta's significant lines of code per landed diff per person rose 106% in a year, while DX's own data shows median PR size grew 64%. Together the numbers sketch out the volume pressure on the review process.
| Metric | Source | One-year increase |
|---|---|---|
| Meta significant lines of code per landed diff per person | Data cited by Brian Houck | 106% |
| Median PR size | DX data | 64% |
The dispute over what review is for
The core of the argument is what code review is supposed to solve. Houck's concern is that simply automating code review could lose the other functions review serves. The author agrees, and goes further: code review is not just about finding bugs. It is how teams share knowledge, teach junior engineers, build collective ownership and spread architectural understanding.
Code review isn’t just about finding bugs. It’s how teams share knowledge, teach junior engineers, build collective ownership and spread architectural understanding.
But the author also offers a different view: perhaps the problem is not that AI has broken code review, but that teams have been using code review to solve the wrong problems. That reframes the discussion from "has AI made review fail" to "is review itself overloaded."
Verification costs and the measurement trap
Another Martin Fowler blog post, "Fragments: September 8," cites Christian Catalini for a broader view of the dilemma. Catalini notes that we are vastly reducing the cost of generating things, but not the cost of verifying them.
We’re in a situation where we are vastly reducing the cost of generating things, but not the cost of verifying them.
Catalini argues this explains why the first major AI products appeared in chat, image generation and code assistance: not because these were the hardest human problems, but because their outputs were relatively easy to inspect. A user can judge the tone of a message, look at an image or run tests on code. He further suggests that the old automation boundary was routine versus non-routine work, while the new boundary is increasingly measurable versus unmeasurable work.
In software, there is a wide gap between lines of code and productivity, and attempts to measure productivity often fail. Catalini warns that the danger is people automating heavily with AI while measuring its effectiveness incompletely, so dashboards rise in the short term but disaster follows on longer timescales. He calls this illusory short-term gain "counterfeit utility." Scaled up across companies and institutions, the result is a "Hollow Economy": extraordinary measurement activity built on weakened human capability, hidden technical debt, correlation errors and results no one can confidently stand behind.
What to watch
The debate has yet to produce a consensus. Whether code review needs restructuring, how to restructure it, and how to balance review efficiency against its other functions as AI-generated code surges remain open questions for engineering teams. The Martin Fowler blog discussion offers reference points on several sides of the issue.