Jevons’ Paradox and the Fate of Software Developers in the Age of AI Coding

I have spent most of my career building software-based companies and have been deep in AI for the last several years. So people ask me constantly what happens to software developers in the age of AI-augmented software development.

I do not think anyone knows the answer for sure, myself included. But I think the question is more interesting than most treatments suggest, and Jevons’ Paradox, a 1160-year-old economic puzzle, sheds some useful light on it.

The Intuition That Keeps Being Wrong

In 1865, William Stanley Jevons noticed something that a naive take might suggest was impossible. Britain’s steam engines were getting more efficient, burning less coal per unit of work. The sensible prediction: Britain would need less coal. What actually happened: coal consumption exploded. Efficiency lowered the effective cost of using coal, which widened its applications, deepened its adoption, and increased total consumption. The cheaper the fuel, the more uses people found for it.

I think the same logic applies to AI coding and developer employment. At first glance, AI appears to threaten the profession. If a model can write boilerplate, generate tests, explain unfamiliar APIs, and accelerate debugging, then surely firms will need fewer programmers. That conclusion feels natural. It is also almost certainly wrong.

Here’s the mechanism. AI does not merely substitute for developers. It lowers the cost of turning an idea into working software. When the cost of production falls, demand rarely sits still. Projects once judged too small to justify a team suddenly become feasible. Internal tools that were postponed become worth building. Startups can attempt products that would previously have required twice the capital. The frontier of what is economical moves outward.

The central question is not whether AI can make one developer more productive. It plainly can. The question is whether demand for software will expand faster than productivity improves. If it does, total employment can grow even while code generation itself becomes less labor-intensive.

I think the demand expansion will be enormous. And not just because software is cheap to copy. The real reason is structural, and it makes software fundamentally different from coal.

Software Is Not Coal

Coal had diminishing returns. You can only heat a building so much, drive a locomotive so fast, smelt so much iron per furnace. Coal’s applications, while numerous, were bounded by the physics of combustion. Eventually coal consumption plateaued and declined, displaced by oil, gas, and renewables. A sharp reader will ask: doesn’t this undermine the analogy?

Not quite. Software has properties coal never had, properties that make the paradox apply more forcefully, not less.

First, software is combinatorial. Every new piece of software creates integration surfaces that demand more software. A company builds a customer database; now it needs analytics, reporting, API access, mobile views, compliance logging, backup systems, and migration tools. Each layer creates demand for the next. Coal never did this. Burning coal in a factory did not create demand for more coal in the accounting office.

Second, software has near-zero marginal cost of distribution but near-infinite marginal cost of customization. The generic product ships free; the version that actually fits your workflow requires engineering. This means cheaper production does not just make existing software cheaper. It creates entirely new categories of products: software tailored for smaller niches, narrower use cases, shorter lifespans.

Third, the physical world remains massively under-digitized. Take a 50-person manufacturing company. Today they probably have an ERP system they hate, a handful of spreadsheets that run the shop floor, and a whiteboard for production scheduling. Imagine software development costs drop by 10x. Now it makes economic sense to build a custom tool that reads their specific CNC machines’ output, tracks scrap rates by operator and shift, flags quality drifts before they hit the customer, auto-generates compliance documentation for their industry certifications, and integrates all of that with their specific accounting workflow. None of that software exists today because the economics did not justify building it. Change the economics, and it gets built. Multiply that by every hospital, law firm, school district, trucking company, and farm co-op in the country. That is a lot of software waiting to exist.

Who Prospers, Who Doesn’t

Jevons’ paradox is about totals, not about symmetry. This is where the comfortable version of the story breaks down.

The standard narrative goes: developers move “up the value chain.” Less time typing routine code, more time deciding what to build, integrating systems, verifying correctness, designing abstractions, translating messy human requirements into computational form. The bottleneck moves from production to judgment.

That is probably right as far as it goes. But it obscures something important: the people who move up are not necessarily the same people who held the jobs before.

When spreadsheets arrived, they did not help accountants uniformly. They destroyed bookkeeping as a standalone profession while creating financial analyst roles that required different people with different training. When desktop publishing improved, it did not make every typesetter into a graphic designer. The skill set changed, and the population changed with it.

The same thing will happen in software. The developer who thrives in an AI-assisted world is the one who can operate at the layer above code: system architecture, failure mode analysis, security reasoning, organizational translation, domain modeling. These are not skills that junior developers automatically acquire by promotion. They are skills some people have and others do not, regardless of years of experience. The person who was great at writing clean, careful Java may not be the person who is great at specifying constraints for a code-generating AI and auditing its output across a complex dependency graph.

So when I say “total employment may rise,” I mean it. But I do not mean every current developer keeps their job. Some tasks will be commoditized. Some entry-level work will become scarcer in its traditional form. Some firms will keep headcount flat and demand more output from existing teams. In the short run, there will be displacement even if the long run brings expansion. The paradox does not promise comfort. It describes a mechanism.

The Bottleneck Might Not Be Where You Think

The pure Jevons framing dodges a harder question. The paradox operates in markets with price-sensitive demand. Is software demand actually that price-elastic?

