How maintainers spend their review attention is one of the few things about software quality you can actually count. A new study counted it for a narrow case. When an AI agent opens a pull request that changes the deployment pipeline as well as the application code, does anyone read it?
The researchers worked from merged pull requests in real, actively maintained repositories, covering six commercial agents alongside a matched set of human-authored changes. They paired every change that touched both application code and infrastructure with a comparable change that touched only code, so the comparison wouldn't just be measuring size.
Most agent work never comes near infrastructure. Only a small fraction of agent pull requests touch both, and a large share do nothing but chores such as README edits, lockfile bumps and test shuffling. When an agent does reach for an infrastructure file, it's usually one file, and usually the CI workflow.
That's where the attention problem starts. When human developers added infrastructure changes to a pull request, their review rate barely moved. When agents did it, review became erratic, rising in one dataset and dropping sharply in the other. To rule out the obvious explanation, that these were maintainers waving through their own agent's work, the researchers isolated contributions from outsiders holding no write access to the repository at all. The gap survived.
"This oversight deficit persists independently of administrative authority: even among unprivileged external contributors, agent identity independently reduces the odds of human review by 63.7%."
Being labelled as an agent cut the odds of drawing a human review by about two-thirds, even among contributors holding no write access. The result splits into two modes, and neither is comfortable. Between 43% and 56% of these pipeline-touching agent changes (depending on the dataset) merged with no human inspection at all, typically inside thirty minutes, while the ones that did get read sat in the queue around three times longer than code-only changes (in the one dataset that supports that comparison).
The authors' reading of the silent half is the sharper claim, and it belongs to them. A change that edits the workflow file is a change to the thing meant to validate it.
"Because the patch altered the validation logic tasked with verifying it, the passing automated check provides zero independent assurance of build integrity."
The argument holds together, but the study never checked whether one of these unreviewed workflow edits actually did anything harmful. It counted merges that nobody inspected; it didn't go looking for consequences.
Which suggests the fix is narrow. Branch protection on .github/workflows and its equivalents costs an afternoon and settles nothing about whether agents deserve trust.
On this reading, the bot label is doing the damage. The same diff draws less scrutiny once it's attributed to a machine, which inverts the entire point of labelling it. And this design can't tell whether maintainers skipped review because the label reassured them or because a colleague had already read the change before dispatching the agent. The data has no window into that, and the two have very different fixes.
For anyone tracking agent adoption on a dashboard, the practical move is to stop reading merge rate as a quality signal and start counting what share of agent merges a human commented on. On this evidence, a fast merge rate is as likely to be measuring how quickly unexamined changes clear as how good the changes were.
Sources
- Soualhi, M. W., Suleiman, B., "Co-Modifying Application Code and Deployment Infrastructure: A Causal Study of AI Agent Pull Requests" — https://arxiv.org/abs/2610.12849