陌生人的 PR 有人审，Agent 的反而没人看（中英切换）

Picture two PRs landing in your open-source repo at the same time. Both come from strangers with no write access, both touch a few application files, and both quietly edit a yml under .github/workflows/. The only difference: one was written by a person, the other says "Generated by Codex" in the description, or its author avatar is Copilot.

Which one do you read more carefully?

Most people's instinct: the agent one, obviously, machine-written code is less trustworthy. The data says the opposite.

My take: we review agent PRs more loosely than we review strangers. The class that most needs review, PRs that also change CI, is exactly the class most likely to merge unread, and its green check comes from the pipeline it just rewrote. This isn't an agent problem. It's maintainers reading "written by an agent" as "machine-generated chore".

The evidence is Mohammad Wathiq Soualhi (independent researcher) and Basem Suleiman (UNSW), "Co-Modifying Application Code and Deployment Infrastructure: A Causal Study of AI Agent Pull Requests" (arXiv:2610.12849, 9 Oct 2026). They take 26,999 PRs from two public datasets (AIDev v5 and MOSAIC-3M), all from GitHub repos with more than 100 stars, created in June–July 2025, covering six agents (Codex, Claude Code, Copilot, Devin, Cursor, Jules) plus a matched set of human-written PRs.

Same stranger, agent byline, less review

The cleanest comparison: look only at external contributors with zero write access, 2,232 PRs. These people have no organisational tie to the repo, so in principle maintainers should be equally wary of all of them.

Human-written PRs got external review 82.7% of the time. Agent-written ones, 63.6%. Controlling for files changed, lines changed, whether tests were included and repo stars, an agent byline cut the odds of human review by 63.7% (OR = 0.363, 95% CI 0.293–0.451).

This group specifically rules out "maintainers use agents to open their own PRs, so they skip review". The authors put it plainly: whether a PR gets reviewed follows attribution, not patch complexity and not privilege.

The class that most needs review slips most

The paper calls PRs that change both application code and deployment infrastructure dual-scope PRs. They're only about 4.5% of agent PRs, but more than 70% of them touch CI/CD pipelines, and when only one infrastructure file changes, it's overwhelmingly a CI config.

For human authors, adding a CI change barely moves the formal review rate: 72.2% vs 73.4%. For agents it wobbles: in MOSAIC-3M it drops from 52.5% (code only) to 36.2% (code plus CI); in AIDev v5 it rises slightly, 47.5% to 53.1%. The two datasets disagree on direction, and the MOSAIC result has p = 0.052 on just 80 pairs, so it's not proof on its own.

But this comparison, within a single dataset, is hard to explain away: of PRs that also change CI, 19.0% of human-written ones merged with no review comments; for agent-written ones it was 56.2%. Across both datasets, 43% to 56% of these agent PRs merge with zero external comments and zero reviews, in a median of 26 to 31 minutes.

The green check grades itself

Why are CI changes the dangerous ones? Because they make "tests passed" meaningless.

A PR that edits .github/workflows/test.yml gets validated by the edited version. It can skip a test suite, mark a step continue-on-error, or narrow the lint paths. And then it's green. The paper calls this a circular verification failure: the thing being checked is the checker, so the green status gives zero independent assurance. CI security already has a name for it, Poisoned Pipeline Execution: untrusted contributions rewrite workflow definitions to execute arbitrary code inside build runners.

Put the two together: an outside account opens an agent PR that tweaks CI on the side, a maintainer sees "another agent PR", glances at the green check, and merges within half an hour. Nobody on that path needs bad intent. Everyone just needs to be busy.

My guess: chores trained people to read only the check

The paper doesn't explain why maintainers go easier on agents. What follows is my speculation, not the paper's finding.

The same paper has this number: 17.7% to 25.4% of agent PRs are pure chores, touching neither application code nor infrastructure, only docs, tests or lockfiles; among AIDev's chore PRs, README.md alone appears in 44.7%. Maintainers drowning in "agent updated your README" and "agent bumped a dependency" naturally learn a routine: if it's an agent, skim, merge when green.

The trouble is that the habit was learned on low-risk PRs and gets applied unchanged to PRs that rewrite the pipeline. Review effort should follow which paths changed. Right now it follows whose name is on it.

One step you can run now

Step one: find out how many "changed CI, nobody reviewed" PRs your repo has already merged. With gh and jq installed, run this inside the repo:

gh pr list --state merged --limit 300 \
  --json number,title,author,mergedAt,files,reviews \
| jq -r '.[]
  | select(any(.files[]; .path | test("^\\.github/workflows/|(^|/)Dockerfile$|\\.tf$|^(terraform|k8s|deploy)/")))
  | .author.login as $a
  | select([.reviews[] | select(.author.login != $a)] | length == 0)
  | "#\(.number)\t\($a)\t\(.mergedAt[:10])\t\(.title)"'

It lists merged PRs among the last 300 that touched workflows, Dockerfiles or Terraform/k8s/deploy directories with no review from anyone but the author. Adjust the path regex to your repo.

Step two: make review follow paths, not bylines. Add a .github/CODEOWNERS:

/.github/workflows/  @your-org/infra
/.github/CODEOWNERS  @your-org/infra
Dockerfile           @your-org/infra
/terraform/          @your-org/infra

Then turn on "Require review from Code Owners" in your branch protection or ruleset. Whoever wrote the PR, whatever name is on it, touching those paths needs a named person's approval; application-only PRs flow as before.

And one rule for yourself: a PR that changes CI doesn't get to count its own green check as evidence. Read what the workflow diff changed, and if needed rerun with the workflow from the main branch.

In one line: we worry agent code is unreliable, then in practice hand it more trust than a stranger. Stop deciding what to read by who signed it; decide by what it touched.