Go back to the 50-person manufacturer. They have not built custom software because they do not have anyone who can specify what it should do, manage its implementation, or handle it when it breaks. The bottleneck is not just cost. It is organizational capacity to absorb change. The hospital has not digitized its remaining manual processes because regulatory friction, staff resistance, and integration complexity make each project a nightmare regardless of whether the code is cheap to write.

But that capacity is itself partly a function of cost. When building and maintaining software is expensive, organizations rationally limit how much of it they take on. Drop the cost far enough and the calculus changes. That manufacturer can now afford to bring on a part-time technical person, or the AI tools themselves lower the bar for specifying and managing the software. The resistance is real, but it is not fixed. It bends when the economics shift hard enough. This is the weakest link in the argument, and an honest accounting has to say so. I think cost is still the dominant constraint. I am less certain than I would like to be.

The AI Moves Upward Too

Even if demand expands enough to absorb the productivity gains, a different threat remains. One more challenge keeps me from full confidence. The “humans move up the value chain” argument assumes the value chain has a stable top. It does not.

Today’s coding assistants handle boilerplate. Tomorrow’s may handle architecture. Next year’s may translate business requirements directly into system specifications. The window of “uniquely human” judgment is not a ledge. It is a scaffolding plank that AI keeps raising from below. If AI compresses the gap between “what to build” and “working system” to near zero, the developer role does not just shift. It dissolves into something closer to product management or systems thinking, and we are in a different conversation entirely.

I do not think we are there yet, and I do not think we will be soon. A model can propose an implementation. It cannot sit in a room where the VP of Sales wants one thing, the compliance team wants another, the legacy system cannot do either, and the budget covers half. Those frictions do not disappear when code gets easier to write. They intensify, because faster production means more software to supervise, more dependencies to audit, more generated code to understand, and more systems whose failures have consequences.

But “not yet” is not “never.” And anyone planning a career should think hard about what happens when the plank keeps rising.

What to Watch

Rather than making a prediction, let me suggest what to watch for. The outcome depends on a handful of variables, and the evidence will arrive over the next five to ten years.

Is latent demand deep or shallow? The Jevons argument rests on the claim that the world has a nearly bottomless appetite for custom software. The history of computing suggests it might: every previous drop in development cost (from assembly to high-level languages, from mainframes to PCs, from desktop to web, from web to mobile) triggered a wave of new applications nobody anticipated. But past performance is not a guarantee. If demand saturates quickly once AI drops costs, the displacement story wins. Watch what happens in industries that have never had much custom software: construction, agriculture, small-scale manufacturing, local government. If those sectors start absorbing developers, the demand reservoir is real.

Does AI augment or replace? If AI coding tools function like a power tool in the hands of a carpenter, making skilled workers faster and more versatile, we are in Jevons territory. If they function more like a robotic assembly line, eliminating the carpenter entirely, we are in substitution territory. The answer will probably differ by type of work. Boilerplate and glue code look substitutable today. System design, failure analysis, and organizational translation do not. The question is how fast the boundary moves.

How fast does AI climb the abstraction ladder? This is the scaffolding plank problem from the previous section, restated as a variable. If AI capability plateaus at code generation and stays weak at architecture, integration, and requirements negotiation, then human developers retain a durable role. If AI pushes rapidly into those higher-order functions, the “move up the value chain” strategy runs out of room. Nobody knows the trajectory. Watch what AI can do with ambiguous, contradictory, and incomplete specifications. That is the real test, not whether it can write a sort algorithm.

What happens to the junior developer pipeline? This one gets too little attention. If AI eliminates most entry-level coding tasks, where do the next generation of senior architects and system designers come from? Those skills are built by years of working with real codebases, debugging real failures, and learning what happens when abstractions leak. If the apprenticeship path narrows, the supply of experienced developers could shrink even as demand for their judgment grows. That bottleneck would reshape the profession in ways Jevons’ paradox does not capture.

Can organizations actually absorb the software? I flagged this in the bottleneck section, and it deserves a spot here. Cheap code is only useful if organizations can deploy it, maintain it, and adapt when it breaks. The 50-person manufacturer needs not just software but the capacity to manage software. If organizational absorption remains the binding constraint, demand expansion will be slower and messier than the pure economics suggest.

These variables interact. If demand is deep and AI augments rather than replaces, we get a boom. If demand is shallow and AI climbs the ladder fast, we get contraction. The most likely scenario is some messy combination, varying by industry, by skill level, and by geography. I lean toward the expansionary case, but I hold that view lightly.

Multiplication, Not Replacement

The most plausible outcome is not a simple story of disappearance or triumph. It is multiplication with redistribution.

AI coding makes software cheaper. Cheaper software invites more uses. More uses require more oversight, more adaptation, more integration, more invention. The developer of the future may write fewer lines by hand but will be asked to bring software to corners of the economy that never had it before. Total demand for the work expands. The specific skills that matter shift, and not everyone who held the old skills will hold the new ones.

Efficiency is rarely the end of a story. In software, as in coal, what becomes cheaper tends to become more pervasive. The paradoxical consequence of AI coding may be that the better machines get at producing code, the more civilization asks developers to do.

Whether that is good news depends on which developer you are.