Does AI actually make developers more productive?

It makes them faster at writing code, which is not the same thing. Telemetry from 22,000 developers showed completed work per person up 66%, but bugs up 54%, code churn up 861%, and review time up roughly fivefold. Raw output rose. Stable, shipped value did not move much.

If AI makes me faster, where does the saved time go?

Mostly into review, debugging, and rework, and then into a backlog that refills. Writing code got cheap, so the easy 80% arrives fast and the hard 20% lands on you. Expectations also reset upward: the speed becomes the new baseline, so the saved hours never show up as free time.

What is the Jevons paradox in software?

The Jevons paradox says making a resource cheaper increases total use of it rather than reducing it. Cheaper coal meant more coal burned. Cheaper code means more code demanded: features that were not worth building become worth building, so the saved effort gets swallowed by a longer roadmap.

Why is reviewing AI code slower than writing it?

Writing and reviewing are different mental modes. When you write, the model lives in your head. When you review, you interrogate something a machine built, often as the first human to read it. AI can generate code far faster than any person can carefully verify it, so the bottleneck moves to review.

Who actually benefits from AI coding tools?

Solo developers and early startups with nobody downstream, teams on standard well-documented patterns, and outcome-focused cultures where finishing early means logging off. The cost lands on senior engineers reviewing machine output, developers on gnarly legacy systems, and anyone whose manager measures tool usage instead of results.

The AI Productivity Paradox, Explained Simply

Most developers will not say this out loud: the AI made them faster, and they are working more hours than before. Not because the tool failed. Because it worked.

In a 2026 study that tracked tens of thousands of developers, the teams that went all-in on AI shipped about 66% more completed work per person. Then researchers checked whether those companies were actually better off, on faster delivery, more stable software, bigger business gains. The answer was basically no. A separate survey of roughly 6,000 companies found that nearly nine in ten saw no measurable productivity improvement at all. That gap is the AI productivity paradox, and by the end of this you will know exactly where your saved time goes.

What is the AI productivity paradox?

The AI productivity paradox is the gap between two facts that should not both be true. AI coding assistants make individual tasks faster, yet most companies report no measurable productivity gain. Output goes up, with more code, more pull requests, and more closed tickets, but reviewing and debugging grow to match, and the saved time never lands as free time for the developer.

The word “productivity” is doing dishonest work here, because it is really three different claims wearing one coat. Pulling them apart is the whole game. One of them is solid. The other two are riding its coattails.

Claim 1 Holds up

AI makes individual tasks faster

True for the right task: boilerplate, scaffolding, a test for logic you already understand. This is the claim everyone can feel.

Claim 2 Shaky

AI makes you more productive overall

You produce more code, more pull requests, more closed tickets. But more is not the same as better, and the volume drags everything downstream.

Claim 3 No evidence

AI gives you your time back

Almost nothing supports this. The time saved on writing gets reabsorbed by review, debugging, and a backlog that refills before you notice.

Fig. 1 Fig. 1 — Three claims, one word. Claim 1 holds up. We assume claims 2 and 3 come free with it. They do not.

Did AI actually make developers faster?

Yes, at the task level, for the right kind of task. Drafting boilerplate, scaffolding a service, writing a test for logic you already understand: AI speeds those up, and the blank page basically disappears. That is claim one, and it holds up. The trouble starts when people quietly assume the other two claims ride along with it.

Claim two, that you are more productive overall, is shaky. You produce more, but more is not the same as better. Claim three, that AI hands you your time back, has almost no evidence behind it. Speeding up one task tells you nothing about your week, and your week is the thing you actually live in.

Follow the time: writing got faster, everything else got slower

When developers sped up, the telemetry did not just show output rise. It showed everything downstream get worse. The Faros AI “Acceleration Whiplash” report, built on two years of workflow data from 22,000 developers across more than 4,000 teams, is the cleanest look we have. Bugs per developer jumped by more than half. The amount of code thrown away and rewritten exploded. The time a pull request just sat there, waiting for a human, went up roughly fivefold.

Look at the shape of that. The writing got faster. The reviewing, the debugging, the cleanup, every part that needs a careful human, got slower, and there is far more of it now. The work did not vanish. It moved, from the part a machine is good at to the part only you can do. You got faster. Your company did not.

+66% Work shipped / dev

