Who actually reviews the pull requests AI agents write?

A 98.7% acceptance rate is not a compliment

Imagine a new engineer whose pull requests get merged 98.7% of the time. Not 90%, not 95% — one rejection in every 77. You would either promote them on the spot or start asking who is reading their code.

That is the acceptance rate of pull requests written by Claude Code on public GitHub in October 2026, in our measurement below. The public tracker LogicStar puts it at 96.3% since mid-2025, ahead of OpenAI Codex at 92.9% and of humans at 83.0%.[1] Now the other number. LinearB's 2026 benchmark — 8.1 million pull requests from 4,800 teams at companies — found that AI pull requests merge within 30 days 32.7% of the time, against 84.4% for unassisted work.[2]

Same families of models. Same kind of work. One dataset says agents are the most trusted contributors on GitHub, the other says they are the least. Both are right, and the gap between them is the whole answer to the question on this page. Merge rate is not a property of the code. It is what happens when code meets a reviewer — and a lot of agent code no longer meets one.

We wanted to see that directly, rather than infer it. So we went and counted.

What we measured

We pulled every hourly file from GH Archive, the public record of GitHub's event timeline, from 4 to 18 October 2026: 360 hours.[4] From those we kept every pull request being opened, merged or closed, and every review and review comment — 260,551 pull requests opened and 155,226 reviews, across public repositories.

Agent pull requests were classified the way the public trackers do it, by the branch the agent pushes to: claude/, codex/, cursor/ and copilot/.[1] Dependabot and Renovate were split out as dependency bots. Everything else — overwhelmingly people, plus a long tail of other automation — is the baseline.

One honest caveat shapes every number on this page. The archive has only ever been what GitHub's public event feed hands out, and in 2026 that is a thin slice; since late 2025 the events also carry less detail, so a merge event no longer says who wrote the pull request.[5] We checked how thin: of merges we saw, only about 2% had their opening event in the archive too, and that capture rate was the same for every class — everything else 2.0%, Claude Code 2.0%, Codex 1.9%, Cursor 1.9%, with only slow-to-merge dependency bots lower at 1.5%. So this is a large, evenly sampled slice, not a census. Absolute counts mean little; ratios between classes, sampled the same way at the same moments, mean a lot. Every figure here is a ratio.

One pull request in seven now comes from an agent

In the two weeks we measured, 14.5% of all pull requests opened on public GitHub came from an agent's branch. Claude Code alone accounted for 8.4%, followed by Codex at 4.5%, Cursor at 1.4% and the Copilot coding agent at 0.2%. Leave out dependency bots and it is one in six.

Eighteen months ago that line was flat on the floor: 0.2% in April 2025. codex/ branches arrived in June 2025 and pushed it to 9.5% almost overnight; claude/ branches went from 0.5% of pull requests in October 2025 to 5.1% a month later and 7.9% now. To make the trend we sampled six hours on the 5th, 15th and 25th of every month back to April 2025, so read individual months loosely and the slope seriously. One detection caveat: the Copilot agent's share falls through 2026 in our data, which may mean it changed how it names branches, so treat its numbers as a floor.

Nobody says no

Here is the chart that made us stop and re-run everything. Of finished Claude Code pull requests, 1.3% were closed without merging — one in 77. Codex: 2.4%. Cursor: 3.6%. The baseline of everything else: 6.3%, five times Claude Code's rate.

The bar at the top needs a footnote before anyone quotes it, because we nearly did. We checked who closed those dependency pull requests: 83% of the closures were Dependabot or Renovate closing their own superseded updates. Count only closures by a person and people turn down a dependency bump about 3.6% of the time — still almost three times as often as they turn down a Claude Code pull request, which arrives under their own name.

