Half the Issues, Three Times the Output, and a Longer Queue: Inside the Agent Productivity Paradox - August 21, 2026

Half the Issues, Three Times the Output, and a Longer Queue: Inside the Agent Productivity Paradox Linear's first How Teams Build report finds that AI now authors just under half of every issue created on its platform, and that teams using coding agents tripled weekly pull requests from twenty one to sixty five. Total product development time still went up, with engineering time on creating and triaging work rising roughly seventeen percent. Chris and Laura dig into the corroborating LinearB benchmark of 8.1 million pull requests, where AI assisted changes merge at 32.7 percent versus 84.5 percent for code written by humans, and ask the uncomfortable question the throughput numbers hide. Hosted by Chris and Laura. The DX Today Podcast brings you daily deep dives into the most consequential stories in the AI ecosystem. #AIAgents #DeveloperProductivity #SoftwareEngineering #AICoding #ProductivityParadox

Transcript

SPEAKER_00 0:00

Welcome to the DX Today Podcast, your daily deep dive into the AI ecosystem. I'm Chris, and joining me as always is Laura.

SPEAKER_01 0:07

Thanks, Chris, and I have been waiting all week for this one because it is the rare AI story where the numbers genuinely argue with each other instead of all pointing the same comfortable direction.

SPEAKER_00 0:17

That is a great tease. So let's set it up properly for everyone listening. What exactly landed, who published it, and why should anyone outside of a software engineering team care about any of it?

SPEAKER_01 0:28

The project tracking company Linear published the first edition of a report they're calling How Teams Build, and it is drawn from their own platform telemetry rather than from a survey where people guess about their own productivity.

SPEAKER_00 0:39

And that distinction matters enormously because most of what we get in this space is people self-reporting how much faster they feel, which is roughly as reliable as asking a driver how fast they were going.

SPEAKER_01 0:51

Exactly. And the headline finding is startling. Two years ago, fewer than one issue in a thousand created inside linear was authored by an AI. Today it is just under half of every single issue created.

SPEAKER_00 1:03

Hold on, I want everyone to understand what an issue actually is here, because the Word does a lot of quiet work that non-engineers will miss. It's a unit of tracked work, right? A bug, a task, a request.

SPEAKER_01 1:13

That's it exactly. It is the atomic particle of how software teams organize themselves, and the volume curve is almost comical. In June of 2024, it was essentially zero per week. By June of 2025, it was around 35,000 a week.

SPEAKER_00 1:29

And now I feel like you're about to give me a number that requires a respectful moment of silence afterwards, so go ahead and land it on us.

SPEAKER_01 1:36

Roughly 2.4 million AI-authored issues per week as of this month. That is a 70-fold increase in 14 months. And the curve is still climbing steeply rather than flattening out anywhere.

SPEAKER_00 1:46

My instinct is to read that as an unambiguous win. More work identified, more work captured, more things getting done. But you're smiling in a way that tells me I'm about to be corrected.

SPEAKER_01 1:57

I'm smiling because this is where the report turns on itself. Linear, also measured output, specifically pull requests, which are the actual proposed code changes that represent real shipped work rather than mere intentions. An issue is a promise. A pull request is closer to a delivery.

SPEAKER_00 2:14

So what happened to the deliveries once the agents showed up in force? Because that is the number that decides whether any of this was worth the money.

SPEAKER_01 2:22

Teams using coding agents went from roughly 21 pull requests a week to about 65. That is a clean tripling. Meanwhile, teams not using agents crawled from about eight a week to 10.

SPEAKER_00 2:33

So that's a real effect, and not a small one. Three times the output is the kind of number that gets a budget approved in about 90 seconds flat at most companies I've ever worked with.

SPEAKER_01 2:42

It absolutely is. And I want to be fair to the technology, because that throughput gain is real and measured across a large sample. But now here is the part that should stop everyone cold. Total product development time went up, not down. Engineering time spent creating and triaging work rose about 17% over the very same window.

SPEAKER_00 3:02

Okay, that is genuinely counterintuitive, and I want to sit in it for a second. Three times the output, and yet the humans are spending more time, not less. Where exactly is that time going?

SPEAKER_01 3:13

Into direction and cleanup. Linear zone framing is the sharpest line in the entire report. They write that AI has landed on top of existing work rather than replacing any of it. That is their conclusion, not mine.