Epics completed per developer on the highest-AI-adoption teams. This is the gain, and it is real. Then it stops being good news.

+54% Bugs / dev

Defects per developer rose by more than half, up from a 9% bump in the 2025 data. The defect rate is steepening, not flattening.

+861% Code churn

Lines written and then deleted or rewritten within weeks. Nearly a tenfold jump in code that never should have shipped.

+441% Time in review

The median pull request now sits roughly five times longer waiting for a human to read it. Writing got fast. Reviewing did not.

Fig. 2 Fig. 2 — Faros AI telemetry. The one blue number is the gain everyone feels. The red ones are where it goes.

The freeway problem: why the speed never adds up

The reason the speed does not add up is one of the oldest results in economics. Make something cheaper and people do not bank the savings. They buy more of it. Widen a freeway to cut traffic, and within a year it is jammed again, because cheaper driving pulls in more drivers and longer commutes. The Victorians watched the same thing with coal: more efficient engines burned more of it, not less.

That last one has a name. The Jevons paradox says efficiency gains tend to raise total consumption of a resource rather than lower it. Code is now cheaper to produce, so demand for code expands to swallow the gain. The feature that was not worth building last year is worth building now. The two-week ticket comes back bundled with single sign-on, an audit log, and dark mode, and it still takes two weeks. The road got wider. The traffic showed up.

Cost of code DOWN

swallowed by

Demand for code UP

Freeways

Widen a jammed road and within a year it is jammed again. Cheaper driving pulls in more drivers and longer commutes.

Victorian coal

More efficient steam engines burned more coal, not less, because efficiency made coal worth using in new places.

AI code

The two-week ticket comes back bundled with single sign-on, an audit log, and dark mode. And it still takes two weeks.

Fig. 3 Fig. 3 — Induced demand. Drop the cost of a thing and demand rises to fill the space the cost used to occupy.

Why doesn’t faster coding give you time back?

Because the time saved becomes the new baseline before you can spend it. The first time you finish ten days of work in three, that does not turn into free time. It turns into the new normal. The next estimate shrinks. The expected scope grows. As one developer put it, the ceiling moved and I moved with it, without anyone asking me to.

There was no memo. The bar just rose to match your new speed, and now you are sprinting to stay level. You did not get time back. You got a quota. And the gain is invisible, because it is just an estimate that quietly got smaller, so you cannot even point to it. You cannot negotiate over time nobody admits you saved.

10 days of work in 3

The first time AI compresses the sprint, seven days of slack seem to open up. It looks like free time.

The ceiling drops to match

That speed becomes the new baseline. The next estimate shrinks, the expected scope grows, and the slack is gone.

You got a quota, not time

The gain is invisible because it is an estimate that got smaller. You cannot negotiate over time nobody admits you saved.

Fig. 4 Fig. 4 — The ratchet effect. Each speed-up resets the floor, so the slack never appears on your calendar.

Why does the work feel worse even when it’s faster?

Because the job changed shape. Writing code and checking code are two different mental modes. When you write, you build the thing and the whole model lives in your head. When you review, you interrogate something someone else built. AI flips the ratio: one developer can now generate code far faster than any human can carefully read it. As one engineer put it, as an author I am lightning fast, as a reviewer I am slow as molasses, and half the time I am the first person who has actually read this.

The machine also nails the easy 80%, the boilerplate and the happy path, then hands you the hard 20%: the edge case, the race condition, the integration with your weird legacy system, the part that needed you to understand code you did not write. Even the rhythm breaks. Real programming runs on flow, long stretches of focus. AI work runs on prompt, wait, glance at Slack, come back, re-read, correct, wait again. You are not in the work anymore. You are managing it.

As an author Lightning fast

You build the thing. The whole model lives in your head. Code pours out faster than ever.

flips to

As a reviewer Slow as molasses

You interrogate something a machine built, and half the time you are the first person to actually read it.

80% The easy part the machine nails: boilerplate, happy path

20% Handed back to you: edge cases, race conditions, legacy

Fig. 5 Fig. 5 — The bottleneck moved. AI flips the ratio toward reviewing, then hands you the hard 20% it cannot finish.

We have run this experiment before

