This blog has spent seventy-odd articles on how review works today. This one is about the future of code review, and it is the closest thing we have to a thesis statement. The short version: generation got cheap, verification did not, and everything that happens next in this discipline follows from that one inversion. What follows is where we think review lands, stated as bets with conditions that would prove us wrong, because predictions without falsifiers are just marketing.
The inversion already happened
This is not a forecast; it is the recent past. AI writes code faster than you can review it, and the numbers behind that sentence (adoption near three quarters of developers, output multiplied, unreviewed merges climbing) are on our statistics page with sources attached. The industry spent two decades optimizing how code gets written and about two sprints noticing that review capacity is fixed while authorship capacity is not. Review did not get worse. It got outnumbered. The evidence of the overflow is visible in the plainest metric there is: changes merging with no review at all, rising, while every study of what review delivers says its value concentrates exactly where volume is highest.
The surface is catching up
For fifteen years the review surface was a solved-enough problem nobody competed on: a diff, a comment box, a green button. That era is over. GitHub added stacked pull requests, in public preview for every repository since July 2026, per InfoWorld’s April 2026 report, with GitHub itself conceding that large pull requests are hard to review. When the default platform admits the default experience fails at scale, the whole category gets permission to try harder: stacking tools, guided surfaces, triage-first viewers. The surface stopped being neutral territory and became the competition. Expect the next round of improvements to be unglamorous and structural: interdiffs that survive a force push, review state that persists between visits, queues ordered by risk instead of recency. None of it demos as well as a chatbot, and all of it moves the number that matters, which is how long a change waits for a qualified human read.
AI settles into triage, not verdicts
The first wave of AI review tried to be a reviewer: post comments, render judgments, summarize everything. The measured results (a large linter-grade share, confident wrong answers, and reviewers tuning bots out) pushed the field toward a narrower and better job: ordering, filtering, flagging, and routing, with humans reading the code itself. The constraint is attention. Every generated paragraph competes with the diff for the same scarce reviewer focus, and alert fatigue is what happens when tooling loses sight of that. Full disclosure, this is the bet our own product makes: Pyor’s AI groups review-worthy changes apart from the noise, labels the groups, and points, rather than narrating. We may be wrong; the falsifier is below.
Humans keep judgment and accountability
Two things do not delegate. Judgment: does this change match intent, fit the system, and deserve to exist? An agent author cannot answer that, because the author cannot explain itself. And accountability: someone answers for the change in production, and that someone has a name, not a model number. The stable pattern looks like a human on the loop: automation handles volume, sampling replaces exhaustive reading on low-risk tiers, and the merge stays a human act. Teams that let the bot’s approval become the approval are not automating review; they are discontinuing it quietly. The interesting design work of the next few years is drawing that line well: which tiers of change earn a full human read, which get sampled, and which ship on automated gates alone, decided deliberately rather than by whoever burned out first.
Five bets on the future of code review
Held loosely, checkable in two years, and each with the condition that would prove it wrong. We would rather be specific and mistaken than vague and unfalsifiable.
- Stacking goes mainstream by 2028. Native platform support makes small chained PRs the default for new changes at most large shops. Falsifier: stacked PRs stay a power-user niche.
- AI review consolidates into triage. Winning tools order and filter; prose-heavy summarizers shrink to a niche. Falsifier: narration-first tools dominate adoption two years from now.
- Provenance becomes a required field. Who or what wrote this, under what prompt, checked how: recorded on the PR as routinely as CI status. Falsifier: major platforms still have no authorship-provenance primitive by 2028.
- Review latency becomes a tracked SLO. Turnaround gets measured like uptime, because unreviewed queues are where the defect numbers grow. Falsifier: review time stays absent from mainstream engineering metrics suites.
- Zero-review merges keep rising before they fall. The uncomfortable one: things get worse until a visible incident makes verification fashionable again. Falsifier: unreviewed-merge rates decline steadily from here.
The durable skill
Close the arc where it started. Addy Osmani’s line, which we have quoted before because it deserves it: reading code has always been the skill, and it is about to be the skill. Languages and frameworks churn; the ability to open an unfamiliar change, reconstruct its intent, and decide whether to trust it is the part of this craft that compounds. Everything on this blog, and honestly everything in this product category, is scaffolding around that act. The future of code review is not fewer humans reading code. It is humans reading code with the leverage they should have had all along, and owning the merge when they are done.
Frequently asked questions
Will AI replace code review?
It will replace parts of it: the mechanical first pass, the style policing, the obvious-bug sweep. It will not replace the part that was always the point: a human deciding the change matches intent, fits the system, and is worth being accountable for in production. The evidence so far shows AI shifting review work, not removing it.
What skills will code reviewers need in the future?
Reading unfamiliar code fast, reconstructing intent that was never written down, judging blast radius, and triaging automated findings without drowning in them. Line-level defect spotting matters less as automation absorbs it. Osmani puts it sharply: reading code has always been the skill, and it is about to be the skill.
Is code review becoming more or less important?
More. When code was expensive to write, review guarded a scarce resource. Now code is cheap to generate and expensive to trust, so review became the bottleneck and the value gate. Every trend line, from rising unreviewed merges to rising churn, is an argument for better review, not less of it.
