Coding Agents Tripled PRs. Total Dev Time Still Went Up

Every engineering leader evaluating coding agents asks the same question: are these things actually making teams faster, or just busier? In August 2026 Linear published six years of anonymized usage data that gives one of the clearest answers available, because it tracks the full workflow from issue creation to pull request rather than token consumption. The short version: output roughly tripled for teams running coding agents, planning time did not move, and total product-development time went up. A separate benchmark from LinearB explains why - the extra work is piling up in review.

Official Sources#

Last updated: August 23, 2026

From 1 issue in 1,000 to half of everything#

In June 2024, fewer than one issue in a thousand created in Linear was authored by AI. By the week of August 3, 2026, agents and MCP clients were creating about 2,435,000 issues per week against roughly 2,481,000 per week from people and integrations (Linear). That is just under half of all issue creation, generated in under two and a half years from effectively zero.

The curve is not linear. Agent-created volume stayed near zero through early 2025, crossed 100,000 issues per week in December 2025, passed 1,000,000 per week by April 2026, and kept climbing. Human-created issues also grew over the same window, from around 600,000 to around 2,500,000 per week, so agents are adding volume on top of a growing base rather than replacing it.

For an engineering lead, this reframes what your backlog is. If your team runs Linear-style tooling, close to half the text describing work is now machine-written, which changes how much review discipline the intake process itself needs before anyone writes code.

Agent-connected teams tripled their output#

The sharpest cut in Linear's report compares a fixed cohort of paid workspaces over two years (Linear):

• Teams with a coding agent connected went from 21 weekly PRs in June 2024 to 65 in June 2026 - roughly tripled.
• Teams without one went from 8 weekly PRs to 10 - essentially flat.
• Overall PRs opened per workspace rose 111 percent against the June 2024 baseline, measured the week of June 21, 2026 across about 47,900 paid workspaces.

Linear flags the selection effect directly: agent-connected teams were already higher-output before coding agents existed, so the levels are not comparable across cohorts. Each cohort against its own baseline tells the story, and nearly all of the growth sits on the agent side. The timing supports that reading too - output held roughly level through the first year, then bent upward through 2026 as model quality and adoption climbed together.

If you want a defensible claim to take to your org, it is this: in this dataset, connecting a coding agent is associated with tripling opened-PR throughput over two years, while not connecting one is associated with standing still.

The catch: total product-development time went up#

Here is the number most summaries skip. Between June 2025 and June 2026, engineering time spent creating and triaging issues rose from 24 to 28 minutes per user per month, and time spent commenting rose from 35 to 40 minutes per user per month (Linear). Two entirely new activity categories appeared on top - chatting with AI and delegating issues to agents - and nothing else shrank to make room.

Linear's own conclusion: "teams are working more, not less, suggesting AI has a Jevons paradox quality beyond token consumption." When a technology makes something cheaper, total consumption of it often rises enough that overall spending goes up, not down. Agents made producing code cheap, so teams produce more candidates, coordinate more, review more, and spend more hours in the system overall.

Two honest caveats. This measures time inside Linear, not a stopwatch on engineering, so it captures coordination overhead rather than deep-work time. And rising minutes per person alongside tripled output is not automatically bad - it means the constraint moved, not that value fell. But if you bought agents expecting your team's total workload to drop, the data says otherwise so far.

Planning time did not move at all#

While nearly everything else in the report moved, time spent on customer requests, docs, and projects held steady within a minute per function year over year (Linear). Linear reads this plainly: "AI has so far changed how teams execute far more than how they decide what to build."

That matches what adoption numbers imply. Agents compress implementation, not judgment. The scarce inputs remain deciding what to build, specifying it well, and judging whether shipped work was worth it. Teams that treat agents as a way to skip specification work should expect the difference to surface later as rework in review.

Non-engineers started shipping code#

The share of users attaching a pull request in the last 30 days, June 2024 versus June 2026 (Linear):

• Product managers: 3% to 10%
• Designers: 1% to 8%
• Engineers: 20% to 34%
• Founders: 11% to 23%

The people who used to describe a change increasingly ship it themselves. Linear notes these are floors rather than ceilings, since they only count PRs in repositories connected to Linear. For capacity planning purposes, this means your effective engineering population is larger than your engineering headcount, and your code review queue inherits reviewers who have never reviewed code professionally.

Opened is not merged#

