Nothing in Linear's data shows coding agents giving engineers time back. They are producing more code, and the work around it — specifying, triaging, and deciding whether the output is safe to merge — is growing rather than shrinking.
That is the finding buried in the first edition of Linear's How Teams Build data report, published this week. Across a fixed cohort of 6,887 paid teams tracked from June 2024 to June 2026, teams that connected a coding agent went from 21 pull requests a week to 65. Teams that did not went from 8 to 10. And across Linear's whole paid user base in the same window, the time engineers spent creating and triaging issues went up, not down. If you told a CFO that agents would compress delivery time or reduce headcount, this is the dataset that gets quoted back at you.
What Linear Actually Measured
Linear measured product-development activity inside its own product across 47,900 paid workspaces, not self-reported productivity. That distinction is the reason this report is worth an hour of your time and most vendor productivity studies are not — nobody was asked how fast they felt.
The report is Edition 01, authored by Tim Qi, and it draws on 127,000 paid users active between January and June 2026, 166,000 paid users for the pull-request analysis, and a fixed two-year cohort of 6,887 teams — 4,280 with a coding agent connected and 2,607 without — for the headline throughput comparison.
The numbers that matter to an engineering leader:
- Pull requests per workspace are up 111% since June 2024, and almost all of that arrived in 2026: the index sat around +27% in February 2026 and hit +111% by June.
- Agent-connected teams: 21 → 65 PRs a week (+210%). Non-agent teams: 8 → 10 (+25%).
- AI now authors just under half of everything created in Linear. As of August 2026 the report puts AI at roughly 2.4 million issues a week against 2.5 million from humans and integrations combined. Two years ago it was fewer than 1 issue in 1,000.
- Executives are personally in the tool. CEOs at companies of 201+ people went from 9% to 36% active on AI features in six months — the largest jump in the report.
This is the closest thing the industry has to a multi-company throughput measurement with a comparison group, and it lands in a corpus of single-company anecdotes. It is a better instrument than the ones we have been arguing over — including Airbnb's claim of 80% more features shipped and Zalando auto-approving a third of its pull requests.
The Control Group Is Not a Control Group
The non-agent cohort is a baseline, not a matched control, and Linear says so itself. Read the caveat before you put the 3x number in a board deck.
At the June 2024 starting line, the teams that would later connect an agent were already opening 21 PRs a week against 8 for the teams that would not — 2.6x more output before any agent existed. The report is explicit: "These teams were already higher-output before coding agents existed, so the levels aren't directly comparable, but each cohort against its own baseline tells a clean story."
That is the honest reading. The slopes are the finding — +210% against +25%. The levels are a selection effect: teams that adopt agents early are the teams that already had CI, review discipline, and repo hygiene good enough to make an agent useful.
Linear also flags that it counted pull requests opened, not merged — "an opened PR says nothing about the value of the change" — and states plainly that "we have no way of knowing whether this increased output led to positive business outcomes." The Hacker News thread, 178 points and 110 comments deep, made the same argument less politely: usage is not value, and PR count measures what is easy to measure.
Steel-man the optimistic case, because it is real. DX's guidance on measuring AI impact argues that flat throughput with high time savings is a good outcome — developers reinvesting speed into quality — and that coding is only about 14% of a developer's day, so accelerating it has a hard ceiling. Across 400+ companies DX puts median PR throughput growth at roughly 8% against 65% growth in AI tool usage, alongside a claimed 3.9 hours saved per developer per week. Both things can be true: individual coding got faster, and the system did not.
The Time Did Not Come Back
Engineering time in Linear held flat or rose in every category the report tracks — nothing declined — and a new category appeared on top of the old ones. That is the sentence to underline.
Average minutes per user per month, engineering role, June 2025 → June 2026:
| Activity | Jun 2025 | Jun 2026 |
|---|---|---|
| Create and triage issues | 24m | 28m |
| Commenting | 35m | 40m |
| Chat with AI | 0m | 2m |
| Agent issues | 0m | 1m |
| Planning (docs, projects) | 3m | 3m |
| Customer requests | 1m | 1m |
These are minutes spent inside Linear, not total engineering hours — a small slice of the day, and the report is measuring the coordination surface, not the work. Two caveats the throughput headline does not carry: this chart runs across Linear's entire paid user base — 54,300 users in June 2025, 89,000 in June 2026 — and is not split by whether a team connected an agent, so it cannot pin the rise on agents specifically. And Linear sells the coordination layer, which gives it an interest in a finding that coordination work is growing. Read it as the population trend it is. That is still what makes the direction interesting. The coordination layer is the work that surrounds writing code: specifying what should be built, triaging what came back, reviewing it, and deciding whether it ships. If agents were absorbing coordination overhead, this is where it would show up as a decline. It went the other way.
Linear's own conclusion: "Those gains haven't shown up as time saved... Time spent on existing tasks in Linear held while AI usage appeared as a new layer of work, meaning the overall time spent on product development is going up rather than down." And then, more bluntly: "teams are working more, not less, suggesting AI has a Jevons paradox quality beyond token consumption."
This is not the first measurement to land there. METR's randomized controlled trial put 16 experienced open-source developers through 246 real tasks in their own mature repositories and found them 19% slower with AI tools available — while they estimated afterward that they had been 20% faster. METR itself now labels that result historical, and the tooling has moved a long way since early 2025. The durable finding is not the direction of the number. It is the size of the gap between what practitioners believed and what the clock said.
The Bottleneck Moved to Code Review
The constraint did not disappear. It moved from writing code to deciding whether code is safe to merge, and the measurements on that side are worse than the throughput numbers are good.
Faros AI's Acceleration Whiplash report, built on two years of telemetry from 22,000 developers across 4,000+ teams, found task throughput per developer up 33.7% and epics completed per developer up 66% under high AI adoption — and, in the same population, median code review time up 441.5%, median time to first review up 156.6%, bugs per developer up 54%, the incidents-to-PR ratio up 242.7%, and pull requests merged with no review at all up 31.3%.
LinearB's 2026 benchmarks, drawn from 8.1 million pull requests across 4,800 teams in 42 countries, put numbers on why: at the 75th percentile, AI-assisted PRs run 400+ lines against 157 for unassisted ones, reviewer pickup on agent-generated PRs stretches past 16 hours against roughly 200 minutes, and only 32.7% of AI-generated PRs merge within 30 days against 84.5% of unassisted ones. Two-thirds of them do not land inside that window.
What lands is heavier to maintain. GitClear's 2026 maintainability research, across 623 million analyzed changes, reports duplicated code blocks up 81% since 2023 to the highest level on record, error-masking constructs up 47%, and moved-code refactoring collapsing from 21% of changed lines in 2022 to 3.8% year-to-date in 2026.
Linear's own head of engineering said the quiet part out loud two months before the data report shipped. Speaking to LeadDev in June 2026, Tom Moor called code review "the new bottleneck" and noted that his 45-engineer team is "writing a lot more requests for comments recently" — more upfront specification, not less. Linear's internal numbers in that piece are notably milder than the cohort headline: 52.7 to 59.8 PRs per author, on a team that already knew what it was doing.
The 2025 DORA report, from nearly 5,000 respondents, framed the same trade cleanly: AI adoption now shows a positive relationship with throughput and a negative relationship with delivery stability, because "without robust control systems, like strong automated testing, mature version control practices, and fast feedback loops, an increase in change volume leads to instability." Or, in DORA's blunter phrasing: "AI doesn't fix a team; it amplifies what's already there."
Product Managers Are Opening Pull Requests
The people opening pull requests changed, and almost nobody has assigned a reviewer to the new ones. This is an org-design problem wearing a tooling costume.
Between June 2024 and June 2026, per Linear's data, the share of users attaching a pull request to an issue rose:
- Product managers: 3% → 10%
- Designers: 1% → 8%
- Founders: 11% → 23%
- Engineering: 20% → 34%
Linear's read is that "senior leaders are doing more of the hands-on IC work... and non-engineers are committing code," and that the everyone-is-a-builder claim is "directionally true."
Take it seriously and the staffing question is immediate. A PM's agent-generated PR does not review itself, and it does not get reviewed by the PM. It lands in an engineer's queue — the same engineer whose median review time is already up 441.5% — attached to a change whose author cannot answer a design question about it. That is the specific mechanism behind "merged with no review, up 31.3%."
It also raises the oversight problem we covered in the research on how novices trust vague AI explanations more than experts do: the reviewer least equipped to catch a subtle failure is the one most likely to approve it. If your review rota now includes non-engineers, you have moved authority away from competence, quietly, without a decision ever being made.
How to Staff the Coordination Layer
Treat this as a capacity-planning exercise, not a tooling one. Here is the sequence that actually produces a decision.
This Week:
- Chart your own two cohorts against their own baselines, not each other. Split teams by whether an agent is connected, plot PRs opened per week over 24 months, and compare each line to where it started. Linear's caveat is your caveat — the levels will lie to you, the slopes will not.
- Add merge rate to every throughput dashboard that currently counts PRs opened. If your 30-day merge rate on agent-authored PRs is anywhere near LinearB's 32.7%, you are reporting motion as output.
- Pull median time-to-first-review and median review time, split by whether the PR was agent-authored. You need the number before the next planning conversation, not after.
This Month:
- Name an owner for non-engineer pull requests. Decide who reviews a PM's or designer's agent-generated change, put it in the CODEOWNERS file, and give that person the hours. Do not leave it to whoever is on rota.
- Set an alert on merges with zero review approvals and look at the trend line, not the total. This is the failure mode that shows up as an incident three weeks later.
- Fund the spec layer explicitly. More RFCs before the agent runs is the pattern Linear's engineering lead reports, and it is billable engineering time that no roadmap currently accounts for. Our playbook on evaluating coding assistants at 500 seats has the seat-versus-consumption math; this is the line item that sits above it.
Before Your Next Planning Cycle:
- Rewrite the promise you made to finance. If the pitch was "agents reduce delivery time," the measured result across every dataset here is more output at equal or greater time. Restate the benefit as throughput per engineer and say explicitly what you intend to do with the extra throughput.
- Pick one auditable business number and publish it monthly. Features shipped is not it. Pick something with a denominator that finance already trusts.
- Set a review-capacity ratio and defend it in headcount. Reviewer-hours per merged PR is a number you can budget. "We'll absorb it" is not.
The Bottom Line
Every automation cycle has ended the same way: the constraint moves, it does not vanish. Numerically-controlled machining did not empty the factory floor — it moved the bottleneck to inspection, scheduling, and tooling changeover, and the plants that won were the ones that staffed those functions before the parts piled up. That pattern was already visible in Alibaba's 16-day autonomous coding run, where a human still wrote the commits that mattered, and in the 64% of the Fortune 500 running coding agents against the 33% that measure the return.
Linear's dataset is the first at scale to show both halves of the trade in one place: output tripled, and coordination time went up. Whether you are running Cursor, GitHub Copilot, or Claude, the model you bought is not the variable that decides how this goes. Your review capacity is.
The agents gave you more code. They did not give you more judgment. That is still the thing you have to staff.
Continue Reading
- Zalando Auto-Approves a Third of PRs. Agents Made Them Bigger.
- Airbnb Shipped 80% More Features. One Number Is Auditable.
- 64% of Fortune 500 Use AI Coding Agents. 33% Measure ROI.
- Alibaba's Agent Coded 16 Days. A Human Wrote 13 Commits.
- Best AI Coding Assistant at 500 Seats: Buy Copilot Business
- The Vaguer the AI Explanation, the More Novices Trusted It
- Claude Code Stops Asking Aug 14. Prompts Aren't Policy.
