The Death of Code Reviews (As We Know Them) | by Ben Northmore | Jul, 2026 | MediumSitemapOpen in appSign up<br>Sign in
Medium Logo
Get app<br>Write
Search
Sign up<br>Sign in
The Death of Code Reviews (As We Know Them)
Ben Northmore
3 min read·<br>Just now
Listen
Share
Press enter or click to view image in full size
The more code I see AI generate, the less convinced I am that our current approach to code reviews can scale.<br>For years, code review has been a fairly stable process. Someone spends a few hours or a few days building something, opens a pull request, another engineer reads through the diff, understands what changed and decides whether it's ready to merge. It isn't perfect, but it's worked because writing the code took a meaningful amount of time. Reviewing it felt proportional.<br>I see that relationship changing.<br>A couple of years ago, a pull request containing 800 lines of code usually represented a significant amount of engineering effort. Today, I can ask Cursor to implement a feature, refactor a few files, write tests and explain its own reasoning before I've finished my coffee. Whether the code is correct is another question entirely, but generating it is no longer the expensive part.<br>The expensive part is deciding whether we should trust it.<br>What's interesting is that our review process hasn't really changed. We still open a diff and work backwards. We scan hundreds of lines of additions and deletions, slowly build a mental model of what the author was trying to achieve and then decide whether we're comfortable pressing Merge.<br>I'm not sure that's the best use of an experienced engineer's time.<br>The engineers I respect aren't valuable because they can read code faster than everyone else. They're valuable because they ask awkward questions.<br>Why was this approach chosen?<br>What happens when this dependency fails?<br>Are we introducing another pattern that we’ll have to support forever?<br>Is there a simpler way of doing this?<br>They’re reviewing the decisions behind the code far more than the syntax itself.<br>That made me wonder if we've accidentally made the implementation the centre of the review process when it should really be supporting evidence.<br>Imagine opening a pull request and starting with a generated summary instead of a diff.<br>This change introduces one new endpoint. Authentication is unchanged. No new dependencies have been added. One database query has changed. Test coverage is unchanged. Service A now depends on Service B. No measurable performance impact is expected.
Engineers already write summaries like this, although some are better than others. My point is that they feel optional. The diff is still treated as the source of truth.<br>I'd almost reverse that.<br>Read the summary first. Challenge the claims. Decide where the risk is likely to be. Then use the code to verify those claims instead of using the code to discover them in the first place.<br>That changes the review from "What happened? " to "Do I believe this is the right change? "<br>To me, that's a much more interesting problem.<br>As code generation gets cheaper, confidence becomes more expensive. I don't just want to know that something compiles or that the tests passed. I want confidence that it solves the right problem, doesn't create three new ones, and isn't quietly making the system harder to evolve six months from now.<br>My hunch is that the next generation of developer tools won't win by generating code a little faster. They'll win by reducing uncertainty. The teams that move quickest won't necessarily be the ones producing the most code. They'll be the ones that can understand, validate and trust changes without asking humans to inspect every line of every diff.<br>That’s the shift I’m interested in.<br>Not replacing code reviews, but changing what we spend our time reviewing.
Artificial Intelligence
Software Development
Coding
Software Engineering
Written by Ben Northmore<br>0 followers<br>·1 following
Help
Status
About
Careers
Press
Blog
Store
Privacy
Rules
Terms
Text to speech