In June 2024, almost nothing inside Linear — the issue tracker used by a large share of modern software teams — was written by a machine. Fewer than one issue in a thousand was created by AI. This month Linear published aggregated data from 127,000 paid users across 47,900 paid workspaces, and the number has moved further in two years than most metrics move in a decade.
AI now authors nearly half of every issue created in the product. By early August 2026, agents and AI features were generating roughly 2.44 million issues a week, against about 2.48 million from humans and traditional integrations. The two lines are days away from crossing.
The output metrics moved with it. Pull requests attached to Linear issues are up 111% in two years. Teams that adopted coding agents went from 21 pull requests a week to 65 — a little over triple. Teams that did not went from 8 to 10.
And then the part that does not fit the story everyone expected: the time engineers spend on the work around the code went up. Create-and-triage time rose for most functions. Planning time inside Linear did not fall at all. The agents did not take work off the board. They put more on it.
The Queue Nobody Staffed
Linear’s data shows the volume. A separate dataset shows where it goes. LinearB, an engineering-metrics company with no corporate relationship to Linear despite the name, published a benchmark in March 2026 built on 8.1 million pull requests from more than 4,800 organisations across 42 countries. It is the largest public look at what happens to AI-written code after someone opens the pull request.
Human-authored pull requests in that dataset merged within 30 days 84.5% of the time. AI-assisted ones merged 32.7% of the time.
Roughly two thirds of AI-written pull requests never became shipped software at all.
The waiting is where it happens. AI-assisted pull requests sat about 5.25 times longer before a reviewer picked them up — over a thousand minutes of dead time against roughly two hundred for code with no AI involvement. The submission is instant. The queue is not.
| After the pull request opens | Human-written | AI-assisted |
|---|---|---|
| Merged within 30 days | 84.5% | 32.7% |
| Wait before first review | ~200 min | ~1,000+ min |
| Time in review once started | 252 min | 194 min |
| Size, 75th percentile | 157 lines | 400+ lines |
Source: LinearB 2026 Engineering Benchmarks, 8.1 million pull requests across 4,800+ organisations in 42 countries, published March 24, 2026.
Read the third row again, because it inverts the obvious explanation. Once a reviewer actually starts on an AI-assisted pull request, they finish it faster than a human-written one — 194 minutes against 252. The code is not harder to review. It is harder to begin reviewing.
Bigger Diffs, Same Reviewers
The size numbers explain most of the reluctance. At the 75th percentile, a pull request with no AI involvement ran 157 lines. An AI-assisted one ran over 400. That is not a marginally larger change; it is a different category of thing to hold in your head on a Tuesday afternoon.
A 157-line diff is a task. A 400-line diff written by something that cannot be asked what it was thinking is a project. Reviewers triage by cost, and a large diff from an author who cannot explain their reasoning is the most expensive item in the queue. So it moves to the bottom. Then it sits there long enough to conflict with everything merged above it, and by the time anyone opens it, the cheapest resolution is to close it.
That responsibility has not moved. Whoever approves the merge owns the outcome at three in the morning, and no amount of generated code changes who gets the page.
Feeling Fast and Being Fast
There is one more piece of evidence, and it is the only one of the three that was a controlled experiment rather than an observation.
In July 2025, the research nonprofit METR ran a randomised trial with 16 experienced open-source developers across 246 real tasks in repositories they already knew well. Half the tasks permitted AI tools; half did not. The developers using AI took 19% longer.
Afterwards, the same developers were asked how much AI had helped. On average they estimated it had made them about 20% faster.
A roughly forty-point gap between measured performance and felt performance, in people who had just done the work themselves, is the most uncomfortable number in any of this. It is worth stating the caveats plainly: the sample was small, the developers were domain experts working in code they knew intimately — the scenario where AI assistance helps least — and the tooling was early-2025 vintage. METR itself now labels the result historical and says it does not necessarily describe current tools. But it does describe something that has not gone away, which is that throughput feels like progress from the inside even when the finish line has not moved.
It Is Not Only Engineers Anymore
The last thread in Linear’s data is who is now generating this work. Between January and June 2026, AI feature usage roughly doubled across every function. Product teams went from 12% to 34%. Engineering went from 12% to 30%. Go-to-market went from 5% to 18%. At companies over 200 people, CEO usage climbed from 9% to 36% — the sharpest jump of any group measured.
More consequentially, people who do not write code have started attaching pull requests to their tickets. Product managers went from 3% to 10%. Designers went from 1% to 8%. Both roughly tripled in six months.
That is a genuine expansion of who can propose a change to a codebase, and in a lot of organisations it is the healthiest thing in this entire dataset. It also lands in the same queue. A designer who can now open a pull request has not added a reviewer; they have added a submission. The people qualified to approve a merge are the same people they were in January, and there are the same number of them.
What To Watch
- Merge rate, not pull request count. Any team reporting how much AI has helped by counting pull requests is reporting the input. The number that matters is what share of them merged, and how that share moved.
- Review capacity as a staffed role. If submissions tripled and nobody was moved onto reviewing, the queue is the plan. Watch for the first organisations that treat review throughput as something to resource rather than absorb.
- Diff size as a policy. The 400-line pull request is the unit causing the delay. Teams that cap generated changes at something a human will actually open on a Tuesday should show up in the merge-rate data before they show up anywhere else.
- Whether the two Linear lines cross. AI is days away from authoring the majority of issues created in the product. The first month where machines create more work items than people do is a milestone somebody should mark.
- A replication of the METR result on 2026 tools. METR has said its study is historical and has redesigned the experiment. The rerun is the single most useful number nobody has yet.
The Takeaway
AI now writes nearly half of every issue created in Linear, up from fewer than one in a thousand two years ago. Teams running coding agents triple their pull requests, from 21 a week to 65. Across 8.1 million pull requests, the AI-assisted ones merge 32.7% of the time against 84.5% for human-written code, after waiting more than five times longer for anyone to look at them.
The bottleneck did not disappear. It moved one step to the right, from writing code to agreeing to be responsible for it — and that step is still done entirely by a person, at the same speed as always.
The number worth keeping is not 65 pull requests a week. It is 32.7%. That is the conversion rate between what these tools produce and what actually ships, and until it starts climbing, every gain in generation speed is being spent on a queue.