The Jevons Paradox of Software Development

AI made code cheaper, so headlines say developers are finished. The Jevons paradox says the opposite, and I staff engineering teams for a living.

Abstract diagram of a falling efficiency curve feeding an expanding demand curve, representing the Jevons paradox in software
Abstract diagram of a falling efficiency curve feeding an expanding demand curve, representing the Jevons paradox in software

In 1865 a young English economist named William Stanley Jevons published a book about coal and accidentally wrote the most useful thing anyone has ever said about AI and software jobs. His worry, in The Coal Question, was the opposite of what you would expect. Engineers had made the steam engine far more efficient. Each ton of coal now did much more work. The obvious conclusion was that Britain would burn less coal. Jevons looked at the data and saw the country burning more of it, year after year, faster than before.

He named the mechanism plainly. When you make a resource cheaper to use, you do not reduce how much of it gets used. You expand the set of things worth doing with it, and total consumption climbs. Cheaper steam power did not satisfy the existing demand for mechanical work more thriftily. It made mechanical work cheap enough to deploy in places nobody had bothered to before, and the appetite grew to meet the new supply.

I think about that book constantly right now, because the dominant story about AI and software gets the economics exactly backwards, and I have a particular reason to care. I help companies decide how many engineers to hire and what those engineers should do. The headline version — AI writes the code, so the coders are finished — is the steam-engine fallacy wearing a hoodie. My position is that the Jevons paradox is the correct lens, that it predicts more developers rather than fewer, and that the data which seems to contradict this is real but is telling you something narrower than people claim. Let me earn each of those.

Name the principle

The paradox only fires under one condition: demand for the thing has to be elastic. If a country needs a fixed amount of mechanical work and no more, then making engines efficient really does cut coal use, and Jevons is wrong. His insight was that Victorian Britain's appetite for mechanical work was nowhere near satisfied. There was a deep reservoir of things people would do with cheap power that they would not do with expensive power. Efficiency drained the price barrier, the reservoir flooded in, and consumption rose.

So the real question for software is not "can AI write code?" It plainly can. The question is whether the world's demand for software is closer to fixed or closer to bottomless. If fixed, AI lets us meet that demand with fewer people and the pessimists are right. If the demand is a reservoir held back by the cost of building, then making software cheaper to build floods the field with work, and the people who build software become more wanted, not less.

Everything I have watched in twenty years of running and advising engineering organizations says software demand is a reservoir, and a vast one. Every company I have sat inside carries a backlog of things it would build if building were cheaper: the internal tool nobody can justify, the integration that stays manual, the report a human still assembles by hand on the last Friday of the month. That backlog is not a rounding error. It is most of the iceberg. The software that exists is the fraction that cleared the cost bar. The software that does not exist, blocked purely by the price of building it, dwarfs the software that does.

Software has run this experiment before

We do not have to reason about this purely from theory, because the cost of writing software has been falling for forty years and we know what happened each time. The assembler programmer who watched the first compilers arrive could have concluded that a machine writing machine code would end the profession. Instead, compilers made software cheap enough that vastly more of it got commissioned, and the number of people paid to program went up. Every layer since told the same story. High-level languages, garbage collection, open-source libraries, cloud infrastructure that abolished the need to rack your own servers, the framework that turns a week of plumbing into an afternoon. Each one was, in its moment, a large cut in the cost of producing working software. Not one of them shrank the profession. Every one of them grew it.

The reason is the part Jevons would recognize. Each efficiency gain did not let us build the same amount of software with fewer people. It dropped the price of software low enough that a new tier of projects became worth doing, and the new projects needed people. The work moved up the stack — fewer hand-managed memory allocations, more product decisions — but it did not evaporate. It multiplied.

AI-assisted coding is the next entry in that ledger, and a big one. Calling it a different kind of thing because it touches the keystrokes directly is, I think, a failure of imagination about where the actual work lives. Typing was never the bottleneck. I have never once staffed a team and worried that the constraint was words-per-minute into an editor.

An endurance read of the same data

Here is where the way I think about training earns its place, because it is the same reasoning error in a different costume. When a runner first starts using a power meter or a structured plan, their efficiency jumps — they get more fitness out of each hard session. The naive prediction is that they will now train less, because each unit of effort buys more. What actually happens is the opposite. Efficient training makes progress feel attainable, the athlete sees what another block could unlock, and total training load goes up, not down. The improved return on effort raises the appetite for effort. I have lived this through more than one race build: the better my sessions converted, the more I wanted to do, never fewer.

