Coding agent PRs are now part of real engineering work. Claude Code, Codex, Copilot, Devin, and Cursor can open patches, respond to feedback, and try to fix CI. The failure mode is subtle: an agent PR can look clean and still be expensive to review.
In 2026, an MSR/arXiv study analyzed 33,596 agentic GitHub PRs and found 24,014 merged, or 71.48% of the total (arXiv, "Where Do AI Coding Agents Fail?", 2026). The useful question is not whether agents work. It is why many PRs still die before merge.
Practical summary
- Agentic PRs should arrive small, tested, and scoped.
- Reviewer abandonment, duplicate work, and broken CI are rejection patterns.
- Subagents help when they review separate signals, not when they add more narrative.
- A good agent PR saves human judgment; it does not outsource responsibility.
Why do coding agent PRs fail before merge?
In 2026, "Where Do AI Coding Agents Fail?" analyzed 33,596 PRs from five agents across GitHub projects with more than 100 stars (arXiv, 2026). PRs fail when broad scope, fragile CI, and weak maintainer coordination combine.
The practical finding is clear. Documentation, CI, and build tasks had the best merge rates, while performance and bug-fix work performed worse. That tracks with review reality: localized maintenance is easier to verify, but bug and performance changes need product context, regression proof, and acceptance criteria.
The study also found that unmerged PRs tend to touch more files, change more lines, and fail more CI checks. For a reviewer, that changes the cognitive cost. They are not just reading code. They are reconstructing intent, boundaries, impact, and evidence.
This builds on PR evals that hold coding agents in CI. Evals measure the patch. Here, the earlier question is how to package the PR so it deserves review.
Citable capsule: Coding agent PRs fail when they arrive as too much package to trust. The 2026 MSR/arXiv study analyzed 33,596 agentic PRs and linked non-merge outcomes with larger changes, more touched files, and more CI failures.
What must the PR prove before review?
In 2026, GitHub said Copilot code review had processed more than 60 million reviews and that more than one in five GitHub code reviews involved an agent (GitHub Blog, "Agent pull requests are everywhere", 2026). Volume without evidence becomes queue pressure.
An agent PR must prove four things before tagging a reviewer. What behavior changed? Why is the scope limited? Which commands ran? What risk still needs human judgment? Without those answers, the reviewer becomes a debugger of intent.
Do not accept a PR body that only says everything was implemented. Ask for compact evidence: command, summarized output, critical file, and negative case. If the task fixes a bug, the test should fail before the fix. If it adds a feature, the PR should show limits and unsupported behavior.
This fits the coding agent harness for reliable PRs. The harness defines the contract. The PR proves the contract was followed.
| PR evidence | What the reviewer decides |
|---|---|
| Declared scope | Whether the diff matches the original task. |
| New or existing test | Whether the change can be verified without faith. |
| CI output | Whether the agent broke the basic path. |
| Residual risk | Whether security, data, or infra review is needed. |
Citable capsule: An agent PR is review-ready only when it carries intent, scope, commands, and residual risk. GitHub reports tens of millions of Copilot reviews; at that volume, review without evidence moves cost to humans.
How do you reduce reviewer abandonment without blind trust?
In 2026, the qualitative study categorized 562 accessible rejected PRs; abandonment or lack of meaningful review appeared in 228 cases, about 38% (arXiv, "Where Do AI Coding Agents Fail?", 2026). The PR dies when no one sees enough value to enter the diff.
Abandonment is not just maintainer laziness. In a busy project, a broad, unplanned agent PR competes against human work with social context. If the patch looks experimental, duplicate, or generic, it loses priority before technical review begins.
The fix is less ambiguity. Open small PRs. Point to an issue or requirement. Declare files out of scope. Confirm that similar PRs were searched. If the agent generated several alternatives, do not push all of them to the maintainer. Choose one and explain why the others were dropped.
In the study, duplicate work appeared in 142 rejected PRs, or 23% of the categorized sample. That is a hard lesson for agents: they can write fast, but they do not always know that equivalent work is already open. Search issues, branches, and PRs before opening the patch.
Practical note: I treat an agent PR without a plan as an internal draft. I request review only when the diff tells a short story: problem, boundary, evidence, and pending question. If the pending question is "can you understand all of this?", the PR is not ready.
Where should CI and tests block the patch?
In 2026, the study found CI or test failure in 99 of the 562 categorized rejected PRs, about 17% of the sample (arXiv, "Where Do AI Coding Agents Fail?", 2026). CI should block red tests and attempts to weaken verification.
GitHub recommends treating any CI weakening as a hard stop in agent PRs. That includes removed tests, skipped lint, reduced coverage, workflows that no longer run on PRs, and commands that pass even when the underlying step fails (GitHub Blog, "Agent pull requests are everywhere", 2026).
The minimum gate should verify three things. First, test integrity: no test removed, renamed, or skipped without justification. Second, relation to the task: a bug fix needs a reproduction test. Third, scope: sensitive files require the right reviewer.
For backend and DevOps, mark high-risk areas. Authentication, billing, personal data, migrations, queues, CI workflows, infrastructure, and permissions should not pass with agent approval alone. The PR may be correct, but the cost of being wrong is higher.
Citable capsule: CI for agentic PRs must catch broken tests and weakened tests. The MSR/arXiv study found CI or test failure in about 17% of categorized rejected PRs, and GitHub recommends blocking any change that reduces verification.
How can subagents help without multiplying noise?
In 2026, Codex documentation says subagents help with parallel tasks such as codebase exploration or multi-step feature plans, while warning that they consume more tokens than a single-agent run (OpenAI, "Subagents", 2026). Use subagents to separate observation, not to inflate authorship.
A good subagent reviews one signal. One checks tests. Another checks security. Another checks scope. Another compares requirement and diff. The main agent consolidates, but it should not hide disagreement. If the security subagent blocks, the PR should carry that block.
Claude Code documentation lists benefits such as preserving context, limiting tools, and specializing behavior with focused prompts (Anthropic, "Create custom subagents", 2026). That matters because agent PRs fail when reviewers get too much context or the wrong context.
When a PR spans multiple sessions, subagents, and evidence without dumping the whole history into the main prompt, I use RemoteCode as the author's tool for taking Claude Code and Codex farther in agentic flows with less context waste. It helps coordinate the work; it does not replace review, CI, or security gates.
This matches subagent fan-out for migrations without losing control. Fan-out helps only when each output has a short format, severity, file, and next action.
Citable capsule: Subagents improve coding agent PRs when they reduce context for the reviewer. Codex documents subagents for parallel tasks and token tradeoffs; Claude Code highlights isolated context and tool restrictions as practical benefits.
What is the minimum checklist before opening the PR?
On June 18, 2026, GitHub announced that Copilot code review now uses relevant instructions from repository-level AGENTS.md files (GitHub Changelog, "Copilot code review: AGENTS.md support and UI improvements", 2026). The checklist should become versioned context, not oral memory.
Before opening the PR, validate this sequence:
- The PR resolves a named issue, task, or requirement.
- The diff touches few files and explains any exception.
- The PR body lists commands run and their result.
- A test fails before the fix when the task is a bug.
- No test, lint, coverage, or workflow was weakened.
- Similar PRs and issues were searched before opening.
- Sensitive areas trigger a specific human reviewer.
- The agent stopped when context was missing instead of inventing certainty.
The checklist can live in AGENTS.md, a PR template, or a job named agent-pr-eval. The format matters less than enforcement. If the agent cannot produce that package, the work is still a draft.
For teams already using lean AGENTS.md files for coding agents, the next step is direct: add a short agentic PR section with required evidence, scope boundaries, and stop rules.
FAQ about coding agent PRs
Should an agent PR be smaller than a human PR?
In practice, yes. In 2026, the MSR/arXiv study observed that unmerged PRs tend to touch more files and change more lines (arXiv, "Where Do AI Coding Agents Fail?", 2026). The agent can produce quickly, but the reviewer still pays for diff size.
Can reviewers trust the PR if all tests pass?
Not by itself. In 2026, GitHub warned that agents can weaken CI by removing tests, skipping lint, or changing workflows (GitHub Blog, "Agent pull requests are everywhere", 2026). Green tests matter, but check whether the evidence was reduced.
Should a subagent comment directly on the PR?
Only when the output has a clear contract. In 2026, OpenAI documented subagents for parallel tasks and Anthropic highlighted tool restrictions in subagents (OpenAI, "Subagents", 2026; Anthropic, "Create custom subagents", 2026). Prefer findings with file, severity, and next action.
How do you avoid duplicate agent PRs?
Start with search. In 2026, duplicate work appeared in 142 of the 562 categorized rejected PRs in the MSR/arXiv study (arXiv, "Where Do AI Coding Agents Fail?", 2026). Before opening a patch, search issues, PRs, branches, and discussions for the problem terms.
Sources consulted
- arXiv, "Where Do AI Coding Agents Fail? An Empirical Study of Failed Agentic Pull Requests in GitHub", retrieved 2026-07-16, https://arxiv.org/abs/2601.15195
- GitHub Blog, "Agent pull requests are everywhere. Here's how to review them", retrieved 2026-07-16, https://github.blog/ai-and-ml/generative-ai/agent-pull-requests-are-everywhere-heres-how-to-review-them/
- GitHub Changelog, "Copilot code review: AGENTS.md support and UI improvements", retrieved 2026-07-16, https://github.blog/changelog/2026-06-18-copilot-code-review-agents-md-support-and-ui-improvements/
- OpenAI, "Subagents", retrieved 2026-07-16, https://developers.openai.com/codex/subagents
- Anthropic, "Create custom subagents", retrieved 2026-07-16, https://docs.anthropic.com/en/docs/claude-code/sub-agents