SPEAKER_00 3:24

On top of, rather than instead of. That is a devastating little phrase when you consider what every vendor deck for the last three years has promised about freeing up your engineers to do higher value work.

SPEAKER_01 3:36

And the distribution of that new burden is fascinating. Founders showed the largest increases of anyone, 17 extra minutes a month creating issues, and 26 extra minutes a month just commenting on things.

SPEAKER_00 3:48

Founders. So the single most expensive and most distractable person in the entire organization is now spending an extra half hour a month typing comments at robots. That is not the future anybody was selling.

SPEAKER_01 4:01

And the categories themselves are new. Chatting with an AI added two to five minutes a month across every function, and delegating issues out to agents added another one to two minutes on top. That is the entire mechanism, honestly. Nobody adds an hour. Everybody adds four minutes here and six minutes there, and the aggregate quietly eats the savings that the throughput gain was supposed to deliver.

SPEAKER_00 4:23

Let me play devil's advocate because one company's platform data is still one company's platform data. How big is this sample and how much weight can we responsibly put on a single vendor's telemetry?

SPEAKER_01 4:34

It's substantial. Nearly 6,900 teams in the agent comparison, split into about 4,300 using agents and 2,600 not. Almost 48,000 paid workspaces feed the aggregate trends.

SPEAKER_00 4:48

That is a real sample. And I appreciate that they publish the denominators, which frankly a lot of these reports conveniently omit. But I still want to hear about selection bias before we go further.

SPEAKER_01 5:00

You should, and to Linear's credit, the caveat is right there in the report. This is paid workspaces only, and it skews hard toward teams already inclined to adopt new tooling. These are early adopters, not the median company.

SPEAKER_00 5:12

Which actually cuts in an interesting direction. If the enthusiasts, the people who most want this to work, are the ones showing rising total time, that is arguably worse news than if the laggard showed it.

SPEAKER_01 5:24

That is exactly the right read. And it is why I don't think this can be waved away as a skill issue or a temporary adoption curve problem. These are the people who are best at this.

SPEAKER_00 5:35

So is there any corroboration outside of Linear? Because a single data set with a surprising result is a hypothesis, not a finding, and I would hate for the two of us to overclaim on one report.

SPEAKER_01 5:45

There is, and this is what convinced me the story is real. Linear B, a different company entirely, ran the numbers on 8.1 million pull requests across 4,800 engineering teams in 42 countries.

SPEAKER_00 5:58

Different company, different methodology, much larger volume. That is the kind of independent replication that actually moves my priors. What did they find on the delivery side of the equation?

SPEAKER_01 6:09

Something brutal. Human written pull requests merged within 30 days about 84.5% of the time. AI-assisted pull requests merged within 30 days about 32.5% of the time.

SPEAKER_00 6:21

Wait, so roughly two-thirds of AI-assisted code changes are still sitting there, unmerged a month later? That reframes the throughput number completely because volume that never lands is not output at all.

SPEAKER_01 6:33

It is the single most important number in this entire story, and almost nobody is quoting it. You can triple the pull requests opened and still ship less if two-thirds of them never make it in.

SPEAKER_00 6:43

So what happens to them? Are they rejected outright? Are they abandoned? Or are they simply rotting in a review queue that nobody has the appetite to open on a Tuesday afternoon?

SPEAKER_01 6:53

Mostly the third one, and the timing data tells you why. Human-authored pull requests get picked up for review in around 200 minutes. AI-assisted ones take over a thousand minutes just to get picked up.

SPEAKER_00 7:05

Five times longer merely to get someone to look at it. And I would bet a considerable amount of money that the reason is sitting right there in the size of these things.

SPEAKER_01 7:14

You would win that bet. At the 75th percentile, human pull requests are about 157 lines of code. AI-assisted ones are over 400 lines. Nobody wants to open that on a Friday.

SPEAKER_00 7:24

Of course they don't. A 400-line change request is not a code review, it is a weekend. So the bottlenecks simply migrated from writing the code to finding somebody willing to read it.

SPEAKER_01 7:34

That is the cleanest summary of the whole phenomenon I have heard. We automated the cheap half of the process and left the expensive half, human judgment and human attention, completely untouched and badly overloaded. And here is the almost poetic detail: the fully autonomous agent pull requests are actually smaller, around 290 lines, than the human plus AI assisted ones. When a human has an assistant, the human accepts more than they would ever have written themselves.