Cheaper, more efficient production does not sate demand when the underlying appetite is deep. It feeds it. A developer who can now ship in a day what used to take a week does not become a developer the company needs one-fifth as much of. They become a developer who can finally clear the backlog that was always there, which makes the next item on the backlog suddenly worth starting, which is how reservoirs drain into rivers. The constraint stops being how fast you can produce software and becomes how much software is worth producing — and that number has only ever gone up.

Now the part that contradicts me

If I stopped here I would be doing the thing I criticize: telling a clean story and ignoring the data that bites. So here is the bite. The near-term numbers, right now, point the wrong way for my thesis, and I am not going to wave them off.

Stanford economists led by Erik Brynjolfsson published a study in 2025, bluntly titled "Canaries in the Coal Mine?", tracking high-frequency payroll data. Their finding for my field is hard to dismiss: by mid-2025, employment of young software developers was down close to 20% from its late-2022 peak. Across the most AI-exposed occupations, early-career workers saw a roughly 13% relative decline since generative AI went mainstream, even after controlling for company-level shocks — while older workers in the same fields kept growing. That is not noise. That is a real, measured contraction landing on exactly the people the optimistic story is supposed to protect.

A weaker writer would now reach for "but it is early." That is true and it is not enough. The stronger objection to my own thesis is this: maybe software demand is not as elastic as I claim, and we are watching the efficiency gain meet a more-or-less fixed appetite with fewer juniors. If that is what is happening, Jevons does not apply and I am wrong.

Compositional shock, not structural reversal

Here is why I do not think that is what the data shows, and where I will stake the position. What the Stanford numbers describe is a compositional shock, not a structural reversal of the demand curve. The decline is concentrated at the entry level — the exact rung whose job was the most codified, most boilerplate-heavy, most automatable slice of the work. AI did not reduce the need for software. It reduced the need for the specific tasks that used to fill a junior's first two years, and the staffing math followed.

That distinction matters because it changes what you predict next. A structural reversal would show up everywhere — senior demand falling too, total developer headcount trending down, the aggregate projections rolling over. That is not what the broader sources show. The U.S. Bureau of Labor Statistics still projects 17.9% growth in software developer employment from 2023 to 2033, far above the average for all occupations. The World Economic Forum's Future of Jobs Report 2025 lists software and application developers among both the fastest-growing roles in percentage terms and the largest in absolute net new jobs. Gartner's software-engineering outlook is titled, with no ambiguity, "AI Will Not Replace Software Engineers — It Will Require More", and argues that as AI cuts the cost of software, demand for software and for the people who build it grows.

So we have a genuine near-term contraction at the bottom of the pyramid sitting alongside multi-year forecasts of strong net growth. Those are not contradictory once you stop treating "developer" as one undifferentiated job. The entry tier is being automated and recomposed at the same time the total demand for software keeps climbing. The reservoir is still draining into the field. What changed is the kind of bucket the field hands a beginner.

Where the work actually goes

When I decide how to staff a team today, the math has genuinely shifted, and I would be lying to call it business as usual. I need fewer people to convert a clear specification into working code. I need more people who can decide what is worth building, judge whether the AI-written code is actually correct, hold the architecture in their head, and own the system when it pages someone at 3 a.m. That work is not shrinking. The volume of software is rising, and every additional system someone ships is one more thing that has to be decided on, reviewed, integrated, and owned. AI compresses the typing and inflates everything wrapped around the typing.

The uncomfortable truth inside the good news is that the traditional on-ramp got steeper. The junior rung where you wrote boilerplate under supervision and absorbed judgment by osmosis is the rung AI ate first. That is a real problem and the recent data is the early warning. But "the entry path is harder" is a different claim from "the profession is dying," and conflating the two is how you end up advising a sixteen-year-old to avoid the single field that every aggregate forecast says will keep growing for a decade.

The position