Linear counts PRs opened, not merged, and says so explicitly (Linear). That choice matters when you put its numbers next to LinearB's 2026 Engineering Benchmarks Report, covered by Dev Interrupted on March 24, 2026: over 88 percent of developers use AI regularly, yet AI-assisted pull requests merge at less than half the rate of human-authored ones. LinearB's analysis attributes the gap largely to review - code generation accelerated, review processes did not.

These findings are compatible. If agent-heavy teams open three times as many PRs and each merges at half the rate, merged output still rises substantially. That is roughly what Microsoft's CLI-agent field study found from the other direction: across tens of thousands of engineers in an early-2026 rollout of Claude Code and Copilot CLI, adopters merged about 24 percent more PRs than counterfactual baselines predicted (arXiv:2607.01418).

Put together, the picture is consistent: more work enters the pipeline, more work ships than before, and a much larger share stalls in review along the way. We have covered this pattern before in AI Code Review Is the New Bottleneck - when generation gets cheap, review becomes the constraint, and unreviewed PR queues are silent inventory.

What to measure instead of PR count#

Raw PR count rewards opening work, not finishing it. Four metrics track what actually happened:

1. Merged PRs per week, split by author type. Count human-authored and agent-assisted separately. Merged, not opened, or you are measuring enthusiasm.
2. Median open-to-merge time, split by author type. If agent PRs take twice as long to merge, your review process is the bottleneck and the median makes that visible without outliers distorting it.
3. Rework rate. The share of PRs receiving substantive change requests or new commits after opening. High rework on agent PRs usually points upstream at specification quality, which connects to why agent evals need baseline receipts before you scale usage.
4. Review time per change. Minutes of reviewer attention per PR. As non-engineer authorship grows, reviewer load grows with it, and this is the number that predicts when your senior engineers burn out.

None of these require new tooling. All of them are computable from git metadata your team already produces, and together they answer the question PR count cannot: is agent-generated work converting into shipped software at the same rate as human work?

FAQ#

Are coding agents actually making teams more productive?#

Output yes, efficiency unclear. Teams connected to a coding agent tripled weekly PRs from 21 to 65 between June 2024 and June 2026, but total product-development time rose over the same period (Linear). More software moves; more total hours go in.

Did total development time go down with AI?#

No, according to Linear's data. Engineering time on issue creation rose from 24 to 28 minutes per user per month and commenting rose from 35 to 40 between June 2025 and June 2026. New AI activities stacked on top of existing work with nothing shrinking to compensate.

Why do AI-assisted PRs merge less often?#

Per LinearB's 2026 benchmarks, AI-assisted PRs merge at less than half the rate of human-authored ones, with the gap concentrated in review (Dev Interrupted). Common causes include larger diffs, thinner context in descriptions, and review processes sized for human-paced generation.

What does the Jevons paradox framing mean here?#

Cheaper production increases total consumption enough that overall cost goes up. Linear applies it beyond tokens: agents made producing candidate changes cheap, so teams generate more of them, and the total hours spent coordinating, reviewing, and integrating rose even though each unit got easier.

Do non-engineers really ship production code now?#

A growing minority does. PMs attaching PRs went from 3 to 10 percent and designers from 1 to 8 percent between June 2024 and June 2026 (Linear). These count only repos connected to Linear, so true rates may be higher.

Can I trust Linear's data?#

It is self-interested vendor data with disclosed limits: one vendor's customer base, opened PRs rather than merged, and a cohort-selection caveat on the agent comparison. It is nonetheless the largest workflow-level dataset published so far, and the caveats are stated openly on the page. Treat direction as credible and exact magnitudes as provisional.

What should I track instead of PR count?#

Merged PRs per week split by author type, median open-to-merge time split by author type, rework rate after opening, and review time per change. Together they distinguish generating work from shipping it.

Does any independent evidence support the output gains?#

Partially. Microsoft's field study of CLI-agent adoption found adopters merged roughly 24 percent more PRs than baselines predicted (arXiv:2607.01418), using merged rather than opened PRs. The magnitude is smaller than Linear's tripling, which is expected since it isolates individual adoption effects rather than comparing connected versus unconnected teams.

Continue Reading#

If the review bottleneck is the part you want to fix next, start with AI Code Review Is the New Bottleneck for the systems that keep agent output shippable. To see what the individual-adoption evidence looks like underneath these team-level numbers, read Microsoft's CLI Coding Agent Study. And before you take any vendor productivity claim at face value, including the ones above, Your Benchmark Is Lying to You covers how to interrogate it.