Signal-to-Noise Ratio in AI-Generated Pull Requests

AI coding agents now write something like 41% of production code, and GitHub's coding agent alone has opened roughly 1.2 million pull requests. That volume didn't wait for review processes to catch up. The failure mode isn't sloppy code, it's fluent code: clean enough to pass the checks reviewers built for human mistakes, while burying more defects per PR than a human ever shipped. The tools got better at looking correct faster than teams got better at checking for it, and that gap is the actual story here, not the raw output number.

How volume reshapes the review queue before quality enters the picture

The throughput numbers tell you the shape of the problem before anyone looks at a single diff. Telemetry from over 10,000 developers across 1,255 teams shows high-AI-adoption teams complete 21% more tasks and merge 98% more pull requests than their peers. Review time on those same teams goes up 91%.

That pairing is the whole argument in miniature. Merging nearly double the PRs while review time nearly doubles doesn't mean the bottleneck disappeared, it means the bottleneck moved. Writing code used to be the slow part of the job. Verifying it is now, and most teams have not restructured anything to reflect that.

The queue also behaves in a way that inverts what you'd expect, and this is where most teams get the diagnosis backwards. Data spanning over a million PRs from more than 4,800 organizations shows AI-authored PRs wait several times longer before a human even opens them, but once someone starts reviewing, the review itself goes twice as fast. Reading was never the slow part. Getting someone to click into the diff was.

For agentic PRs, where the AI has more autonomy over the branch and the scope of the change, pickup time stretches even longer, several times worse than an unassisted PR. Handing the agent more independence means its output sits untouched in the queue that much longer.

That's exactly backwards from where the risk sits. Agents produce fluent, clean-looking work: tests pass, CI goes green, and reviewers, staring down a queue of PRs that look fine on the surface, keep deprioritizing them in favor of the ones they instinctively trust less. The PRs sitting longest are frequently the ones that most need a second set of eyes, and they're the ones getting them last.

What the research on acceptance rates shows about which AI PRs deserve scrutiny

An MSR empirical study by Pinna, Gong, Williams, and Sarro examined 7,156 pull requests from the AIDev dataset, comparing OpenAI Codex, GitHub Copilot, Devin, Cursor, and Claude Code across nine task categories. The finding that matters most: task type predicts risk better than which agent did the work.

Documentation PRs get accepted 82.1% of the time. New feature PRs run 66.1%. That 16-point gap is wider than the variance between different agents doing the same category of work. The decision most teams agonize over, which agent to license, matters less than the one they barely think about: what kind of work to route to it. A shop that points agents at docs and boilerplate is running a fundamentally different risk profile than one that turns an agent loose on new feature branches, regardless of which logo sits on the tool.

Agent choice does start to matter once the task gets hard enough to expose real differences in judgment. On test-writing tasks, the spread between best and worst performer opens into a real gap: Cursor accepted at 77.8%, Claude Code at 33.3%. Simple, well-bounded tasks flatten the differences between tools because there isn't much room to go wrong. Tasks that demand actual judgment, like writing a test that catches a real regression instead of just exercising the code path, are where an agent's training and architecture either hold up or fall apart.

Why the noise problem is harder on mobile codebases than it looks in the abstract

Mobile makes this worse for a concrete reason, not an abstract one. Web apps have a DOM, a structured tree that testing tools hook into and inspect reliably. Mobile apps have no equivalent. Every UI change an agent makes risks breaking selector-based tests in ways that stay invisible until the app runs on an actual device, not a simulator.

Device fragmentation compounds it. An agent-written change can pass CI cleanly on a simulator and still behave differently across the sprawl of Android hardware variants sitting in the market today. That's a PR that looks correct on paper right up until it reaches a real phone in a real user's hand, and by then the CI green checkmark has already done its damage: nobody looked twice.

Mobile's release rhythm turns a manageable debt problem into a scheduling crisis. Structural debt can accumulate quietly in agent-generated code, and on most software that's a slow cost paid down on your own timeline. Mobile doesn't grant that timeline. Debt accumulates right up until App Store submission, where a refactoring problem becomes a rejection risk, because there's no post-release window left to fix it before review. Top App Store apps today ship updates on cycles measured in weeks, not months. There's no slack in that cadence to absorb a rejected build when nobody caught an AI-generated regression before it shipped.

Emerging triage and review architectures teams are building

Before a team can filter for quality, it has to solve a cruder problem: figuring out where AI-generated PRs even land. Different agents open PRs under different identities. Some show up under the developer's own account. Some open as bot drafts with a human tagged as reviewer. Some land with no personal filter catching them. A PR that doesn't route to the right queue doesn't get reviewed, regardless of how good or bad the code inside it turns out to be.

GitHub has started building infrastructure for exactly this problem. Its newer pull requests dashboard, combined with branch-prefix labeling using prefixes such as copilot/, claude/, codex/, cursor/, and devin/, lets teams identify PRs by origin. That naming convention alone lets a team build agent-aware queues without bolting on a separate tool.

Routing solves attribution, not judgment. It tells you which agent touched a branch. It says nothing about whether the change is safe to merge, and teams that treat routing as the finish line have solved the easy problem while leaving the hard one, is this safe, completely unaddressed.

What routing does buy is a floor. It makes sure judgment gets applied somewhere, to something, instead of getting lost in an unlabeled queue. Gating regression at the pull request level is associated with change-failure rates dropping under 5%, and that number reflects where in the pipeline review happens as much as how carefully anyone reviews once they get there. Putting the gate in the wrong spot means it doesn't matter how sharp the reviewers are.

Governance when the bottleneck shifts from writing to verifying

The job itself is changing shape. Engineers on AI-native teams are drifting from implementers toward specifiers, verifiers, and orchestrators: people who define what correct looks like and check whether the agent hit it, rather than people who type the implementation by hand. The specification, the acceptance criteria, the description of what "done" actually means, is becoming the artifact that determines quality. Sloppy requirements produce sloppy agent output no matter how capable the model underneath happens to be.

AI doesn't fix organizational dysfunction, it magnifies it, and this is the part boards and engineering leads keep underestimating. A team with a backed-up review process doesn't get relief from AI, it gets more volume dumped on an already-overloaded queue. A team with poorly documented architecture gets an agent that inherits all that ambiguity and hands the ambiguity right back as code. The pattern across the data is that AI functions as an amplifier, and the honest reading of that is uncomfortable: it amplifies the strengths of well-run organizations exactly as reliably as it amplifies the weaknesses of poorly run ones.

Research on AI maturity lays out what a team stuck at the bottom rung looks like: no centralized inventory of what AI tools are even in use, governance bolted on after the tools already scaled instead of built in beforehand, agent workflows running in isolation with no shared memory or context carried between them. Those are the teams generating the noise this piece opened with, and no amount of better tooling fixes that on its own.

The fix has to be explicit, not cultural, because culture is what teams point to when they want to avoid writing anything down. Teams need clear, written answers to where an agent can act alone, where it can only recommend and wait for a human call, where approval is mandatory before anything merges, and who's accountable when something slips through anyway. Skipping that clarity means accountability doesn't distribute to anyone. It disappears, and the review queue that was supposed to be a quality gate turns into just another risk surface.