A passing test suite is the cheapest thing in code review. Somebody else produced it, it travels with the change, and a reviewer can lean on it without reading every line. A survey of practitioners, each asked matched questions about human- and AI-authored pull requests, found the lean stops working once the author is an agent.
The inversion is specific. Reviewers ranked inspecting and running tests higher among where their review time goes on AI-authored changes, while the share who named tests covering the risky behaviour as enough evidence to approve fell from 41% to 24%. What replaced it was working through the critical cases themselves, the most common approval criterion for agent-written code. Tests turned into a way to investigate a change rather than a warrant for merging it.
"Thus, AIPR review does not simply increase demand for more tests. It shifts approval toward reviewer-owned reasoning about critical cases."
The rest of the pattern fits a reviewer who's stopped trusting evidence they didn't generate. Reading the pull request description slid down the list of where review time goes; running the code locally jumped up it. When part of a change couldn't be verified in the time available, 44% said they would block the merge outright, against roughly one reviewer in five for a human's change. Unclear ownership doubled as a reason to stop reviewing and ask for more. The technical triggers barely moved. Missing tests, logic a reviewer can't follow, unexplained cross-module impact all halted review at the same rates either way. Reviewers weren't applying stricter technical triggers. They were relying on different evidence, and declining to sign off on anyone else's.
The authors read this as a problem of evidence ownership. Reviewers want a traceable line from a generated change to a checked behaviour and to a person who will answer for it. They push further, into territory their data can't reach.
"Generating a patch or producing a passing test result does not imply that the associated integration decision becomes cheaper."
They're honest about the limits. The time questions asked reviewers to rank activities against each other, not to clock them, so the study cannot show that an AI-authored pull request takes longer to review in total. It can only show that attention moves around inside it. And nothing here establishes that the agent's tests deserve the suspicion.
"The survey does not establish that AI-generated tests are generally less reliable."
Review has become less delegable, rather than more thorough. A human pull request arrives with cheap proxies, such as the author's record, their familiarity with the subsystem, and a conversation available if something looks off. Strip those out and the reviewer absorbs the work personally. That's the one cost that doesn't scale by adding agents, and it's the half of the ledger nobody sees when capacity planning runs on generation throughput. Track wall-clock from PR opened to merged on agent-authored changes, and ask submitters to state which claims they checked themselves rather than which the agent asserted. Treat any benchmark reporting resolved issues or merge rates without review cost as describing half a transaction.
This will get over-read, because it measures what reviewers say they'd do, in a questionnaire that showed them the comparison being drawn. A third reported equal or higher trust in the AI pull requests, and about half kept the same approval criterion for both. So the finding is narrower than "engineers distrust AI code", and more interesting. The shortcut teams were counting on, letting CI clear the merge, is the one reviewers quietly withdrew.
Sources
- Rahman, M. S., Alam, K., Roy, B. et al., "Plausible Is Not Enough: Trust and Evidence in AI-Authored Pull Request Review" — https://arxiv.org/abs/2610.21144