So here is where I land, without hedging. The Jevons paradox is the right model for AI and software, and it predicts more developers, not fewer — because software demand is a deep reservoir that cheaper production floods rather than drains. The near-term entry-level contraction is real, it is painful, and it is a compositional shift in what beginners do, not evidence that the demand curve flattened. The thing to watch is not the headcount headline. It is whether the latent demand for software ever runs dry. As long as every company I walk into is still carrying a backlog of software it would build if building were cheaper — and that has been true in every single one — Jevons keeps winning, and the people who build software stay scarce relative to what the world wants from them. AI made coding cheap. History is clear about what happens to a resource when you make it cheap. You get more of it, and more of the people who work with it, doing work that looks different from the work before.

Frequently asked questions

What is the Jevons paradox in software development?

The Jevons paradox is the observation that making a resource cheaper to use tends to increase total consumption of it, not decrease it. Applied to software, it predicts that AI lowering the cost of writing code will raise the total amount of software the world builds, because cheaper production unblocks demand that was previously priced out. More software being built means more work, not less, for the people who build it.

Will AI reduce the number of developer jobs?

In the near term it already has at the entry level: Stanford research found employment of young software developers down roughly 20% from its late-2022 peak by mid-2025. But aggregate projections point the other way — the U.S. Bureau of Labor Statistics still forecasts 17.9% growth in software developer employment from 2023 to 2033. The honest read is that the work is being recomposed faster than it is shrinking.

Does the Jevons paradox apply to AI coding?

It applies if the demand for software is elastic — if cheaper software produces more of it rather than the same amount for less money. Forty years of history says software demand is highly elastic: every prior drop in the cost of building it was met by an explosion in how much got built. The paradox holds as long as there is still latent demand for software that cost used to block, and there is no sign we have run out.

Why do developer jobs grow if AI writes the code?

Because writing the code was never the whole job. Deciding what to build, judging whether it is correct, integrating it, owning it when it breaks at 3 a.m. — that work expands as the volume of software expands. AI compresses the typing and amplifies everything around it. When each developer can ship more, the binding constraint moves from how fast you can write code to how much software is worth building, and that number keeps rising.

Is software engineering still a good career?

Yes, but the shape of the entry has changed and pretending otherwise is dishonest. The junior rung where you got paid to write boilerplate while you learned judgment is the rung AI eroded first, which is exactly what the recent entry-level data shows. The career is still strong for people who build judgment quickly — knowing what to build, reading a system, owning outcomes — because that is the part AI makes more valuable, not less.

Frequently Asked Questions

What is the Jevons paradox in software development?

The Jevons paradox is the observation that making a resource cheaper to use tends to increase total consumption of it, not decrease it. Applied to software, it predicts that AI lowering the cost of writing code will raise the total amount of software the world builds, because cheaper production unblocks demand that was previously priced out. More software being built means more work, not less, for the people who build it.

Will AI reduce the number of developer jobs?

In the near term it already has at the entry level: Stanford research found employment of young software developers down roughly 20% from its late-2022 peak by mid-2025. But aggregate projections point the other way — the U.S. Bureau of Labor Statistics still forecasts 17.9% growth in software developer employment from 2023 to 2033. The honest read is that the work is being recomposed faster than it is shrinking.

Does the Jevons paradox apply to AI coding?

It applies if the demand for software is elastic — if cheaper software produces more of it rather than the same amount for less money. Forty years of history says software demand is highly elastic: every prior drop in the cost of building it was met by an explosion in how much got built. The paradox holds as long as there is still latent demand for software that cost used to block, and there is no sign we have run out.

Why do developer jobs grow if AI writes the code?

Because writing the code was never the whole job. Deciding what to build, judging whether it is correct, integrating it, owning it when it breaks at 3 a.m. — that work expands as the volume of software expands. AI compresses the typing and amplifies everything around it. When each developer can ship more, the binding constraint moves from how fast you can write code to how much software is worth building, and that number keeps rising.

Is software engineering still a good career?

Yes, but the shape of the entry has changed and pretending otherwise is dishonest. The junior rung where you got paid to write boilerplate while you learned judgment is the rung AI eroded first, which is exactly what the recent entry-level data shows. The career is still strong for people who build judgment quickly — knowing what to build, reading a system, owning outcomes — because that is the part AI makes more valuable, not less.

For CTOs & Tech Leaders

Need Expert Technology Guidance?

20+ years leading technology transformations. Get a technology executive's perspective on your biggest challenges.