The AI Coding Productivity Paradox, Explained With Data

In a data update published August 21, 2026, the project management company Linear reported that AI now writes just under half of everything created inside its own tool, up from fewer than one issue in a thousand two years earlier. Teams that connected a coding agent roughly tripled their weekly pull requests. And overall product development time still went up.

That last sentence is the part worth sitting with. Three separate 2026 datasets, from Linear's own product telemetry, from the code-intelligence platform LinearB, and from the engineering analytics firm Faros AI, converge on the same shape: AI coding tools are unambiguously increasing output, and they are not shortening the time it takes to actually ship. This is not a story about AI coding being a scam, and it is not a story about 10x engineers. It is a measurement problem, and understanding it is the difference between adopting AI coding well and adopting it badly.

What Linear's own numbers show

Linear tracks its own usage because it is, among other things, the tool its engineers use to build itself. Two years ago, AI-authored issues were a rounding error. Today they are just under half of everything created in the product, and Linear's data suggests AI will soon author more issues than people and integrations combined.

The pull request numbers make the split concrete. Teams that adopted a coding agent went from an average of 21 weekly pull requests in June 2024 to 65 in June 2026, close to a tripling. Teams without one grew from 8 to 10 over the same span. Across the whole workspace, Linear says pull requests opened per week are up 111 percent against a June 2024 baseline.

The company's internal engineering team supplies a sharper, shorter-horizon version of the same pattern. After co-founder Jori Lallo circulated a January 7, 2026 memo asking engineers to install Claude Code or Opencode and write code with a model instead of by hand, Linear's per-author output jumped almost immediately: from a January baseline to 52.7 pull requests and 44.4 issues per author in February, increases of roughly 30 percent and 33 percent in a single month. And yet Linear's own writeup is explicit that it cannot show this converted into better outcomes: "we have no way of knowing whether this increased output led to positive business outcomes." Time spent on existing categories of work did not fall; AI usage simply layered on as a new category of work on top, which is the mechanism Linear points to for why total product development time rose rather than fell.

The independent data says the same thing, at larger scale

Linear is one company self-reporting on its own tool. The pattern holds up in data that spans thousands of companies. LinearB's 2026 Engineering Benchmarks Report analyzed 8.1 million pull requests across roughly 4,800 teams in 42 countries, and it found that 88.3 percent of developers now use AI regularly, up from about 72 percent in early 2024. That is near-total adoption. But the same report found that AI-assisted pull requests run about 2.5 times larger than unassisted ones. At the 75th percentile, AI-assisted PRs run over 400 lines of changed code, against 157 lines for work done without AI.

Bigger diffs are harder to review, and the LinearB data shows reviewers responding accordingly: AI-generated pull requests wait more than five times longer for a first review than unassisted ones, and they merge to production within 30 days at roughly a third the rate of human-authored work (32.7 percent versus 84.5 percent). Writing code faster did not make the code faster to trust.

Faros AI's 2026 report, built on telemetry from roughly 22,000 developers across more than 4,000 teams, quantifies the same tradeoff with two years of longitudinal data rather than a single snapshot. Task throughput per developer rose 33.7 percent. PR merge rate per developer rose 16.2 percent. Those are real, measurable gains. Median time spent in code review rose 441.5 percent over the same period, and the incident-to-pull-request ratio rose 242.7 percent. Faros AI's own name for the pattern, "the acceleration whiplash," captures the two halves of the same trend line moving apart.

Why both things can be true at once

The mechanism is not mysterious once you separate two different things that get collapsed into one word, "productivity."

Writing code and shipping code are different processes with different bottlenecks. A coding agent removes friction from the writing step: drafting a function, scaffolding a test, refactoring a module. It does nothing, by itself, to remove friction from validating that the result is correct, secure, and consistent with everything else in the codebase. When the writing step gets radically cheaper and the validating step does not, the constraint on total delivery time simply relocates. Economists call this a shift in the binding constraint; in a software team, it shows up as a queue of pull requests sitting in review.

Volume and size compound the review cost. It is not just that there are more pull requests. Each one is, on average, two and a half times larger. Review effort scales worse than linearly with diff size, because a reviewer has to hold more surrounding context in mind to judge whether a change is safe. Three times the PRs at two and a half times the size is not a 3x increase in review burden; it compounds toward something closer to 7 to 8x, which is roughly the order of magnitude the review-time data actually shows.

