THE NUMBERS
● Issues authored by AI: under 1 in 1,000 two years ago, just under half today.
● Weekly pull requests: 21 to 65 for teams using agents. 8 to 10 for teams not using them.
● Engineering time on create and triage: up roughly 17%.
● Total product development time: up. Not down. Up.
What Linear measured
Linear published aggregated product data from its paid workspaces — AI conversations, agent sessions, issue activity, comments and pull requests — comparing June 2025 with June 2026. Adoption metrics use trailing 30-day windows, and time series aggregate weekly to reduce noise.
Two caveats worth holding. It covers paid Linear workspaces only, which skews toward software teams that adopt tooling early. And it measures activity inside Linear, which is not the same as shipped outcomes. Linear says as much, noting it intends to go deeper on the full lifecycle from token spend to outcomes in future reports.
Within those limits, the dataset is unusually good: real telemetry from real teams, not a survey of what engineering leaders think is happening.
The gap between throughput and speed
Teams using coding agents went from 21 weekly pull requests to 65. Teams not using agents went from 8 to 10. That is a genuine, large, agent-attributable difference in output.
And total product development time increased.
WHY BOTH CAN BE TRUE
Throughput is how much work moves. Cycle time is how long any given thing takes to finish. Agents raise the first and leave the second alone, because the bottleneck was never typing the code.
Every PR an agent opens still needs a human to review it. Triple the PRs and you triple the review load, and review is the part that was already the constraint.
Linear's own framing is that more work needs more coordination, and that coordination increasingly sets the context agents act on. Time spent creating, triaging and commenting rose in nearly every function — engineering up roughly 17 percent on create and triage alone. Founders moved most, up 17 minutes on issue creation and 26 on commenting, though that cohort is small.
Read plainly: agents converted engineering time from writing code into specifying and reviewing code. That is a real change in the job. It is not obviously a saving.
What the research says about which agent PRs actually land
A separate body of work this year gives the practical counterpart. Studies mining the AIDev dataset of agent-authored pull requests found:
- Reviewer engagement has the strongest correlation with successful integration. Not model quality, not iteration count — whether a human actually engaged with the review.
- Larger change sizes are associated with lower merge likelihood. Big agent PRs die.
- Coordination-disrupting actions like force pushes reduce the chance of merging.
- Iteration intensity alone explains little once collaboration signals are accounted for. An agent grinding through twenty revisions on its own does not help.
- Successful integration happens when agents engage in actionable review loops converging toward reviewer expectations.
One analysis covered 24,014 merged agent PRs against 5,081 merged human PRs. Another fingerprinted 33,580 PRs across Codex, Copilot, Devin, Cursor and Claude Code, identifying which agent wrote which at 97.2 percent F1 — agents leave detectable behavioural signatures, which has implications for repository governance nobody has fully worked through yet.
What to actually change
| If you are... |
Do this |
| Measuring agent ROI on PR count |
Stop. Measure cycle time from issue opened to shipped. PR count is the number that flatters agents |
| Drowning in agent PRs |
Cap PR size in agent instructions. Large diffs are measurably less likely to merge |
| Finding review is the bottleneck |
It was the bottleneck before agents too. Agents made it visible, not new |
| Running agents unattended overnight |
Reviewer engagement predicts merges better than anything else. Unattended output mostly does not land |
| A founder or exec adopting this |
Budget your own time. Founders showed the largest increases in creation and commenting |
| Deciding whether to adopt at all |
Adopt for volume of parallel work, not for speed on any single thing |
The honest read
This is not an argument against coding agents. Stripe runs Minions producing over 1,300 pull requests a week. Spotify migrates its codebase with Honk on work traditional scripts could not touch. Those are real capabilities and they did not exist two years ago.
It is an argument against a specific expectation. If you adopted agents to ship the same roadmap faster, the data says that is not what happens. What happens is you attempt a larger roadmap with the same headcount, and the coordination cost of doing so is real and lands on your engineers.
That may still be the trade you want. It is a different trade from the one most teams think they are making.
FAQ
Do coding agents make teams faster?
They increase throughput substantially — 21 to 65 weekly PRs in Linear's data. They did not reduce total product development time, which rose. Faster at producing work, not faster at finishing it.
Why did development time increase?
Review, triage and coordination all scale with PR volume, and they land on humans. Linear reports engineering time on create and triage up roughly 17 percent. The constraint moved rather than disappearing.
What makes an agent pull request more likely to merge?
Reviewer engagement, by a wide margin. Smaller change sizes help. Force pushes and other coordination-disrupting actions hurt. Iteration count on its own explains very little.
Is AI really writing half of all issues?
Just under half of everything created in Linear across its paid workspaces, up from fewer than one in a thousand two years ago. Linear expects it to pass people and integrations combined shortly.
Does this mean I should not use coding agents?
No. It means measuring them on PR count will tell you a flattering and useless story. Measure cycle time from issue opened to shipped, and adopt agents for parallel volume rather than single-thread speed.
How reliable is this data?
It is real telemetry rather than a survey, which is unusually good. It covers paid Linear workspaces only, so it skews toward early-adopting software teams, and it measures activity inside Linear rather than shipped business outcomes. Direction credible, magnitude may not generalise.