Most research on agent-written pull requests stops at the merge button: was it accepted, how fast, how many review rounds. This morning's arXiv list had a paper that keeps going past that point, and I think that's exactly where the interesting question is. A merged PR from an agent looks like finished work on the dashboard. The real question is what happens to it over the next thirty days, and who does the fixing when it breaks. Thesis: the merge isn't where the work ends, and increasingly the thing that comes back to fix it is the same agent.
What it does#
Who Finishes the Job? A Study of Follow-Up Fixes and Commit Authorship on AI Coding Agent Pull Requests by Wannita Takerngsaksiri, Nhat Duong and Scott Barnett follows 6,774 merged agent PRs from five agents (OpenAI Codex, GitHub Copilot, Devin, Cursor and Claude Code) across open-source repos with 500+ stars, taken from the AIDev-pop dataset. The baseline is 5,044 human PRs merged in the same repositories over the same period. For each merge they look for candidate follow-ups: a later PR in the same repo, merged within 30 days, tagged as a fix, that edits at least one non-boilerplate file the original PR touched. Each candidate is then labelled as a direct fix, a related touch or unrelated.
The methodology is what sets this apart from the pile of "agents write smelly code" studies. Two humans labelled a seed set (κ=0.77), then an LLM judge labelled the rest and matched human agreement (κ=0.78, 90% precision on direct fixes). They report odds with confidence intervals, split out time effects with Mantel–Haenszel stratification, and attribute fixes at both the PR level and the commit level. That last part is what lets them say who actually typed the fix, not just who opened the PR.
The key result#
The headline: merged agent PRs attract verified fixes at 1.62× the odds of merged human PRs in the same repos over the same period (95% CI 1.10–2.39, p=0.015). In absolute terms that's 4.5% of agent merges getting a verified fix within 30 days, against 2.3% for humans. Codex was highest at 5.5% and Claude Code lowest at 3.2%, though Claude Code had only 63 PRs in the sample. Half of that 30-day incidence shows up in the first week. The second result is the one I found more interesting: 69.6% of verified fixes to agent merges come from the same agent. Humans fix 27.4% and a different agent fixes 3%. Copilot fixes its own work 95% of the time. At the commit level, 76.4% of fix PRs are agent-authored end to end, which is a higher share than in the original merges (54.1%). The agents lean even harder on themselves in the cleanup than in the first pass.
Why it matters#
The first thing I'm taking from this is that "merged" is a weak success signal for agent work, and most of the dashboards and evals we build treat it as the finish line. If you run agents against your own repos, whether that's Claude Code in CI or background agents opening PRs from issues, you should track a 30-day follow-up fix rate per agent, per repo and per task type. It's cheap to compute from git history using exactly the heuristic in this paper (same files, fix-tagged, merged within 30 days), and it tells you something PR acceptance rate can't. It's also a much better reward signal than "tests passed" if you're tuning prompts, skills or sub-agent setups: an agent config that gets merged fast but pulls in fixes a week later isn't better, it's just pushed the cost downstream.
The self-fix finding changes how I think about ownership. Humans already fix their own code; the paper just shows the owner is now an agent. That's fine while the loop stays closed: the same agent config, the same context files, the same model. It gets awkward when the model is deprecated, the vendor changes, or the agent's memory of why it made a choice never existed in the first place. If 70% of your maintenance comes from a system with no durable memory of the original change, then the PR description, the commit messages and the spec it worked from are the only continuity you have. Spec-driven workflows earn their keep here: have the agent write down its intent and constraints in the PR, and point the fixing run back at the original PR and spec rather than letting it re-derive intent from the diff. The RQ4 result backs up the review point too. PRs that later needed fixes spent slightly less time in review and got fewer review comments. The problem isn't that reviewers argue too much. It's that they wave things through.
The caveats#
Absolute rates are small. The gap between 4.5% and 2.3% is statistically real, but it's roughly two extra fixes per hundred merges. That's worth tracking, not worth panicking over.
The fix-linking heuristic has blind spots. Fixes that land in different files, arrive after 30 days, or aren't tagged as fixes are missed, so both rates are floors. Codex commits aren't marked as agent-authored, which makes its self-fix and commit-share numbers conservative.
Author class isn't authorship. A human can prompt an agent to write the fix, or tweak an agent's commit. "Agent-authored" means who committed or marked the work, not who decided what to do.
Population scope. It covers popular OSS repos and five agents at a single point in time, with Claude Code and Cursor underpowered. Enterprise monorepos with stricter review may look quite different.
The takeaway#
What I'm filing away: merge rate measures whether reviewers let a change through, while the follow-up fix rate measures whether the change was right, and agent tooling mostly tracks the first. The self-fix pattern makes the agent's written intent (PR body, spec, commit messages) the real maintenance record, because the agent won't remember anything else. What I'm doing differently: I'm adding a 30-day "fix-after-merge" query to how I evaluate my own agent-generated PRs, and when I kick off a fix I'll feed the original PR and spec back in as context instead of just pointing at the bug.