Linear published its own numbers, and the honest part is the caveat

Linear put out Edition 01 of a data report covering tens of thousands of teams, written by Tim Qi, their Head of Data. It's the closest thing we have to a controlled look at what agents actually did to software teams, because Linear sees the issue tracker and the PR link, and it has a clean pre-AI baseline to measure against.

Here's the headline. By August 2026, agents and MCP clients created roughly 2,435,000 issues per week. Humans and integrations created about 2,481,000. Two years ago the agent share was fewer than one in a thousand. Pull requests across the platform are up 111% against the June 2024 baseline. And the split is not evenly distributed: teams using coding agents went from 21 weekly PRs to 65, roughly tripling, while teams not using them sat flat at 8 to 10 the entire time. (Linear)

That's a 3x throughput gap between two populations of teams that presumably looked similar in 2024. If you've been arguing with someone about whether agents produce measurable output changes, this is the number to put in front of them.

Now the part I actually care about. Qi looked for the expected effect, that time spent on existing work would shrink because agents absorbed it, and didn't find it. Teams are working more, not less. He reads it as Jevons paradox: make a unit of software work cheaper and you consume more of it rather than banking the savings. Nobody got their afternoons back.

And Qi caveats his own headline, which is why I trust the rest of it: PRs opened measure motion, not value. A tripled PR count is a tripled review count, a tripled merge-conflict surface, a tripled number of decisions somebody has to hold in their head.

Which lands right on top of what Simon Willison said this week on Talking Postgres. He defends lines of code as a productivity metric in the agent era, arguing an engineer historically shipped 50 to 200 lines of production-ready code a day and can now hit a thousand debugged lines, which is a real gain if quality holds. Then he names the wall: "I can churn out code a hundred times faster. I don't have the cognitive capacity to stay on top of 100 times the amount of code." (simonwillison.net)

He pairs it with a conceptual-integrity warning I hadn't thought about in these terms. The week-long estimate used to be a filter. It killed bad feature ideas by making someone justify a week. When implementation drops to an afternoon, nothing filters them anymore, and you get Claire Giordano's Winchester Mystery House: rooms added forever, staircases into ceilings.

What to do with this: if your team adopted coding agents and your PR count went up but nothing feels better, you're the normal case, not the broken one. The intervention isn't more agent throughput. It's putting a cost back on the decision to build something, because the cost on the implementation is gone. Write the estimate down before you start even though the agent will finish it in an hour. The estimate was never really about time.