AI can generate pull requests faster than a team can understand them

Agentic coding is present across thousands of projects, but intensive use is rare

A July 15, 2026 paper by Maliha Noushin Raida and Daqing Hou analyzed 25,264 agentic pull requests from 2,361 GitHub repositories with more than 100 stars. It studied PRs attributed to Copilot, Codex, and Claude Code during May through July 2025. The result is a more useful picture than product demos: most repositories tried only one or two agentic PRs, while sustained volume clustered in a small minority.

The authors found that only 25 projects, about 1% of the sample, exceeded a contextual reference line of 36 agentic PRs per participating human over the three-month observation period. They explicitly warn that the count is not a universal productivity standard. It measures activity, not change complexity, quality, review effort, or business value. That limitation should shape every internal dashboard: a high PR count can indicate productive automation, a fragmented task queue, or a growing pile of review debt.

Smaller projects with one to five contributors showed higher participation ratios and greater average agentic PR activity than larger projects. This makes operational sense. A small repository has fewer coordination boundaries, a compact architecture, and often one person who already understands the whole system. A large repository distributes knowledge across owners, services, compliance controls, test environments, and release trains. The model can generate a patch in both settings, but the cost of proving that the patch belongs is very different.

The strongest finding concerns oversight. In 78.9% of the studied agentic PRs, the same human both reviewed and modified the agent contribution. Another 9.8% had one reviewer and no human committer. Together, those single-human patterns accounted for 88.7% of the sample. Multiple-human collaboration appeared in only 11.3% of PRs. Even larger projects mostly depended on individual oversight.

This is not evidence that one reviewer is always unsafe. A small documentation fix may need only one owner. It is evidence that agent throughput can concentrate responsibility without making it visible. If one developer prompts the agent, interprets its plan, modifies its patch, judges its tests, and merges it, familiar review controls may exist only as interface elements.

The scarce resource is verified attention

Coding agents lower the cost of producing a plausible change. They do not lower every downstream cost. Someone must establish that the issue is worth solving, the requested behavior is correct, the repository context is current, the diff is minimal, the tests exercise the failure, the security boundary still holds, and the deployment can be reversed. The more quickly agents open PRs, the more easily those obligations become a queue.

That queue has nonlinear behavior. Ten small, independent changes may be easy to review. Ten changes that touch a shared schema, permission model, generated client, or migration stack interfere with one another. Reviewers repeatedly reload context, reconcile stale branches, rerun expensive integration tests, and decide which agent interpretation should win. Generation time falls while coordination time rises.

GitHub's documentation gives one concrete warning: skipped checks can report success and therefore may not block a merge even when configured as required. A green box is not a semantic guarantee. Repositories need to know which checks actually ran, on which SHA, against which merge state, and whether an agent could alter the workflow or instructions that define those checks.

AI review does not remove the problem. GitHub Copilot code review and Anthropic's Code Review can inspect broad repository context and surface suspected defects. Both vendors still tell users to validate findings, and Anthropic states that its review does not approve or block the PR. An agent reviewer is useful as an additional evidence producer. If the same model family generates, reviews, fixes, and approves a patch with no independent gate, correlated blind spots become policy.

Design the pull request as an evidence packet

A reliable agentic PR pipeline separates problem definition, change generation, verification, and authorization. The agent can own much of the generation and evidence collection. It cannot own the final statement that the evidence is sufficient for the repository's risk.

Issue or change request
  - expected behavior
  - constraints and owner
          |
          v
Isolated agent branch or worktree
  - inspect -> plan -> edit -> test
  - no direct protected-branch write
          |
          v
Evidence packet
  - scope map and changed behavior
  - test commands and exact results
  - risk flags and residual uncertainty
          |
          v
Independent automation
  - required CI, security, policy, migration checks
          |
          v
Risk-tiered human review
  - evidence review + code review
          |
          v
Protected merge -> canary -> rollback signal

OpenAI's Codex app uses isolated worktrees so parallel agents can work without touching the main checkout. Claude Code GitHub Actions runs on GitHub runners and turns issues into pull requests. GitHub Copilot cloud agent works on a branch and keeps the PR title and body aligned with its changes. These product choices converge on the right integration boundary: proposed work should arrive as reviewable branch state, not as an opaque modification to a trusted working tree.

Isolation is only the first control. Repository instructions, build scripts, and tests come from the branch and can be untrusted or wrong. GitHub notes that Copilot code review can read custom instructions and skills from the head branch. That is useful for testing instruction changes, but it also means review behavior can be influenced by the change under review. Protect the definition of critical checks and require human scrutiny when a PR changes workflow files, agent instructions, review rules, or security policy.

Require a machine-readable evidence contract

A prose PR description is easy to sound confident in and hard to audit at scale. Add a small evidence file or structured section that records what the agent claims, how the claim was tested, what was not tested, and which risk flags apply. CI can validate the shape, while the reviewer evaluates the substance.

