# The PR is too late.

Coding agents made writing code cheap. They did not make reviewing it cheap. Every team now has the same queue, and a better PR reviewer cannot clear it, because by the time a PR exists the expensive part has already started.

## Agents now start more than 40% of pull requests on GitHub

In March 2026 it was 17%. Over the year, merged pull requests more than tripled, to 1.3 billion, about 3.5 million a day.

Share of pull requests started by an agent

March 2026

17%

September 2026

40%+110 million PRs that month

Figure 1. Pull requests on GitHub that started with an agent's first draft 1. Agent PRs do get merged 2.

1. 1 Source. [GitHub Octoverse, October 2026](https://github.blog/news-insights/octoverse/octoverse-commits-pushes-reach-new-highs-in-2026-as-developers-build-with-agents/). It counts the agents GitHub can detect, so it is a floor. Merged PRs cover October 2025 to September 2026.
2. 2 Merging. Agent PRs do get merged: 90% within two weeks by September, against about 86% for the comparison group. The queue is the issue here, not the merge rate.

## Writing scaled. Reviewing did not.

“Code review becomes the bottleneck.”

When a company adopts coding agents, pull requests go up by a third, and each one takes more than half as long again to get approved. Finished work rises far less. The extra code is waiting for a person.

+35.7% more PRs opened

+59.9% longer waiting in the queue

+56.1% longer to get approved

Figure 2. More PRs go in. The same human attention comes out 3.

1. 3 The figures. The percentages are from the Harvard study in Figure 3, after firms adopt coding agents. The shape is an illustration.

*What changed in code review after coding agents arrived*

| After coding agents arrive | Change |
| --- | --- |
| Pull requests opened 4 | +35.7% |
| Time from submission to approval 4 | +56.1% |
| Time waiting in the backlog 4 | +59.9% |
| Comments on each change 4 | +38.6% |
| Issues resolved, the finished work 4 | +13.7% |
| Wait for a first look, agent PRs against unassisted 5 | 17.6 h vs 3.4 h |
| Median time in review 6 | +441.5% |
| PRs merged with no review at all 6 | +31.3% |

Figure 3. What three independent datasets measured. The size of the effect varies by study. The direction does not.

1. 4 Harvard study. [Chen & Stratton, Harvard, November 2026](https://fion.ac/jellyfish.pdf). 720,542 workers at 655 firms, comparing firms by when they adopted agents. A job market paper, not yet peer reviewed. The rise in issues is borderline significant.
2. 5 First look. [LinearB 2026 Benchmarks](https://linearb.io/library/ai-in-software-development). 8.1 million PRs, at the 75th percentile. LinearB sells engineering analytics.
3. 6 Time in review. [Faros AI Engineering Report 2026](https://faros.ai/blog/ai-acceleration-whiplash-takeaways). 22,000 developers, comparing each organization's lowest and highest periods of AI use. Faros sells engineering analytics.

## Much of what reaches the queue is not ready

Reviewers are not only reading more. They are sending more back: comments on each change rose 38.6%. Independent tests show why.

- 45% of AI code tasks introduced a security flaw 7
- 11.8% of agent solutions were secure, though 57% worked 8
- 33% of agent runs were working and secure, in our own test 9

Figure 4. How often code from AI models and agents held up, in three separate tests with different methods.

1. 7 Security flaws. [Veracode, July 2025](https://www.veracode.com/press-release/ai-generated-code-poses-major-security-risks-in-nearly-half-of-all-development-tasks-veracode-research-reveals/). 80 coding tasks across more than 100 language models.
2. 8 Secure code. [Zhao et al., SusVibes, ICML 2026](https://arxiv.org/abs/2512.03262). SWE-Agent with Claude 4 Sonnet on real repository tasks.
3. 9 Our test. Claude Sonnet 5.5 in Claude Code, on 23 SusVibes tasks. See [the benchmark](https://verity.md/benchmark).

## AI review at the PR has not removed the bottleneck

The Harvard study found that 79.1% of firms have already adopted AI code review tools, and they still largely keep humans in the loop. A PR agent adds a reviewer. It reads the same finished code, at the same late moment, and the PR still has to wait for a person.

We saw the same in our own data. Commercial AI review bots reviewed 51 of 110 merged PRs that introduced a known bug, and flagged 8 of those bugs. These bugs all reached a merge, so a bug that a bot stopped before the merge is not in this count.

## By the time a PR exists, the expensive part has started

- **The agent has moved on** The session that wrote the code has usually ended, and its context with it. A finding now starts new work.
- **The cost lands on a person** Every problem found here costs someone's attention: read, comment, wait, read again.
- **The pressure is to merge** A long queue invites shortcuts. PRs merged with no review at all are up 31.3%.

Caught at the commit Nobody waits

1. The agent commits
2. Verity finds the bug
3. The same agent fixes it, in the same session
4. The PR opens without it

Caught at the PR If someone catches it at all

1. The agent finishes
2. The PR waits in the queue
3. A reviewer reads it and comments
4. Someone reopens the work
5. A reviewer reads it again

Figure 5. The same bug, caught at two moments 10.

1. 10 Person steps. The amber steps need a person. Before the PR, Verity's finding goes straight back to the agent, which still has its context.

## So check before the PR

Verity reviews each commit and push, while the coding agent can still fix what it finds. We tested what that does, on the same tasks, with and without it.

- 2× the real bugs of your typical PR agent
- 63% of runs working and secure, against 33% alone
- 45% fewer bad PRs

Our own benchmark, from October 2026, with Verity at maximum review effort.

[See the benchmark](https://verity.md/benchmark) [See how Verity works](https://verity.md/)

$`npm install -g @codacy/verity-cli && verity init`

Source: https://verity.md/why