← Back to blog

Code Review for Coding Agents: When the PR Author Is Not Human

Coding agents now take a ticket and open the pull request themselves - which makes review the first human contact with the code. The four policy decisions that make agent-authored PRs safe to merge, the failure modes to review for, and how to keep the queue and the bill under control.

8 min read
Code Review for Coding Agents: When the PR Author Is Not Human

A new kind of author opens a pull request

Somewhere in your organization this quarter, a pull request was opened by something that was never hired. Assign an issue to GitHub Copilot's coding agent, hand a ticket to Claude Code or Codex running in a cloud sandbox, and the loop closes without you: the agent reads the task, writes the code, runs the tests, and opens a PR with a tidy description — then answers your review comments. The first time a human reads the change is in review.

This is a different situation from the one most teams wrote their review policy for. We covered the volume problem of AI-assisted authorship in our post on reviewing AI-generated code: humans writing more code, faster, with assistants. Agent-authored PRs are a step beyond that — there is no human author at all, only a human who dispatched a task. Most review policies simply have nothing to say about this, and teams are improvising the rules one awkward merge at a time.

Why agent PRs are not just more AI-generated code

Three things change when the author is an agent rather than a human with an assistant:

  • The reviewer is the first human reader. With assisted authorship, the human author at least skimmed what they committed. With an agent PR, review is the first and only point where a person verifies the change before it ships. Whatever your review bar was, it is now carrying the entire weight of human verification.
  • The intent lives upstream, not in the PR. The PR description was written by the same model that wrote the code — it is the code's account of itself, fluent and plausible by construction. The actual source of truth is the ticket or prompt the agent was given. Reviewing the diff against its own description is circular; you have to review it against the task.
  • Reviewers hesitate, and it shows in the queue. LinearB's 2026 Software Engineering Benchmarks Report found that PRs authored by agentic AI wait roughly five times longer for review pickup than unassisted PRs. Nobody wants to be the human who vouched for the robot's change — so agent PRs sit, and the throughput the agent bought you evaporates in the queue. Early research comparing agent-authored changes with human ones also reports more redundancy and more technical debt per change, which makes the hesitation rational.

Four policy decisions to make before you scale agents

Teams that run agents successfully did not get better agents — they wrote a clearer review contract. It comes down to four decisions:

  • 1. Make provenance visible. Agent PRs should be unmistakable: a dedicated bot account, a branch prefix, a label. Reviewers calibrate differently for a colleague with five years of context than for a model with none, and they can only calibrate if they know. Hiding agent authorship behind a human's account is how trust incidents start.
  • 2. Every agent PR gets a human sponsor. The person who dispatched the task owns the PR: they answer for its intent, they respond when it breaks, and their approval means a human vouches for the change. An agent PR with no named sponsor should not be reviewable, let alone mergeable. Accountability does not delegate to software.
  • 3. Scale review depth with risk, not just authorship. A dependency bump authored by an agent does not need a committee; an auth change authored by an agent needs more scrutiny than the same change from your staff engineer, because there is no author judgment behind it to lean on. Route depth by blast radius, with authorship as a multiplier.
  • 4. Decide where agents may not go. Most teams converge on a deny-list: authentication, payments, database migrations, CI configuration. Changes there either reject agent authorship outright or auto-escalate to senior review. Write the list down — an unwritten deny-list is discovered only after it is violated.

Reviewing the diff itself

Agent-authored diffs fail in characteristic ways, and knowing them makes review faster. Check the change against the ticket, not the description — agents are excellent at doing something adjacent to what was asked, cleanly. Treat the tests as part of the claim rather than evidence for it: an agent will happily write tests that assert what the code does instead of what the task required, and a green suite proves nothing if the assertions are circular. Hunt for duplication, because agents recreate helpers the codebase already has. And watch for scope creep: drive-by refactors and formatting churn that widen the diff and bury the part that matters.

The first pass should be a machine's

Here is the arithmetic problem: agents multiply PR volume, and human attention does not multiply with it. If every agent PR needs deep human review from the first line, agents make your team slower — the queue data already shows it happening. The layered answer is the same one that works for assisted code, applied more strictly: an AI first pass sweeps every agent PR for correctness, edge cases, duplication, consistency with the surrounding codebase, and the security patterns AI review catches well — and the human sponsor reviews intent, architecture, and whether the change should exist at all. Machines verify mechanics at machine volume; humans spend their attention where judgment lives.

This is the workload PURA was built for. Routing rules written in plain English in repo-committed review skills — the same reviewable-policy-in-the-repo pattern the AGENTS.md convention made normal — decide how each PR is reviewed: route agent-authored PRs to premium models with strict instructions while human PRs in low-risk paths stay lean. Because agents can open a dozen PRs before lunch, per-author budget caps matter more than ever: a runaway agent becomes a paused budget, not a five-figure API bill. And since unmerged agent branches are still your unreviewed source code, self-hosted deployment keeps the whole loop — agent output and review both — inside your own infrastructure.

Accountability is the part you cannot automate

Coding agents will keep getting better at authorship. What they cannot get better at is being accountable — that stays with whoever clicks merge. The teams getting real leverage from agents in 2026 are not the ones with the most autonomous pipeline; they are the ones where every agent PR arrives labeled, sponsored, machine-checked, and scoped away from the code that can hurt them. Get the review contract right, and the new author on your team is the most productive junior you have ever onboarded. Skip it, and you have merely automated the writing of code nobody is responsible for.

Frequently asked questions

Should agent-authored pull requests be reviewed differently than human PRs?
Yes. With an agent PR the reviewer is the first human to read the code at all, and the PR description was written by the same model that wrote the diff - so review must verify the change against the original ticket or prompt, not against its own description. Provenance should be visible (bot account, label, or branch prefix), and review depth should scale with the blast radius of the change, with agent authorship treated as a risk multiplier rather than a pass.
Who is accountable for a pull request written by a coding agent?
The human who dispatched the task. A workable policy names that person as the PR sponsor: they answer for its intent, respond when it breaks, and their approval means a human vouches for the change. An agent PR with no named human sponsor should not be mergeable - accountability does not delegate to software.
Does it make sense to have AI review code that an AI agent wrote?
Yes, as the first layer. Agents multiply PR volume while human attention stays fixed, so an AI first pass sweeps every agent PR for correctness, duplication, edge cases, and security patterns at machine volume, and the human sponsor concentrates on intent and architecture. The two layers fail differently: the reviewer model reads the change cold, with no stake in the description the authoring agent wrote for itself.
How do teams keep coding agents from overwhelming review queues and budgets?
Two controls. First, route by risk: send agent PRs in sensitive paths to premium models with strict instructions while routine changes get lean review - in PURA this is a plain-English rule in the agent’s review skill. Second, cap spend structurally: per-author budgets turn a runaway agent that opens a dozen PRs before lunch into a paused budget instead of a surprise API bill.

Ready to put your AI review spend on rails?

Install PURA on your GitHub repos and start setting budgets in minutes — not months.

Install PURA for free