Claude Code pull requests get merged 83.8% of the time versus 91% for humans

Over the past few months developers have been writing code with agents en masse — autonomous LLM-based assistants that plan their own steps, make the changes, run the tests and open a pull request on their own. In theory that saves hours of routine work. In practice there is still little data on how such PRs fare inside real projects: which tasks agents take on, how often their PRs are accepted, and how much humans end up reworking. The authors studied 567 PRs from Claude Code across 157 open source repositories and carefully compared them with 567 PRs written by humans in the same projects at roughly the same time.

The agent on the job

Claude Code can work with the file system, run commands, linters and tests, read a repository's history and open a PR marked Generated with Claude Code. This is not a chat handing out step-by-step suggestions but an autonomous loop that runs from planning to pull request. In real projects the quality swings: from tidy, targeted fixes to large submissions that need discussion and follow-up commits.

How the authors read the data

The researchers pulled PRs carrying the tool's marker through the GitHub API for February–April 2025, then found matching human PRs in the same repositories, and where possible from the same authors — which makes the comparison fairer. Part of the sample was additionally labeled by hand by purpose (bug fix, feature, refactoring, documentation, tests and so on), and the size of the changes was measured. The statistics use non-parametric tests.

What agent PRs actually do

Humans and agents alike most often fix bugs and add small features. But agents show a clear shift: they take on refactoring, documentation and tests substantially more often. Multi-purpose submissions are almost four times more common for them: one PR changes the code, adds tests and updates the README all at once. The median size in files is the same (2 files), but agent PRs add twice as many lines (48 against 24), and their descriptions are longer and better structured (a median of 355 words against 56 for humans). That helps review, though it sometimes hides needless complexity.

Agents often drag build or linting updates along with them — useful when a project needs tidying up, risky when it breaks the pipeline. In one case the build was kept alive by temporarily loosening the linter while a proper fix was being prepared.

Do these PRs get accepted?

On average, yes. Agent PRs are accepted 83.8% of the time, human ones 91.0%. Time to merge is close in both datasets: about an hour. Where do agents get turned down? Usually for contextual reasons: the maintainers already have an alternative fix, the PR came out too large, or the submission was a technical check for CI. Purely technical shortcomings come up less often, and outright distrust of AI only now and then. Rejected PRs frequently get no feedback at all, though, so unspoken skepticism is possible.

How much rework they need

About half of both groups are merged with no further commits after the first. When rework is needed, its scale does not differ statistically between agents and humans: a median of two revision commits, with similar increments in files and lines. Put differently, you can have an agent prepare the opening PR without adding load to the review team.

Which changes reviewers ask for most

In almost half of the accepted agent PRs, reviewers ask for more work on bugs and error handling. Documentation comes second: bringing comments, the README and examples back in line with the changed code. Then refactoring and style: removing duplication, consistent naming, linters. Tests are added in one in six such PRs — usually coverage for corner cases the agent missed. Rarer but important: changes to CI/CD and targeted performance optimizations. Tellingly, 41% of the reworked agent PRs were reworked with Claude Code as well — developers use the assistant not only at the start but through the iterations.

A few live illustrations from the sample: in one project the agent raised test coverage from 70% to 94%, in another it sped up queries, and elsewhere it turned in a clean parser refactor. There were cases going the other way too — submissions that were simply too large, or small build incompatibilities that took manual intervention.

What this means in practice

• Split large tasks up. Agents tend to bundle several goals into one PR — convenient, but it complicates review and raises the odds of rejection. A series of small, self-contained submissions works better.
• Write the project's rules down for the agent. A dedicated file with style conventions, architecture and constraints saves dozens of review comments.
• Give reviewers something to check against. Along with the code, ask the agent for a list of assumptions, alternatives and known edge cases — review goes faster that way.
• Automate the routine around PRs. Rebases, small conflicts and the fight with stale status are a good fit for an agent.

The bottom line

Writing code with AI agents has stopped being an experiment: four out of five agent PRs land in the main codebase. They bring refactoring, documentation and tests more often, they come with long, informative descriptions, and they take no more rework than human submissions. Human oversight stays critical all the same: it is people who defend the project's standards, its pipeline and its code quality. The best arrangement is the agent as implementer and co-author, the human as architect and reviewer.

Examples from the sample

• A bug fix in mattermost
• Test coverage growth in dumbql
• A documentation update in tyro
• A refactor in qlty

💾 Code