SPEAKER_00 8:02

There is a third piece of evidence I want to bring in because it goes to the perception gap rather than the workflow. Tell everyone about the randomized trial because I think it is the psychological key to all of this.

SPEAKER_01 8:13

The METER study.

SPEAKER_00 8:50

That gap is the whole ballgame, isn't it? If the people doing the work cannot perceive even the direction of the effect, then every self-reported productivity statistic in this industry is essentially noise dressed up as data.

SPEAKER_01 9:02

Every single one, and that includes most of the executive surveys that budgets are being built on right now. And speaking of executives, the adoption numbers explain why this keeps spreading rather than self-correcting. Among chief executives at companies with more than 200 employees, adoption went from 9% to 36% in six months.

SPEAKER_00 9:23

So the person approving the spend is now personally using the tool, personally feeling faster, and personally unable to measure whether the organization actually got faster. That is a fairly combustible combination of facts.

SPEAKER_01 9:35

And they are not just chatting, they are contributing code. Founders opening pull requests went from 11% to 23%. Product managers went from 3 to 10. Designers went from 1 to 8% over two years.

SPEAKER_00 9:49

Now that one I actually find encouraging, and I want to give it its due rather than folding it into the pessimistic read. More people able to propose changes directly is a real democratization of capability.

SPEAKER_01 10:00

I agree completely, and I don't want the skepticism to swallow that. But notice who has to review all of those new contributions from people who cannot review their own work. It is the same overloaded engineers.

SPEAKER_00 10:13

Right. Every new contributor is a new demand on a fixed pool of reviewers. So are there organizations actually making this work at scale, or is everyone quietly stuck in the same growing queue?

SPEAKER_01 10:22

There are, and the examples are instructive. Stripe runs a fleet of internal agents they call minions that generate over 1,300 pull requests a week, sourced from Slack messages, bug reports, and feature requests.

SPEAKER_00 10:35

1,300 a week is extraordinary. And my immediate question is whether they solved the review bottleneck or simply built a much larger and more expensive version of the exact problem we have been describing.

SPEAKER_01 10:46

That is the honest open question, and the public reporting does not answer it. Spotify has a similar system called Honk that handles large code migrations, the kind of sweeping mechanical change traditional scripts could never manage.

SPEAKER_00 11:00

And migrations feel like the genuinely correct use case because that is high volume, low ambiguity, highly verifiable work where a machine reviewing a machine is actually a defensible arrangement rather than a shortcut.

SPEAKER_01 11:12

That is my read too. The pattern that works is bounded, mechanical, testable work. The pattern that struggles is open-ended feature development where a human has to hold the whole design in their head anyway.

SPEAKER_00 11:23

So if I'm an engineering leader listening to this on a Friday morning, wondering whether my agent budget is buying me anything at all, what is the one measurement you would tell me to start taking today?

SPEAKER_01 11:33

Stop counting, pull requests opened, and start counting pull requests merged, along with the time from opening to first pickup. Volume is vanity here. The merge rate and the queue latency are the only honest signals.

SPEAKER_00 11:46

And I would add one more, which is to be extremely suspicious of your own sense of how it is going. Because the randomized trial says your intuition is not merely imprecise, it points the wrong direction entirely.

SPEAKER_01 11:57

That is the discipline this moment requires. And to be clear, none of this says the agents do not work. It says the constraint moved, and organizations have simply not moved their attention along with it yet.

SPEAKER_00 12:08

Which is such a familiar shape for anyone who has studied automation history. You relieve one bottleneck, the system reorganizes around the next one, and the real gains only appear once the process itself is redesigned around it.

SPEAKER_01 12:20

And that redesign is the actual work ahead. Smaller changes, tighter scopes, real automated verification, and reviewers who are properly resourced for the volume, the technology arrived. The operating model around it simply has not.

SPEAKER_00 12:34

That feels like exactly the right place to land it. Half the issues written by machines, three times the output, and a review cue that somehow got longer. That is the most honest picture of this moment I have seen.

SPEAKER_01 12:45

And I would say, watch for the counterexample. Nobody has yet published a team that achieved both higher throughput and faster cycle time. Whoever manages that first will have figured out something genuinely important.

SPEAKER_00 12:57

That's all for today's episode of the DX Today podcast. Thanks for listening, and we'll see you next time.