More code produced is not the same as more value delivered. A pull request that never merges, or merges and gets reverted, or introduces an incident, consumed real human review time and produced negative value. LinearB's finding that AI-generated PRs merge at less than half the rate of human ones, and Faros AI's finding that the incident-to-PR ratio more than tripled, both point at the same failure mode: teams that count lines written or PRs opened as the productivity metric are counting the wrong thing.

The visible metrics improved for a reason that has nothing to do with delivery speed. Throughput per developer, PRs merged, and issues closed are all outputs, and outputs are what a coding agent directly increases. Lead time (idea to production), change failure rate, and mean time to recovery are outcomes, and none of the 2026 datasets here claim those improved. Linear's report says so explicitly. This is precisely the distinction the DORA metrics framework was built to enforce, and it is exactly the distinction that gets lost when "AI wrote 3x more code" gets reported as "the team shipped 3x faster."

A framework for checking whether AI coding is actually helping your team

Given that pattern, the useful question for an engineering leader is not "how much code is AI writing." It is a short checklist of outcome metrics that catch the paradox before it compounds:

• Lead time for changes. Track idea-to-production time, not commit volume. If AI usage is up and lead time is flat or worse, the gain is being absorbed somewhere downstream, almost always in review.
• Review queue depth and wait time, tracked separately from throughput. A growing backlog of unreviewed AI-authored PRs is the single clearest early warning sign in all three datasets above.
• Change failure rate and incident ratio. If AI-assisted output is growing but so is the rate at which it breaks something, the net delivery speed is worse than the raw output number implies, once you account for the time spent firefighting.
• PR size distribution, not just PR count. A team whose median PR size is creeping up as AI adoption rises should expect review time to rise faster than PR count would suggest, and can act on it directly by asking for smaller, more reviewable diffs regardless of how they were authored.
• Merge rate, not just PRs opened. A PR that gets opened and abandoned or reverted is not output. Counting only what merges, and ideally what stays merged without a follow-up incident, is a cheap correction that fixes most of the double-counting in a raw throughput number.

None of this argues against using AI coding tools. Linear's own conclusion is not to walk back its adoption; it is to treat review capacity, not code-writing capacity, as the resource to manage deliberately, through smaller diffs, better context for reviewers, and metrics that track outcomes rather than output. Teams that route coding work across models rather than committing to a single vendor's assistant, the approach platforms like Metir AI take, get an added practical benefit here too: the ability to match model choice to the task, rather than generating everything at one model's default verbosity and pushing the size problem downstream to whoever reviews it.

The takeaway

The honest reading of the 2026 data is that AI coding tools deliver a real, measurable increase in output and, so far, no measurable decrease in the time it takes a team to actually ship. Those are not contradictory findings. They are what happens when a bottleneck moves from writing to reviewing and nobody has adjusted how they measure the system. The fix is not to write less code with AI. It is to measure delivery, not authorship, and to treat review capacity as the constraint it has become.

Sources:

• AI News August 21, 2026: AI Now Writes Half of All Linear Issues, and Teams Still Ship Slower, AIToolsRecap
• AI usage patterns in software teams, Linear
• 8 million pull requests reveal where engineering productivity breaks down, LinearB Blog
• 2026 Software Engineering Benchmarks Report, LinearB
• Why AI-assisted PRs merge at half the rate of human code, LinearB's 2026 Benchmarks, Dev Interrupted
• The AI Engineering Report 2026: The AI Acceleration Whiplash, Ten Takeaways, Faros AI
• AI Engineering Impact and Productivity Research, Faros AI
• AI-coding agents are now the default. What comes next?, LeadDev

Image credits

Hero: two people reviewing code on a laptop screen, from the WOCinTech Chat collection, via Wikimedia Commons, licensed under CC BY 2.0. In-body photograph of two developers reviewing code together by Bdecarne, via Wikimedia Commons, licensed under CC BY-SA 4.0. Both images are illustrative of a code review scene and do not depict Linear, LinearB, Faros AI, or any specific company named in this article.