The Pull Request Future in the Agentic Era

Problem Statement

The pull request hasn’t changed shape since GitHub introduced it in 2008: a diff, a thread, an approve button. What’s changed is who’s on either side of it. Increasingly, it’s agents proposing the diff, agents commenting on it, and humans wondering what their job in the middle is supposed to be now.

The optimistic case

Martin Monperrus’s The End of Code Review argues that LLM-based coding agents have crossed a threshold where “every stated goal of code review can be served by agents at lower cost and higher throughput,” and that routing AI-generated code through human reviewers is a mismatched integration model, too slow for agent output, too shallow to catch what matters.

It’s a deliberately blunt thesis, but it names a real pressure: review queues are becoming the bottleneck, not code generation.

What the data actually shows

Automated review isn’t free triage.

An ICSE 2025 study, Cihan et al., “Automated Code Review In Practice”, tracked 4,335 pull requests across ten projects. Comments got resolved most of the time, a real signal, but closure time went up, with only minor quality gains and a steady stream of faulty or irrelevant ones. Right now, automated review is a second reviewer who talks a lot.

The agents aren’t ready to grade their own homework either. Zhang et al.’s c-CRAB benchmark tested PR-agent, Devin, Claude Code, and Codex against real human-reviewed pull requests, finding they solve only about 40% of tasks, focusing on different things than human reviewers do. On the authoring side, SWE-Bench Pro raises the bar to long-horizon, multi-file tasks, resisting the contamination that made earlier numbers look rosier than reality.

Agents creating and reviewing PRs?

An intriguing finding is what review even means once agents write the code.

Duma et al., “These Aren’t the Reviews You’re Looking For” mined the AIDev dataset and found most AI-generated PRs receive no review at all, and when they do, the reviewer is often another agent, not a human.

Human involvement shows up as “agent steering” rather than line-by-line feedback.

Pair that with Huang et al., “More Code, Less Reuse”: AI-generated PRs show higher code redundancy than human-written ones, yet reviewers report more positive or neutral sentiment toward them, exactly the gap that lets technical debt accumulate unnoticed.

Worse code, better vibes.

So what does the PR actually become?

A very interesting and pragmatical approach is Kamalı et al., “Rethinking Code Review in the Age of AI”: restructure the review lifecycle into five stages (creation, augmentation, reviewer selection, AI-assisted review, retrospective), with humans repositioned as “supervisory operators of agents,” retained at decision points that need judgment, not every diff line.

That framing beats the “review is dead” and “nothing has changed” narratives alike. The research points to a transition, not a singularity:

1. The unit of trust is moving. From “did a human read every line” to “did the right gate catch the right class of problem,” with tests, verification, and human judgment applied selectively, not uniformly.
2. The redundancy and sentiment-gap findings are the near-term risk, not benchmark scores. Teams that let agent-generated PRs sail through because they look clean are accumulating the debt Huang et al. describe.
3. Review capacity, not code generation, is the constraint to plan around. If closure time is already growing, adding more agent-authored PRs makes the queue worse before an agentic pipeline helps.
4. The reviewer role bifurcates. Routine, verifiable work goes almost entirely to agents; humans concentrate on architecture, intent, and the decisions that need a name attached to them.
5. The highest-leverage human work moves upstream, to requirements. Hamblin et al., SpecBench tested LLM agents on real RFC processes from Kubernetes, React, Rust, TVM, and vLLM, spotting omissions and bad assumptions before code is written. Even the strongest model tested, GPT-5.4, hit only 44.4% accuracy, far below its code-generation scores. If agents judge what should be built worse than whether it’s correct, reviewing requirements protects best against a bad diff.

A flawed spec produces a technically clean PR that still solves the wrong problem, and no amount of downstream code review catches that.

The industry is already building this

The papers above mostly measure a capability gap. Several companies have already shipped what those papers gesture at, with real numbers behind it.

GitHub reports Copilot code review has processed over 60 million reviews, now touching more than one in five on GitHub (Griffiths, 2026). Its guidance echoes the findings above: agent code “appears clean but harbors hidden technical debt,” so the fix is procedural, an implementation plan and new tests required, automated review treated as a filter, not a replacement for judgment.

Uber’s uReview runs three specialized reviewers plus a validation stage against roughly 90% of its ~65,000 weekly diffs (Uber, 2025). Its comments get addressed in the same changeset 65% of the time, against 51% for humans, beating the reviewers it’s supposedly a lesser substitute for.

Stripe’s minions show full agent authorship in production: over 1,300 pull requests a week are, in Stripe’s words, “human-reviewed” but contain “no human-written code” (Stripe, 2026), on a payments platform moving over a trillion dollars a year.

Google’s 2025 DORA report is the reality check: 90% of developers use AI at work, but only about a quarter trust its output “a lot,” and AI amplifies a team’s existing practices rather than fixing them (Google Cloud, 2025).

AI doesn’t fix a team, it amplifies what’s already there.

– Google Cloud team

The manufacturing precedent

Software isn’t the first discipline to hit this problem. Manufacturing solved a structurally similar one decades ago: how do you assure quality on a line producing faster than any human can inspect? The answer was never “look at every part.”

Acceptable Quality Limit sampling (ISO 2859) accepts or rejects a whole batch based on the defect rate in a sample, not because any unit matters less, but because 100% inspection stops paying for itself once a process is stable. Statistical process control goes further, watching the process itself, so control charts flag drift before a defective part is even produced. Full inspection survives only where a miss is catastrophic and unrecoverable, like aerospace fasteners or implantable medical devices; everywhere else, trust sits in the process, with a human stepping in only when something drifts out of tolerance.

