Jevons Paradox and AI: What Happens to Software Jobs
AI is making software cheaper to build. Learn why demand may surge, why jobs can still disappear, and how history helps distinguish the two outcomes.
AI Can Make Software More Abundant - and Developers Less Needed
AI tools are cutting the time and cost of producing software. That's sparked a familiar argument: if it's cheaper to make something, people will want more of it - so overall demand for the work grows. The idea is often wrapped into what's called the Jevons paradox, and it's used to argue that AI will expand software development rather than reduce it.
There's a real mechanism behind that claim. When software becomes affordable, teams can justify projects they would have ignored before. But demand for a product doesn't automatically translate into demand for the specific people who used to build it. History has examples both ways: more efficient technologies can expand an industry for decades, while automation can remove roles even as usage keeps climbing.
So the key question isn't only whether AI will produce more software. It's whether it will make developers more productive at the work that still matters - or take over tasks that no longer require a person. This article looks at what Jevons actually argued, what earlier technologies can (and can't) tell us, and how to judge what AI is likely to do to software work.
What the Jevons paradox actually says
In 1865, British economist William Stanley Jevons published The Coal Question. Britain relied on coal, and the debate was whether more efficient engines would conserve it. Jevons argued that efficiency could do the opposite: if coal got cheaper to use, coal-powered activity could become more profitable, pulling in investment and increasing demand.
His example was iron production. If a furnace used less coal per ton of iron, the cost of iron dropped. Lower prices could attract new customers and encourage more output. Each furnace became more efficient, but the number of furnaces rose enough that total coal consumption increased. Jevons pointed to the hot blast process in Scotland, where coal use per ton of iron fell sharply even as total coal use in the iron industry rose.
That idea is now widely known as the Jevons paradox. The point is about total consumption, not just efficiency. A machine can use less per unit, but if the unit price falls enough, overall use grows.
The "second half" is about employment
Jevons also applied a similar logic to labor. He noted that new machinery might displace workers at first, but that cheaper goods could expand demand enough to bring employment back - or even create new jobs. His example was the sewing machine: if sewn goods got cheaper, more people could afford them, and the trade might grow enough to support seamstresses in new or expanded roles.
That can happen, but it isn't guaranteed. The chain has multiple steps: a tool lowers production costs; lower costs reach customers; customers buy a lot more; and the resulting work still needs people. Break any link, and the outcome changes.
That matters for AI. If you see people producing more software, you can infer that output is rising. But you can't conclude that more people will be hired or paid for that work. Employment depends on which tasks remain, how much demand expands, and how organizations choose to meet it.
Efficiency is not the same as a jobs forecast
The Jevons paradox is sometimes used like a reassurance: productivity grows demand, so workers will be fine. It's useful for explaining why total resource use can rise when things get cheaper. It doesn't tell you who benefits, how fast industries change, or whether a specific occupation survives.
For AI and software, keep two questions separate:
- Will cheaper development lead to more software being built? That's about demand and output.
- Will the extra software require more human development work? That's about task composition and business choices.
Those answers can diverge. More apps, internal tools, and automated workflows might show up even as headcount per app stays flat - or shrinks. Demand can rise while employment shifts, stagnates, or falls.
When cheaper products create more work
The strongest case for AI increasing software work starts with projects that were too expensive to build before. A team might now put together a small internal calculator, a one-off reporting tool, or a customer feature that wouldn't have justified a full development effort. When costs drop, "not worth building" can turn into "good enough to ship."
That's not purely theoretical. Developers already use AI to draft code, tests, and documentation, and to explore options faster. When the cost of a first version drops, it becomes easier to try more ideas. Businesses can test more experiments, and individuals can build tools for narrower needs instead of relying only on broad, general-purpose products.
Demand depends on how people respond to lower prices
Economists describe this as price elasticity of demand - how strongly demand changes when price changes. If a 1% price drop leads to more than a 1% increase in demand, total spending on the product can rise. If demand responds less, total spending might fall even as more units are sold.
Two examples make the point. If a software feature becomes much cheaper and thousands of businesses adopt it, demand could rise enough to support more product and engineering work. But if an automated system handles an existing task once and then runs at scale with little ongoing effort, output can grow without a matching rise in labor.
More things produced doesn't automatically mean more people needed. That's why "AI will create more software" doesn't settle the jobs question.
History shows both expansion and limits
Lighting gives a good example of the demand-expansion story. Research by Roger Fouquet and Peter Pearson found that light became dramatically cheaper in the UK over the long term, while consumption rose much more than the price fell. People didn't just pocket the savings - they used more light in homes, workplaces, and public spaces.
Food shows the other side. Agricultural productivity rose, and the cost of producing food declined. But people have practical limits on how much they eat. In the US, the share of the workforce in agriculture fell from about 41% in 1900 to under 2% in 2000. Productivity made food cheaper and more available, but demand couldn't expand indefinitely to absorb labor displaced from farming.
So the difference isn't that one industry followed a magical rule and the other didn't. Demand has different ceilings. People can use far more light, energy, or digital services than earlier generations could. They can't eat proportionally more meals just because food gets cheaper to produce.
Software likely has similar unevenness: some areas may see demand respond strongly, others less so. Cheaper software could make bespoke tools common. It could also mean that one agent generates thousands of routine variations without hiring a person for each one. Which outcome dominates will vary by product, sector, and task.
Why demand growth does not protect every job
Even the coal story is a warning against treating Jevons like a law that always holds. British coal output rose for decades after Jevons made his argument, peaked in 1913, and then fell into a long decline. New energy sources and shifting industrial economics eventually mattered more than the earlier growth in coal use. Rising demand didn't guarantee the industry's future.
Banking offers a closer comparison for software work. ATMs reduced the number of tellers needed at individual branches. In research on US banking, economist James Bessen found that lower operating costs helped banks open more branches, so teller employment didn't vanish immediately. But the job changed: tellers spent less time dispensing cash and more time dealing with customers.
Later, online banking and mobile deposits changed the economics again. Customers could handle more tasks without visiting a branch. Even if banking activity kept growing, branch visits - and the need for some branch-based work - declined. The first technology reshaped the job; the later one reduced the need for the place where that job used to happen.
A task can disappear while demand for the service grows
Telephone operators show the sharper version. For much of the early 20th century, connecting calls was a substantial job for American women. Mechanical switching replaced much of that work. People kept making phone calls, but the service no longer required an operator to connect each call.
That's central for AI. A technology can expand the market for a service while removing a task from the production process. More calls didn't create more manual switchboard work. Likewise, more software can mean more product decisions, system integration, and review - but not necessarily more demand for routine code writing.
There's also a difference between people already in a job and people trying to enter it. Research on automation finds cases where displaced workers move into other expanding fields, while people trying to enter shrinking occupations face fewer openings. A growing economy doesn't automatically protect every worker or make transitions painless.
The shape of the work matters
A helpful comparison is whether AI acts more like a sewing machine or a switchboard. A sewing machine makes a worker faster at a task while leaving much of the surrounding work intact. A switchboard system takes over the task of connecting calls.
In software development, AI can resemble a sewing machine when it helps a developer write a test, inspect a codebase, or implement a well-defined component. The developer still needs to understand what the behavior should be, assess what comes out, and take responsibility for the effects.
AI can resemble a switchboard when a task is narrow, repetitive, and easy to verify - for example, translating a clear specification into a routine code change. If that task can be handed off end to end and checked cheaply, an organization may need fewer people to do it.
Most jobs mix these kinds of work. The practical issue is what share of a role is made up of tasks AI accelerates, tasks it replaces, and tasks it creates or makes more valuable. Job titles alone don't answer that.
How to judge AI's effect on software work
There's evidence that software output is increasing as AI tools improve and become cheaper to use. But metrics like model usage, code repositories, or new app releases are imperfect stand-ins. They don't tell you how useful the output is, how much human effort it required, or whether the work came from new hires, existing teams, or automation.
Employment signals are mixed too. US Bureau of Labor Statistics projections for software developers have softened across successive releases, while projections for computer programmers look weaker. The categories aren't interchangeable: "programmer" usually describes a narrower set of coding tasks than the broader "software developer" role. Projections aren't destiny, but the difference is consistent with the idea that routine implementation work faces more pressure than work involving broader system responsibility.
Research from Stanford economists Erik Brynjolfsson and colleagues has also reported weaker employment outcomes for younger workers in occupations more exposed to AI, including software-related roles. That doesn't prove AI is the only cause. Still, it raises a real concern: firms may reduce entry-level hiring when AI can handle tasks that used to help junior employees learn.
Use a two-part model
A simple model clarifies what would have to be true for demand growth to protect employment. Suppose labor is the main cost of producing software. If a developer becomes g times faster, labor cost per feature drops to about 1/g of what it was. If demand then grows by g raised to the power of e - where e reflects how strongly demand responds to lower cost - total labor demand shifts roughly with g to the power of e, divided by g.
If demand grows faster than productivity, labor demand can rise. If demand grows more slowly, the industry may produce more software with fewer labor hours. This isn't a measurement of software's true elasticity, and no single number fits every type of software or business model. It's a way to spotlight the missing piece in confident forecasts: how much additional demand does lower cost create?
For a real team, you then need a second question: which tasks are included in those labor hours? Even if total engineering work rises, demand for a specific specialty or level of experience can fall. The work may shift toward defining requirements, reviewing agent-generated changes, securing systems, and integrating software into operations.
Track the work, not just the headlines
Companies trying to understand what's happening should measure changes at the task and workflow level. Practical questions include:
- Which tasks take less time with AI, and how often is the time saved still real after review and rework?
- Are teams building more features or products because costs fell, or mostly delivering the same scope with fewer hours?
- Which tasks can an agent complete and verify on its own, and which still need human judgment or accountability?
- Does the shift change hiring, team size, seniority mix, or how much work is outsourced?
- Are new tools improving outcomes in production, or just speeding up prototypes?
These measures expose trade-offs. An AI tool can speed up code generation, but increase time spent debugging, reviewing permissions, or fixing misunderstandings. It can also let smaller teams serve more customers without increasing headcount. Both outcomes are possible, sometimes in the same company.
Make plans that can survive either outcome
For developers, the safer stance isn't to assume coding disappears or stays untouched. Build your value around parts of software work that are harder to specify and validate mechanically: understanding user needs, making system-level trade-offs, testing real behavior, managing security, and operating software after launch. None of those are guaranteed safe from AI either - but they're areas where technical output ties directly to product and business outcomes.
For employers, cutting hiring based on short-term productivity gains can create a future skills gap. Junior work isn't just cheap implementation; it's also how people learn to maintain systems and make good decisions. If AI removes that learning pipeline, teams will need another deliberate way to train and evaluate future engineers.
A prudent approach is to test AI in real workflows, measure output quality and total delivery cost, and adjust staffing assumptions as evidence accumulates. Forecasts will change. Feedback from production is more useful than treating today's model capabilities as either a permanent ceiling or a promise.
Conclusion
Jevons's argument helps explain why efficiency can expand demand, not why every worker will benefit. Cheaper software makes more ideas worth building - especially smaller, specialized tools that used to be too costly. That's the expansion side of the story.
The other side is that demand growth doesn't protect every task. Sewing machines made some workers more productive; mechanical switching removed the operator role from phone connections. AI can do both kinds of work, sometimes within the same development team.
The clearest way to assess the change is to separate output from employment, then examine which tasks AI accelerates and which it takes over. For builders and business leaders, the practical test isn't whether AI writes code. It's whether the full workflow - requirements, implementation, verification, and operation - still needs the same amount of human effort, and what new work becomes worth doing when costs fall.