AI Coding Agents Tripled Weekly Pull Requests

Teams that connected an AI coding agent opened 65 pull requests a week as of June 2026. Teams that did not opened 10. Two years earlier those same groups sat at 21 and 8, which means AI coding agents pull requests through at roughly triple the old rate while everyone else stayed flat. The numbers come from Linear's published usage data, drawn from its own workspaces.

That is a large gap, and it is the least surprising thing in the dataset.

The numbers

Linear reports that AI now authors just under half of everything created in its product. As of August 2026, agents and MCP clients were creating roughly 2,435,000 issues a week against about 2,481,000 from people and integrations combined. On current trend it crosses over shortly.

Pull requests opened per workspace rose 111% between June 2024 and June 2026. The split behind that average is the interesting bit, because the growth is almost entirely concentrated in agent-connected teams.

Adoption spread beyond engineering too. Between January and June 2026, Linear reports AI feature adoption rising from 12% to 30% in engineering, 12% to 34% in product, 6% to 22% in design, and 5% to 18% in go-to-market. Product managers attaching pull requests went from 3% to 10% over two years, designers from 1% to 8%.

The number that changes the story

More pull requests is an output metric, and output metrics are the easy half. The harder question is what fraction of that work reaches production.

LinearB's 2026 benchmark data, written up on Dev Interrupted, reports that AI-assisted pull requests merge at less than half the rate of human-authored ones, against a backdrop where more than 88% of developers use AI regularly.

Put those two datasets next to each other and the picture stops being about productivity. A team tripling its pull request volume while merge rates halve has not tripled its shipped work. It has tripled the amount of code waiting for a human to make a judgement about it, and moved its bottleneck from writing to reviewing.

That is a constraint shift, not a win or a loss. It just relocates where the queue forms.

Why the queue forms at review

Reviewing is the part agents have not absorbed, and the reason is structural rather than technical.

A reviewer approving human code is checking work by someone who held the requirement in their head and can explain the tradeoffs. A reviewer approving agent output is checking work produced by something that will confidently produce a different answer if asked again, and which cannot be interrogated about its reasoning after the fact in any load-bearing way. The reading is slower because the trust baseline is lower.

Volume makes this worse in a specific way. Reviewer attention is roughly fixed per week. Triple the inbound and the per-change attention drops by two thirds, right at the moment each change deserves more scrutiny, not less. That is how the review step degrades into a rubber stamp, which is the failure mode worth watching for on your own team.

What to measure instead

If you are running agents and want to know whether they are working, pull request count is the wrong number. It is trivially inflatable by anyone with an agent and an afternoon.

Better candidates, roughly in order of usefulness:

• Merged pull requests per week, not opened ones.

• Median time from open to merge, split by agent-authored and human-authored.

• Share of agent pull requests closed without merging, and why.

• Rework rate: changes touching the same file within a fortnight of a merge.

• Review time per change, which is where the cost actually lands.

The gap between opened and merged is the honest measure of how much of the extra throughput was real. There is a fuller treatment in measuring whether an AI coding agent saves time, including how to get a baseline before you turn anything on.

The obvious response, and its limit

The reflex is to put an agent on the review side too, which does help with the mechanical layer: missed null checks, inconsistent error handling, a dependency nobody asked for. Using a coding agent to review a pull request is a genuine time saver for that class of finding.

It does not help with the question the review actually exists to answer, which is whether the change is the right change. An agent that did not sit in the conversation about what the feature is for cannot tell you the implementation solves the wrong problem correctly. Two agents disagreeing about a diff produces more text, not more certainty.

For a small team the practical implication is unglamorous: cap how much agent output you let into review at once. Three well-scoped changes that get read properly beat fifteen that get skimmed. The tooling has made generation cheap and left evaluation exactly as expensive as it was, and the broader tradeoffs of working this way have not moved much either.