That maps onto Kamalı et al.’s framework above: agent-based review as automated gauging on every PR, full manual inspection reserved for genuinely catastrophic diffs (a security boundary, a data migration, a public API contract), not applied out of habit to every line. Insisting on 100% human eyeballs for AI-authored PRs looks like insisting on calipers for every bolt off a line already in statistical control.

The pattern isn’t unique to manufacturing. Auditors sample against a materiality threshold rather than tying out every transaction, scaled to risk, not volume. Radiology screening sits closer to the aerospace end: double-reading survives because a missed cancer is unrecoverable, but AI increasingly triages which scans need that second set of eyes rather than reading them all itself.

Routine volume gets an automated or statistical gate, human attention gets rationed by risk, and full manual inspection survives only where a miss can’t be recovered downstream.

Is a text diff the right format?

Everything above assumes the artifact under review stays fixed: a diff plus a paragraph of prose. That’s worth questioning.

The unified diff predates the pull request, built for a human reading line by line in a terminal. A free-text description bolted onto it is a convention, not a design: nothing forces the prose to map onto the diff, so every reviewer, human or agent, ends up reconstructing intent from scratch.

If requirements are where the leverage has moved, the diff and the requirement it satisfies should be linked structurally: a PR as a set of (requirement, change) pairs, where anything unattached is a flag by construction, the way DO-178C and ISO 26262 already require in safety-critical software. An agent generating a diff already has the requirement in context, so making that link explicit costs almost nothing. Schlathölter’s ReqToCode makes traceability a build-checked property of the code itself, and Akhavan et al.’s LinkAnchor recovers issue-to-commit links autonomously, since only 42.2% are correctly linked today. Neither is a gatekeeper agent, but together they’re most of the way there.

Abenhaim’s account of dismantling a core architectural invariant wires that idea all the way through: a 717,725-line production app, 189 files, with no human code review. The agent audited its own formal spec against the existing code for 14 cycles, implemented, then audited the implementation against the frozen spec for 17 more, catching 201 defects before a human ever ran the program. Three days, $2,430. One case study, but the (requirement, change) pairing pushed to its actual limit.

Zietsman’s “The Specification as Quality Gate” explains why that isn’t reckless: without an executable spec, an AI reviewer and the AI that wrote the code draw on the same training distribution, so the review checks code against itself, not against intent. His fix mirrors Abenhaim’s protocol, spec first, deterministic verification second, AI review reserved for the residual that’s left, a bounded target instead of everything.

Philipp’s Ada/SPARK study marks the ceiling: formal proof, a stricter oracle than any natural-language spec, discharged 49,280 proof obligations on cryptography and TLS/IKEv2 code at 20-40x lower supervision cost than hand verification. Even there, the prover alone missed faults human review caught, because “what an agent can be trusted to establish is bounded by the strength of its feedback.”

“No code review” turns out to mean no human reading the diff line by line, not no verification.

Beyond plain text: other pull request formats

The (requirement, change) pairing above only fixes the “prose” half of “diff plus prose.” The diff itself, a sequence of -/+ lines keyed to file and line number, is just as inherited, built for a person typing in a terminal. delta already makes that format easier to read, without changing what it represents. What follows changes the representation itself.

• Structural diffs. Line diffs render a rename or reformat as noise indistinguishable from a real logic change; tools like difftastic diff the syntax tree instead. An agent already has the AST, no reason to discard it.
• Executable claims, not just code. A diff says what changed, not what should now be true. Shipping a machine-checked assertion, like a property test or invariant, turns review into “does this claim hold,” a question agents already handle better than open-ended judgment.
• Impact-graph views. A three-line change to a shared utility and a leaf component look identical in diff size but not blast radius; rendering the dependency graph touched turns “small diff” into a real risk measurement. Graphite’s take on full-repo vs. diff context makes the same case from the review side: diff-only misses cross-module impacts, so its Diamond reviewer prunes by dependency instead of the whole repo.
• A different unit of change. Git’s commit isn’t inevitable: Google’s Jujutsu treats the working copy itself as a commit, cutting staging and rebase, and Meta’s Sapling builds stacked, reviewable commits by default. If version control’s unit can be rethought, so can review’s.

None of these replace the diff outright. A line-level view stays somebody’s ground truth. But they share one conclusion: the reason, the fact it still holds, and the scope of what it touches are all things an agent can hand over structured, almost for free, an opportunity a format built for a terminal was never designed to take.

Where this leaves us

The PR isn’t disappearing, but the diff’s claim to be the unit of review should.

Line-by-line reading was never the goal, it was the only tool available. Nobody actually cares that line 47 changed; they care whether the system still does what it’s supposed to do, and a human scanning a diff was how that question got answered when there was nothing better to check it against. Abenhaim, Zietsman, and Philipp arrive at the same alternative from three different angles: check the code against what it’s supposed to do, not against what a line looks like on a screen. That isn’t a weaker form of review. It’s the thing diff-reading was always a stand-in for.

Which makes “no code review” the wrong headline for what those papers are actually doing.

Nothing in that pipeline skips verification, it relocates it, off a human’s eyes and onto the one artifact that can be checked mechanically in both directions: the requirement. A change with no requirement behind it is a defect by construction, whether or not anyone ever reads it. A change that matches its requirement doesn’t get any safer for also having been eyeballed. Line-by-line reading earns its cost against the residual a specification can’t express, not as the default gate on everything that ships.

That’s the bet worth making now, ahead of any fully agentic review pipeline:

1. Wire requirement-to-code traceability into the merge path
2. Fail the build on an unlinked change
3. And save human reading for the residual, security boundaries, data migrations, whatever genuinely can’t be specified.

The infrastructure for that already exists. What’s missing isn’t capability, it’s the willingness to treat “a human read it” as a weak signal instead of the whole point.

Resources