Maybe We Shouldn't Be Reviewing All This Code

A new argument in the AI coding debate says the real problem may not be code review itself, but the fact that teams have made it carry too much weight.

That’s the thrust of a response to Brian Houck of DX, after a panel at Code Remix hosted by Moderne. The disagreement wasn’t about whether code review matters. It was about whether review is the right place for things like knowledge sharing, junior training, architectural alignment and collective ownership. The writer says those goals are real. The objection is that they’ve been pushed too late in the process.

The pressure is getting harder to ignore. Brian cites data showing significant lines of code per human-landed diff at Meta rose 106% in a year, while DX’s own figures show median pull request size up 64%. If AI keeps pushing more code into the system, then a setup where every change waits for a senior engineer to inspect it line by line becomes a bottleneck, not a safeguard.

So the proposed fix is to move judgment earlier. Pairing, trunk-based development, design sessions, automated testing, static analysis, security scanning and fitness functions should catch more issues before code ever becomes a finished diff. Formatting, linting and deterministic checks can be automated outright. And yes, people should still review some changes — especially major architectural shifts, sensitive security boundaries, large blast-radius changes or anything in a critical system where the team lacks confidence.

The deeper worry is cognitive and intent debt: systems getting bigger while the people around them understand less. The writer argues pull requests are a weak defence against that on their own. If AI is going to generate more of the implementation, teams need to build human understanding much earlier, and much more deliberately, than the old review queue ever allowed.