A merged pull request is where most measurement of coding agents stops. It got reviewed, it got merged, it counts. A team at Deakin University followed merged agent pull requests across hundreds of popular open-source repositories into the later pull requests that came back and corrected them, against human-written merges in the same repositories over the same months.
Agent merges attracted a verified follow-up fix about 1.6 times as often as human merges in the same repository. The absolute rate is small on both sides. Fewer than one in twenty merges came back inside a month, so this is a consistent gap rather than a dramatic one.
"Therefore, over the same period of time, an agent merge is roughly 1.6 times as likely as a human merge in the same repository to be followed by a verified fix."
Then the authorship question. About seven in ten of those fixes were written by the same agent that shipped the original merge, and when an agent opened a fix, it wrote nearly every commit inside it. Humans do the same with their own merges, and slightly more consistently. A quarter of the cleanup after an agent merge still landed on a person.
The part that should bother anyone running a review process is what didn't show up. Nothing visible at merge time separated the merges that later needed fixing from the ones that didn't. Time under review, review comments, churn after the first push all had near-identical distributions. If anything the merges that came back had slightly less review attention, which is no use at all as an early warning. One thing did survive comparison within a single repository. Merges that had taken many rounds of commits to land were markedly more likely to need more work afterwards. The authors read this as evidence that the warning sign lives in the code rather than the pull request's metadata. Their design can't test that, though, because they never read the diffs looking for it.
There's a limit to what this establishes. The study counted who authored each fix, not whether the fix worked. Nobody checked whether the self-repair was correct, or whether the same code came back a third time. "Agents finish their own job" describes who does the labour, not whether the problem got solved.
"Agents largely finish their own job on both sides of the merge, but their merges need fixing modestly more often than human merges, with little visibility up front."
The figure most likely to be over-read is that 1.6. Taken as a quality verdict it says agent code is worse. The gap is modest and the blindness is total, because no team can spot at merge time which agent work is coming back. So a vendor reporting merged pull requests as its outcome metric is quoting the wrong finish line. Ask for the thirty-day follow-up fix rate instead, and whether anyone tracks it.
Ownership is where this lands. The researchers note that when a human owner moves on, a colleague has usually absorbed enough of the code to inherit it, while an agent that ships a merge and then repairs it alone leaves nobody behind who understands the work. On this evidence, agent-owned areas deserve what a team gives a CODEOWNERS file. Write down which agent works where, and treat a model deprecation or a downgrade to a cheaper tier as closer to a senior engineer resigning than a config change. And that quarter of fixes reaching a human isn't a rounding error. It scales with agent volume, so a team tripling its agent output should plan for triple the cleanup.
Sources
- Takerngsaksiri, W., Duong, N., Barnett, S., "Who Finishes the Job? A Study of Follow-Up Fixes and Commit Authorship on AI Coding Agent Pull Requests" — https://arxiv.org/abs/2609.26847