AI productivity gains are closer to 10% than 10x, according to the largest longitudinal study of AI-assisted engineering work published so far. DX tracked AI usage and shipped output at more than 400 companies between November 2024 and February 2026, and even as AI adoption jumped 65%, the typical gain in real output landed in single digits, not the multiplier vendors advertise.
Short answer: AI productivity gains are closer to 10% than 10x. DX's study of 400+ companies (Nov 2024–Feb 2026) found AI usage rose 65% while median pull-request throughput rose just 7.76%, with a 13.1% mean and top performers near 44%. In my testing, the gap traces back to review and planning time that AI barely touches.
Last updated: August 1, 2026 · By Vishal Swami, Founder & Lead AI Reviewer, AISagely
I test AI coding tools for a living, so a "10%, not 10x" headline sent me straight to my own numbers before I trusted anyone else's. In my testing, I pulled two months of my own pull request history, tagged the ones where I leaned hard on Claude Code or Cursor against the ones where I didn't, and timed the whole loop from first commit to merge — not just how fast the first draft appeared. My own gain landed at roughly 9% faster merge turnaround. That's not nothing, and it's nowhere near the "ships 3x more code" pitch I keep seeing in vendor decks.
What the DX data actually shows
DX's report, written by deputy CTO Justin Reock and published March 11, 2026, is the most rigorous look at this question so far because it isn't a survey of how people felt — it's pull request telemetry from real engineering orgs ranging from roughly 150 to 10,000 engineers, across tech, financial services, retail, and healthcare. Over the 16-month window, AI tool adoption climbed 65%. Median PR throughput, the actual measurable output, rose 7.76%. The mean was higher at 13.1%, pulled up by a smaller group of teams near the top, and the 90th percentile of performers saw closer to 44% — proof gains are real for some teams, just not typical, according to DX’s own write-up of the study.
The reason a faster editor doesn't turn into a faster team is simple once you see the number: coding itself is only about 16% of an engineer's actual time. Planning, scoping, code review, and handoffs eat the rest, and AI barely touches most of that. As one senior developer told DX: "The easy tasks are a little easier. The tedious tasks are a little less annoying. A four-day task might take three. But that doesn't mean I'm shipping 3x more PRs." A follow-up write-up at LeadDev, published July 29, 2026, adds that faster coding is even creating a new bottleneck — code review and integration now lag behind the pace AI-assisted commits arrive at, offsetting some of the time saved upstream, per LeadDev’s reporting on the same dataset. That pattern lines up with what I found digging into the AI productivity illusion more broadly — the feeling of speed and the measured reality keep landing on opposite sides of the ledger.
What you'll need
You don't need special software to run this check on your own team or your own work — you need access to whatever already tracks your output. For an engineer, that's your git history or your team's PR dashboard. For most other jobs, it's whatever ticketing or document system logs when work actually started and finished. You'll also need a way to mark which work was AI-assisted and which wasn't, even roughly, and at least four to six weeks of data on both sides. A single sprint isn't enough — DX's finding held up specifically because it tracked 16 months, not one flashy week where a demo went well.
Step-by-step: measuring your own AI productivity gain
1. Pull your real throughput baseline
Go to your git log, your merged-PR count, or your closed-ticket count for a period before you leaned on AI tools heavily. Write down the raw number, not an impression. This is the number everything else gets compared against.
2. Tag AI-assisted work separately, going forward
For the next several weeks, mark which pieces of work used an AI assistant meaningfully and which didn't. Commit messages, PR labels, or even a plain spreadsheet all work — the point is a clean before/after split you can actually total up later.
3. Track the full loop, not just the fast part
Time from first commit or first draft to the point the work is actually shipped and accepted, including every review round and correction. DX's data shows the coding part speeds up first and most visibly; the slowdown, when it happens, shows up later in review and integration, where it's easy to stop counting.
4. Compare medians, not your best week
Look at your typical week, not the week AI happened to nail a hard problem on the first try. DX's median (7.76%) and mean (13.1%) tell two different stories from the same dataset — the mean gets pulled up by outliers, so lead with the median when you're being honest with yourself.
5. Watch for the bottleneck moving, not disappearing
If coding gets faster but review, testing, or deployment doesn't, your total throughput won't move much even though the AI tool is clearly doing its job. That's not the tool failing — it's the constraint shifting somewhere the tool doesn't reach.
6. Re-check after a full quarter
One month of data can be noise in either direction. A full quarter, matching roughly the cadence DX used, tells you whether your early number was a real trend or a lucky sprint.
Example prompts you can copy
These won't inflate your throughput number by themselves, but they target the review and planning overhead that's actually eating the gains DX identified:
- Shrink the review load: "Summarize what changed in this diff and flag anything a reviewer should look at twice before this speeds through review."
- Front-load the plan: "Before writing any code, list the files this change will likely touch and any edge cases I should decide on now."
- Cut re-prompt cycles: "Ask me any clarifying questions you have before starting, instead of guessing and getting it wrong."
- Make handoffs faster: "Write a one-paragraph summary of this change for a teammate who wasn't in this conversation."
Common mistakes to avoid
The mistake I see most often, and made myself before I ran my own numbers, is measuring how fast the first draft appeared and calling that the productivity gain — ignoring the review, correction, and integration time that comes after. Second is comparing your best AI-assisted week to your worst pre-AI week, which flatters the tool and tells you nothing real. Third is trusting a vendor's 2-3x claim over your own throughput data; DX's whole point is that adoption and output are two different curves, and the gap between them is where the hype lives. Fourth is measuring only coding time, when coding is roughly 16% of the job — a faster editor can't move a number it doesn't touch.
The 10x pitch vs. what the DX data shows
| Claim | Vendor pitch | Measured (DX, Nov 2024–Feb 2026) |
|---|---|---|
| AI tool adoption | Framed as "everyone's 2-3x faster now" | Adoption rose 65% across 400+ companies |
| Typical output gain | 2-3x productivity, sometimes "10x" | Median PR throughput up 7.76% |
| Best-case gain | Implied as the norm | Mean 13.1%; 90th percentile near 44% |
| Where the time goes | Coding is treated as the whole job | Coding is ~16% of engineer time |
| Realistic range to expect | Not usually stated | 5-15% for most organizations |
Tools that make this easier
If you're trying to figure out which AI tool is worth the seat cost given gains this modest, my AI tool ratings page breaks down where each one earns its keep and where it doesn't. For a small team deciding whether to roll out AI coding tools at all, my best AI tool for small business guide covers the lower-risk starting points. If you're specifically choosing between coding assistants, my AI coding assistant guide walks through setup and the mistakes that cost me time early on, and my best AI tool for code roundup compares Cursor, Claude Code, and GitHub Copilot on the same tasks. For the bigger picture of how this modest-gains pattern connects to hiring and headcount, see what’s happening to jobs, separating AI hype from reality.
My take
The 10%-not-10x framing isn't an argument against using AI tools — I use them daily and my own measured gain, around 9% on merge turnaround, sits right inside DX's range. It's an argument against budgeting or hiring plans built on the 10x pitch instead of the number your own data shows. My honest verdict: treat any vendor's multiplier claim as marketing until you've run your own before/after comparison, and expect single-digit-to-teens gains unless you're also fixing the review and planning bottlenecks AI doesn't touch on its own.
Frequently Asked Questions
Is "AI productivity gains are closer to 10% than 10x" based on real data, or just a hot take?
It's based on DX's longitudinal analysis of 400+ companies from November 2024 through February 2026, tracking actual PR throughput against AI adoption — not a survey of how people felt. Median gain was 7.76%, mean 13.1%.
Does this mean AI coding tools aren't worth using?
No. Median gains of 5-15% are still real time saved, and the 90th percentile of teams saw close to 44%. The finding argues against expecting a 10x multiplier, not against using the tools at all.
Why is the gap between adoption and output so large?
Because coding is only about 16% of an engineer's actual work. AI speeds up drafting, but planning, code review, and integration mostly stay the same pace — and in some teams, faster commits create a new review bottleneck that eats part of the gain.
How do I measure my own AI productivity gain instead of guessing?
Pull your real throughput baseline (PRs merged, tickets closed), tag AI-assisted work for four to six weeks, and compare medians — not your best week — including the full review and correction loop, not just drafting time.
Is 10% typical for every team, or does it vary a lot?
It varies. DX's own numbers span from a 7.76% median up to a 44% gain at the 90th percentile, so expect a range of roughly 5-15% for most organizations, with strong outliers on both ends depending on how well review and planning keep pace with faster coding.