The exception that matters is in the second bar. The Copilot coding agent is rejected 11.4% of the time, the most of any agent and nearly twice the baseline. It is also the one agent whose pull requests GitHub treats as somebody else's work: they are opened by the Copilot account, and where approvals are required, the developer who asked Copilot for the change does not count as its approver — so another person has to look.[6] That is not proof of cause — Copilot's pull requests are few and land in different repos — but it points the same way as everything else here. Where a second person is structurally required, agent pull requests start getting rejected like anyone else's.

The change requests tell the same story more sharply. Across all repositories, people asked for changes on Claude Code pull requests about eleven times less often per merge than on everything else: 0.0016 change requests per merge against 0.0170. Codex drew about half the baseline, Cursor a sixth.

The author became the reviewer

There is a mechanical reason this happens, and it is not laziness.

When you run Claude Code on the web, Codex or Cursor's background agent, the pull request is opened under your own GitHub account. To GitHub, to your branch protection, and to every engineering dashboard that counts pull requests per person, it is your work. But you did not write it. You asked for it, which makes you — functionally — its first reviewer.

That quietly deletes a role. The old loop had an author who understood the code because they wrote it, and a reviewer who did not, and who therefore had to read it. The new loop has a prompter who neither wrote it nor is structurally required to read it, and in most repositories nobody else. One person, twice. It is also why "our PR volume doubled and nobody can tell why" is such a common complaint: the volume is real, it is just attributed to people who did not write it. Faros measured the downstream end of this on teams with high AI adoption — 98% more pull requests merged, review time up 91%, and no improvement in delivery at company level.[8]

"Maybe they're just better"

That is the obvious objection, and it deserves a real test rather than a shrug. Agent pull requests tend to be small and tightly scoped. Solo developers prototyping on their own repos have no one to reject anything. Maybe 98.7% is simply what small, well-scoped work by a strong model looks like.

So we split the data by how many people we saw in each repository.

Two things came out, and the objection survives only half of them.

It is partly true. 95.4% of Claude Code pull requests landed in repositories where we saw just one person in two weeks, against 84.3% for everything else. A lot of agent output is people building things alone, where there was never a second reviewer to lose.

It is not the whole story. In busy repositories, where we saw three or more people, Codex pull requests were reviewed about as heavily as everyone else's — 0.62 approvals per merge against 0.77, and the same rate of change requests. Teams can review agent code normally. But Claude Code pull requests in those same busy repositories got 0.31 approvals and 0.04 change requests per merge — less than half the approvals and a third of the pushback. The sample there is small, a few hundred merges, so treat it as direction, not decimals. The direction is not ambiguous.

And quality is not the reason the scrutiny is lower. CodeRabbit's comparison of 470 open source pull requests found AI-coauthored changes carried about 1.7 times as many issues as human-only ones, with readability problems more than tripled.[10] METR's randomised trial found experienced developers 19% slower with AI tools while believing they were 20% faster — a reminder that how a change feels to the person who asked for it is a poor guide to what it is.[12] When agent pull requests do get rejected, 67.9% of the time nobody writes down why.[11]

A Carnegie Mellon team studying the same question this year found that the answer flips depending on which repositories you include — agent pull requests in repos with ten or more stars were reviewed about as often as human ones by early 2026.[9] That is consistent with what we see, not in tension with it. Where there is a team, review mostly survives. The trouble is that most agent work is not landing where there is a team.

The robots reviewing the robots

If agents write one pull request in seven, who reviews them? Increasingly, other agents.

AI review bots wrote 37% of all review events in our two weeks. GitHub's Copilot reviewer alone wrote 12.6% — one review in eight on public GitHub — followed by CodeRabbit at 8.6% and the Codex connector at 6.5%. People wrote 51.9%. In April 2025 the bots' share was 11.7%; it passed a third in February 2026 and has stayed there since.

The catch is what kind of review it is. 92.6% of AI bot reviews were comment-only. 3.6% were approvals and 2.7% requested changes. Human reviews, by contrast, were approvals 28.8% of the time. That is not a flaw in the bots; it is the design. GitHub's documentation states that Copilot leaves a Comment review by default, and that it does not count toward required approvals.[7] LinearB even finds that pull requests with AI code review merge at the highest rate of any category in its 2026 data.[3] AI review adds information. It does not add a second person who can say no — and nobody should pretend the comment count is a review count.