If this feels new, it is not. The promise that a tool will shorten the work week is one of the most reliably broken promises of the industrial age. Back in 1987, economist Robert Solow looked at the whole computing revolution and quipped that you could see the computer age everywhere except in the productivity statistics. Spreadsheets and word processors were going to free us. Instead, demand for bigger reports and deeper analysis ate every hour they saved.

Go back further. In 1930, John Maynard Keynes predicted his grandchildren would work 15-hour weeks, because he correctly saw how much richer the world was about to get. The wealth arrived. The 15-hour week did not. The one thing that ever actually handed workers time back was not a gift from a tool. It was a law, the Fair Labor Standards Act of 1938. Every productivity revolution since has handed us more output. Not one of them, on its own, handed us more time.

1930

Keynes predicts a 15-hour week

He was right that the world would get far richer. The wealth arrived. The shorter week never did.

1938

The 40-hour week, by law

The one thing that ever actually gave workers time back was not a tool. It was the Fair Labor Standards Act.

1987

Computers everywhere but the stats

Solow's quip about the original productivity paradox. Spreadsheets saved hours; bigger reports ate them.

Fig. 6 Fig. 6 — A century of the same lesson. Tools delivered output. Only a law ever delivered a shorter week.

Who actually wins, and who pays for it?

Some developers do come out ahead, and pretending otherwise would be dishonest. If you are a solo developer or an early startup building something new with nobody downstream to review you, AI is rocket fuel. If your work is standard, well-documented patterns, basic CRUD or a stock front-end, you will feel a lift. And if you are somewhere with an outcome-focused culture, where finishing early on Wednesday means you log off on Wednesday, you might actually keep the time.

The people who absorb the cost are the mirror image. Senior engineers get pulled off architecture work to babysit a flood of machine-written pull requests. Anyone on a gnarly legacy codebase, where the AI guesses wrong with total confidence, unwinds it by hand. And watch the worst version: companies that cannot measure output, so they measure AI usage instead. Token counts on a dashboard, which is lines-of-code as a metric with extra steps. In 2026, reports surfaced of teams “tokenmaxxing”, burning tokens just to look busy on a leaderboard.

Keeps the gain

Solo devs and early startups

New code, nobody downstream to review you. AI is rocket fuel.

Standard, documented work

Basic CRUD, a stock front-end. Well-trodden patterns get a real lift.

Outcome-focused cultures

Finish early on Wednesday and you actually log off on Wednesday.

Absorbs the cost

Senior engineers

Pulled off architecture to babysit a flood of machine-written pull requests.

Legacy-codebase devs

The AI guesses wrong with total confidence, and you unwind it by hand.

Anyone measured by usage

When output is hard to track, managers count tokens. Lines of code with extra steps.

Fig. 7 Fig. 7 — Same tool, opposite outcomes. What decides it is usually what sits downstream of you, not the model.

Is this a tool problem or a boss problem?

This is the distinction people constantly blur, and keeping it apart is the honest version of the whole argument. There are two separate questions. Did the tool fail to make me faster? Or did the tool work, and did my employer pocket the entire gain? For a lot of developers it is the second one. The code came faster, and the saved time got scooped straight into a bigger backlog before anyone could feel it. That is not a broken tool. That is a question of who captures the surplus, and that is a much older fight than AI.

It matters because the fixes are different. If the tool is the problem, you need better tools and sharper skills, which is what disciplines like agentic engineering and spec-driven development are for. If the gain is being captured, no model upgrade will ever reach it.

Question	Tool problem	Boss problem
What happened	The AI did not actually make me faster	The AI worked; the saved time was captured
Where it shows up	Hallucinations, rework, review fatigue	Same hours, bigger backlog, smaller estimates
How old is it	New: probabilistic tools need supervision	Older than AI: who keeps the surplus
The fix	Better tools, tighter specs, sharper skills	Different incentives, not a better model
What will not fix it	Working longer to absorb the slop	The next model upgrade

The mental model to keep

The model to keep is this. AI coding tools can be making you faster at writing code while making your week longer, your codebase shakier, and your job market thinner, all at once. Those are not contradictions. They are the same paradox seen from different distances. The speed is real. The paradox just asks one question: who is it for?

Right now, by default, the gain flows to the backlog and the roadmap, not to you. That is not a reason to drop the tools. It is a reason to stop expecting them to hand you something they were never built to hand you. Time does not come back because a task got faster. It comes back when someone decides it should, and so far that someone has always had to be us.

Watch the explainer