Linear's AI usage data: why 65 PRs a week proves little

AI usage patterns in software teams got a rare piece of hard data this week: Linear published Edition 01 of its data report, written by Tim Qi, drawn from aggregated activity inside its own product. The number everyone will quote is that teams which connected a coding agent went from 21 pull requests a week to 65.

That figure is real. It is also close to meaningless on its own, and Linear says as much inside the report. The parts worth your attention are quieter.

---

🔍 Read the definitions before you quote the numbers

Every adoption chart in the report rests on a specific definition, and the definition is generous.

Metric	What it actually measures	Sample
"AI-active" user	At least one AI interaction (in-app or Slack conversation, or an agent session) in a 28-day window	127,000 paid users
PR volume	Pull requests opened per workspace per week	47,900 paid workspaces
Coding-agent cohort	4,280 teams with an agent vs 2,607 without	6,887 paid teams
Company-size adoption	Same 28-day AI-active bar, split by headcount	199,000 paid users

So when the report says product roles moved from 12% to 34% AI-active between January and June 2026, that is not "a third of product managers use AI daily." It is "a third touched it at least once in a month." Those are very different claims, and the gap between them is where most AI-adoption headlines go wrong.

Key takeaway: A 28-day "at least once" bar measures curiosity, not dependence. Adoption charts built on it show how many people tried the thing, not how many rely on it.

---

📊 The real shift is in who files work, not how much gets filed

Strip out the throughput noise and one pattern is genuinely new: non-engineers are now shipping code artifacts.

Function	Attaching PRs, Jun 2024 → Jun 2026	Change
Engineering	20% → 34%	+14 pts
Product managers	3% → 10%	+7 pts
Designers	1% → 8%	+7 pts

A designer group going from 1% to 8% is an eightfold relative move. Alongside it, AI authorship of issues went from fewer than one in a thousand to just under half of all issues created.

Adoption growth by function over January–June 2026 tells the same story:

• Product: 12% → 34%
• Engineering: 12% → 30%
• Founder: 14% → 30%
• Design: 6% → 22%
• Go-to-market: 5% → 18%

Product overtook engineering. For a five-person team in Colombo where the founder already writes copy, files bugs and reviews Figma, this is not a disruption; it is the tooling finally matching how you already work. The interesting question is not "will roles blur" but "who reviews the output when everyone can produce it."

---

⚡ "Motion rather than value" is their phrase, not mine

The report is unusually honest about its own limits. Two caveats are stated outright:

Looking at pull requests indicates motion rather than value. An opened PR says nothing about the value of the change.

The data is a picture of adoption inside our own customer base, not the market at large.

There is no data in the report on defect rates, review burden, revert frequency, or whether any of those PRs shipped. The authors say they intend to cover the full lifecycle, from token spend to outcomes, in future work. Until then, the +111% two-year rise in overall PR volume describes artifacts created, not problems solved.

Run the arithmetic on the headline. Sixty-five PRs per workspace per week, with three reviewers, is roughly 22 reviews per person per week on top of their own work. Nobody's reading capacity tripled between 2024 and 2026. If generation went up 3x and review capacity stayed flat, the constraint simply moved, and the report has no visibility into what happened at the new constraint.

---

🛠️ What a small Sri Lankan team should actually do with this

The report is drawn from paid Linear workspaces, which skews toward funded startups. Three things translate anyway:

1. Treat review capacity as the scarce resource. Cap open PRs per author before you raise agent throughput. A queue of 40 unreviewed agent PRs is worse than 10 human ones.
2. Enforce small diffs on agent output. Agents happily produce 900-line changes. A 900-line diff does not get reviewed; it gets approved.
3. Watch the currency mismatch. Agent tokens are billed in USD while salaries are paid in LKR, so per-seat AI tooling costs a Sri Lankan team far more in relative terms than it costs the median workspace in this dataset. Estimate spend before you commit: our AI token counter gives you a per-prompt figure, and the LKR exchange rate tool turns a USD subscription into a number your budget recognises.

For students and solo builders, the useful signal is different. Non-engineers filing PRs at 8-10% means the floor for "can contribute code" dropped. The differentiator is no longer typing the code; it is judging whether the change is correct.

---

💡 The metrics they didn't publish are the ones to track

The interesting measurements are the ones absent from Edition 01, and every one of them is free to collect from your own git history.

Metric	Why it matters	How to get it
Merged ÷ opened PRs	Separates shipped work from motion	GitHub API, or gh pr list --state all
Time to first review	Shows where the queue is backing up	PR timestamps
Revert + hotfix rate	The closest cheap proxy for quality	Commit message grep
% of PRs over 400 lines	Predicts rubber-stamped reviews	git log --shortstat

A starting point that costs nothing:

# hotfix/revert share of the last 200 commits
git log -200 --oneline | grep -icE '^\w+ (revert|hotfix|fix: regression)'

Track those four for a month before and after you add an agent. That is a better dataset for your team than any industry report, because it is measured on your codebase, with your reviewers.

---

🚀 What this means for you

Linear's report is worth reading, and its honesty about its own limits is worth more than its charts. Take three things from it:

• Adoption numbers rest on soft definitions. Check the window and the threshold before you repeat a percentage.
• The role boundary moved. Designers and PMs attaching PRs at 8-10% is the durable finding, not the throughput jump.
• Nobody has published the quality half yet. Until someone does, throughput claims about coding agents are unfinished sentences.

If you run a small team here, the cheapest advantage available right now is measuring the thing the vendors have not measured. Review latency and revert rate take an afternoon to instrument, and they tell you whether your agents are helping or just producing.