Run this on your own repositories

You do not need our archive to find out whether this is happening to you. The GitHub CLI already exposes everything needed: the head branch, who opened it, who merged it, and every review. Save this as agent-review.jq:

def bot: test("\\[bot\\]$|^app/|^(Copilot|coderabbitai|copilot-pull-request-reviewer|github-actions|cursor|claude|chatgpt-codex-connector|gemini-code-assist|greptile-apps)$");
map(select(.headRefName | test("^(claude|codex|cursor|copilot)/")))
| map(. as $pr | {
    pr: .number, branch: .headRefName, merger: .mergedBy.login,
    minutes: (((.mergedAt | fromdate) - (.createdAt | fromdate)) / 60 | floor),
    approvals: [.reviews[] | select(.state == "APPROVED") | .author.login
      | select(bot | not) | select(. != $pr.author.login)
      | select(($pr.author.login | bot | not) or . != $pr.mergedBy.login)] | unique | length })
| (map(select(.approvals == 0)) | length) as $alone
| "\(length) agent-branch PRs merged, \($alone) with no human approval beyond the person who asked for them",
  (.[] | select(.approvals == 0) | "  #\(.pr)  \(.branch)  merged by \(.merger) after \(.minutes) min")

Then run it against any repository you can read:

gh pr list -R your-org/your-repo --state merged --limit 500 --json number,headRefName,author,mergedBy,createdAt,mergedAt,reviews | jq -r -f agent-review.jq

It lists every merged agent pull request that no human other than the requester approved, with who merged it and how many minutes it lived. AI bot approvals are not counted, and for Copilot's own pull requests neither is the merger's — mirroring GitHub's rule that the person who asked Copilot cannot be its approver. We tested the filter against fixtures covering each case: self-merged Claude Code work, a Codex pull request approved by a colleague, a Copilot pull request approved only by the person who requested it, and a human branch that should be ignored.

The number to look at is not how many there are. It is your agent rejection rate next to your human one. If people on your team reject each other's work 6% of the time and the agents' work almost never, that gap is not the model being good. It is the review missing.

What to actually do on Monday

1. Tag agent work by branch prefix, everywhere you measure. claude/, codex/, cursor/, copilot/. Until you do, every productivity chart you have counts agent output as human output, and every "PR volume doubled" conversation starts from a false premise.
2. Require one approving review on your default branch, for every repository that ships. Because Claude Code and Codex open pull requests as the prompter, GitHub's ordinary rule — authors cannot approve their own work — then forces a second person, for free. It only works if the rule is on; on most public repositories it is not.
3. Turn on "require approval of the most recent reviewable push." Agents push again after review comments. Without this, an approval given to version one merges version three.
4. Let AI review comment, never gate. Keep it as a pre-filter that catches the obvious so humans read the interesting parts. Do not count its comments in your review metrics.
5. Watch the ratio, quarterly. Agent rejection rate against human rejection rate, and approvals per merged agent pull request. A healthy team should see them converge. A near-zero agent rejection rate is a finding, not a win.
6. Cap agent pull request size. In LinearB's data, agentic pull requests at the 75th percentile were 293 lines against 157 for unassisted work, and waited 17.6 hours to be picked up instead of 3.4.[2] A pull request nobody can review in fifteen minutes is a pull request nobody reviews.

The one-line version

On public GitHub in October 2026, one pull request in seven was written by an agent, a third of all reviews were written by bots, and Claude Code's pull requests were rejected once in 77 times — because the person who used to be the author is now the reviewer, and usually the only one. The model did not make your review process obsolete. It made it optional, and most people took the option. If you want someone to find where that has happened in your codebase before an incident does, that is a large part of what the readiness audit looks for — and the AI slop security audit is what to do with the code that already merged.