change_evidence:
  issue: ENG-1842
  behavior_before: "expired sessions return 500"
  behavior_after: "expired sessions return 401 with error code"
  scope:
    files: 4
    services: ["auth-api"]
    migrations: false
    permissions_changed: false
  verification:
    - command: "pnpm test auth/session-expiry.test.ts"
      result: "18 passed"
      commit: "4f83c2a"
    - command: "pnpm lint"
      result: "passed"
      commit: "4f83c2a"
  not_verified:
    - "mobile client retry behavior"
  risk_flags:
    - "authentication"
  rollback:
    strategy: "revert commit; no data migration"
  human_owner: "@service-owner"

The commit field matters. Evidence from an earlier version of the branch does not prove the reviewed head. For generated artifacts, migrations, dependency changes, or API schemas, record both the generating command and the diff. For a claimed regression fix, require a failing-before and passing-after test when feasible. A test added by the same agent is useful, but the reviewer should check that it fails for the original defect and cannot pass for the wrong reason.

Keep uncertainty explicit. "Not verified" is a useful field, not an admission of failure. It lets the reviewer decide whether the gap is acceptable, needs a second environment, or changes the risk tier. Agents are prone to summarizing missing evidence as success. A contract makes absence visible.

Route review effort by blast radius, not author type

Do not treat every agent PR as high risk merely because AI created it, and do not treat every human PR as low risk. Classify the change by the authority it touches, the reversibility of the effect, and the strength of available evidence. The author type can affect scrutiny, but it should not replace the technical risk model.

Change size is a routing signal. A large diff is not automatically wrong, but it consumes more review context and hides unrelated choices. Set repository-specific thresholds that request splitting or an architecture review. More important, flag semantic boundaries: one PR that changes authentication, a database migration, and deployment policy is three review problems even if it is only 200 lines.

Turn the policy into protected repository behavior

Start with branch protection or repository rulesets. Require pull requests, appropriate approving reviews, and named status checks from expected sources. Require the latest reviewed push where practical so an agent cannot add a commit after approval and inherit stale consent. Prevent the agent identity from bypassing the rule.

name: agentic-pr-evidence
on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]

jobs:
  evidence:
    if: ${{ !contains(github.event.pull_request.labels.*.name, 'human-only') }}
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v4
      - name: Validate evidence contract
        run: ./scripts/validate-change-evidence.sh
      - name: Detect sensitive surfaces
        run: |
          git diff --name-only origin/${{ github.base_ref }}...HEAD \
            | ./scripts/classify-change-risk.sh
      - name: Run repository verification
        run: ./scripts/ci-required.sh

This example is intentionally generic. Pin actions according to your supply-chain policy, keep job names unique, restrict token permissions, and ensure the workflow runs for merge queues if the repository uses them. Do not allow a PR to redefine the only check that approves itself. For critical workflows, keep policy in an organization-controlled reusable workflow or require code-owner approval for changes under .github/workflows/.

Define task intake before enabling parallel generation

A useful agent task has one owner, one expected behavior, named constraints, a verification path, and a stop condition. "Improve the auth service" is an exploration prompt, not a merge task. "Return a typed 401 for expired access tokens without changing refresh-token behavior; add a regression test and stop if the mobile client contract is ambiguous" is reviewable.

Measure verified delivery, not generated activity

The July study is careful not to equate PR volume with productivity. Internal programs should be equally cautious. Measure whether the system reduces the cost of delivering correct changes without transferring invisible work to reviewers or operations.

Compare similar work. Documentation edits, dependency upgrades, isolated bug fixes, migrations, and cross-service changes should not share one leaderboard. Use a baseline from the team's existing workflow and retain rejected PRs in the accounting. If only merged work is measured, the failed generation and review cost disappears.

Common failure modes

The community signal from July matches the empirical caution. In r/AI_Agents, a thread about wanting to give automation less control drew 24 points and 32 comments, while another thread about agent projects being cancelled focused on reliability and operational limits. These are not representative studies, but they reveal the concern teams should test: useful automation often comes from narrowing authority and improving evidence, not from letting the agent do more.

FAQ

What is an agentic pull request?

It is a proposed repository change produced by a coding agent that can inspect context, edit files, run commands or tests, and create a pull request. The label describes the generation workflow. It does not guarantee quality, autonomy, or safe merge readiness.

Should every AI-generated PR get two human reviewers?

No. Review requirements should follow blast radius and evidence. A typo fix may need one owner; a permission change, migration, or production workflow should receive independent domain review. The important rule is that the generator cannot silently authorize its own change.

Can an AI reviewer satisfy the independent review gate?

It can add useful evidence, especially for broad context gathering and repeatable checks. It should not be the sole authority for high-impact changes produced by an agent with similar blind spots. Keep a qualified human accountable for the merge decision.

What is the best first coding-agent task?

Choose a bounded problem with a reproducible failure, an established test command, a clear owner, and a reversible change. Avoid the first experiment being an architecture rewrite, permission change, production migration, or vague cleanup.

Does a higher agentic PR count mean higher productivity?

No. Count measures activity. Pair it with accepted value, reviewer effort, rework, queue time, change risk, defects, and rollback. The research itself cautions that PR-per-participant volume does not capture complexity, quality, or review effort.