Jevons Paradox and Software Engineering
The Core Pattern#
Software engineering has been getting easier since its inception. Every decade brings new abstractions, better tools, higher-level languages, and more powerful frameworks. The learning curve for building functional applications has dropped dramatically. What required expert knowledge in 1970 is now undergraduate coursework. What took a team of specialists in 1990 can be done by a single developer today.
And yet, at no point has the industry contracted. Quite the opposite. The field has grown at exponential rates. The easier we make it to build software, the more software we build, and the more people we need to build it. This isn’t an anomaly or a temporary effect. It’s a fundamental pattern that has repeated for seventy years without exception.
Understanding why this happens requires looking at an economic principle discovered in the 19th century, one that explains not just software engineering’s growth, but the growth of computing itself.
Historical Evidence#
When assembly language gave way to high-level languages like FORTRAN and COBOL, writing software became orders of magnitude easier. Developers no longer needed to manage registers or think about memory addresses for every operation. This efficiency gain didn’t result in fewer programmers. It resulted in the birth of the commercial software industry. Companies that never would have attempted software projects suddenly could. Applications that were economically infeasible became viable.
The transition from mainframes to personal computers followed the same pattern. Computing became accessible to individuals and small businesses. The result wasn’t less software development. It was software everywhere, for everything. Word processors, spreadsheets, databases, games, educational tools. Personal computing created entire categories of software that didn’t exist when computing was expensive and centralized.
Garbage collection eliminated an entire class of memory management bugs. Languages like Java and C# automated away one of the most difficult and error-prone aspects of programming. This didn’t lead to smaller development teams. It led to bigger, more ambitious projects. Systems that would have been too risky to build with manual memory management became routine.
Cloud infrastructure compressed the time to provision a server from weeks to seconds. The labor involved in deploying and maintaining infrastructure dropped dramatically. The result wasn’t fewer servers or smaller infrastructure teams. It was millions more servers running services that never would have been built if infrastructure remained expensive. Startups could launch with infrastructure that would have required a full operations team a decade earlier.
The shift from waterfall to agile to continuous integration and deployment made shipping software faster and more reliable. Teams could deploy multiple times per day instead of once per quarter. This efficiency didn’t reduce the need for developers. It created an expectation of constant iteration, feature flags, A/B testing, and rapid response to user feedback. More efficiency led to more work, not less.
Jevons Paradox#
In 1865, economist William Stanley Jevons observed something counterintuitive about coal consumption in England. As steam engines became more efficient and used less coal per unit of work, total coal consumption didn’t decrease. It increased. Dramatically. More efficient engines made coal-powered applications economically viable in contexts where they previously weren’t. The efficiency gains didn’t reduce demand. They expanded it.
This became known as Jevons Paradox, and it has remained a foundational principle in economics ever since. Modern economists call it the rebound effect, and it has been observed repeatedly across energy markets, transportation systems, and computing resources. When LED bulbs made lighting cheaper, people installed more lights. When fuel efficiency improved, people drove more miles. When data storage became inexpensive, systems stored exponentially more data. The pattern holds across domains and decades.
The principle is straightforward. When you make something more efficient, you don’t necessarily use less of it. You often use more, because the cost decrease makes new applications economically feasible. The efficiency gain expands the frontier of what’s possible rather than consolidating existing use.
Software engineering follows this pattern precisely. Every efficiency gain has expanded what’s economically viable to build. Frameworks that used to require specialists can now be used by generalists. Applications that used to need custom development can be assembled from libraries. Infrastructure that used to need dedicated teams can be managed by developers. Each efficiency gain doesn’t reduce the total amount of software work. It increases it by making more types of software economically feasible.
The Current Moment#
AI-assisted development is the latest efficiency gain in this long line. Large language models can generate code, suggest completions, explain unfamiliar syntax, and help debug problems. These tools make individual developers more productive. They reduce the time spent on certain types of coding tasks.
The pattern suggests what happens next. The efficiency gain won’t reduce the total demand for software engineers. It will expand what’s economically feasible to build. Organizations that couldn’t justify custom software development will be able to. Products that weren’t viable with traditional development timelines will become realistic. The cost decrease will unlock new categories of software, which will require more people to envision, design, build, integrate, maintain, and evolve.
We’ve seen this movie before. When integrated development environments automated syntax checking and made refactoring easier, the result wasn’t fewer developers. When package managers made dependency management trivial, the result wasn’t smaller teams. When containerization made deployment consistent and reproducible, the result wasn’t less infrastructure work. Each time, the efficiency gain expanded the scope of what teams could accomplish, which expanded the scope of what organizations expected them to accomplish.
Why This Time Isn’t Different#
Every major advancement in software tooling has been met with some version of the claim that this time is different. High-level languages were supposed to eliminate the need for most programmers. So were fourth-generation languages, CASE tools, model-driven development, no-code platforms, and a dozen other innovations. Each one made building software dramatically easier. And each time, the number of software engineers in the world went up, not down.
The claim that AI will finally break this pattern is a bet against Jevons Paradox. It’s a bet that this efficiency gain will behave fundamentally differently from every efficiency gain in the past seventy years. That this time, making software easier will consolidate demand rather than expand it.
There’s no evidence for this claim. The entire history of computing suggests the opposite. Every efficiency gain in computation, storage, bandwidth, and developer productivity has expanded consumption rather than reduced it. Jevons was right about coal in 1865. He’s been proven right about every aspect of computing since. There’s no reason to think this time will be different based on historical patterns, economic theory, or the trajectory of the field.
The Discipline’s Youth#
It’s easy to forget how young software engineering is. Depending on where you draw the line, the field has existed for roughly seventy years. It hasn’t yet seen the conclusion of its first century.
Civil engineering has accumulated millennia of knowledge. Electrical engineering has over a century of maturation. Even aerospace engineering had several decades to stabilize before reaching a kind of equilibrium where the number of aerospace engineers stayed relatively constant relative to the overall economy.
Software engineering is still in its rapid growth phase. The tools change every few years. The paradigms shift regularly. The boundaries of what software can do keep expanding. We’re nowhere near equilibrium. We’re in the part of the growth curve where exponential expansion is the norm, where every efficiency gain opens new possibilities rather than consolidating old ones.
AI-assisted development isn’t arriving in a mature, stable field. It’s arriving in a field that’s still growing explosively. The efficiency gains from AI won’t move us from growth to contraction. They’ll accelerate the growth we’re already experiencing.
The Pattern Continues#
Software engineering has spent seventy years making building software easier, and seventy years proving that easier doesn’t mean less. It means more. More software, more ambitious projects, more categories of applications, and more people needed to create and maintain it all.
AI-assisted development fits this pattern exactly. It’s another efficiency gain in a long series of efficiency gains. Each previous one expanded the field. The evidence suggests this one will too. Organizations will build software they couldn’t justify building before. Teams will take on projects they couldn’t have attempted with traditional tooling. New categories of software will become economically feasible.
The people who understand Jevons Paradox aren’t panicking. They recognize that efficiency gains expand frontiers. The history of software engineering is clear. The economic principle is sound. The discipline is young and still growing. And AI is another chapter in an ongoing story, not the final chapter.