The Jevons Paradox and the Future of Software Engineering

I recently came across the Jevons Paradox, and it reshaped how I think about where software engineering is heading.

The paradox is simple. When a resource becomes more efficient to use, total consumption of that resource goes up, not down. Coal got more efficient in the 1800s. People did not use less coal. They used vastly more of it because suddenly new applications became viable.

Software is following the same pattern.

The Demand Has Always Been There

Pre AI, everyone wanted software. Automation, tools, apps, anything to make their life easier. But building software was expensive. It took months. Sometimes years for complex systems. Most of that demand stayed suppressed.

Think about who has been left out.

• The restaurant owner who needs inventory management but cannot afford a dev team
• The local clinic still running on paper forms
• The solo lawyer manually drafting repetitive documents and reading through stacks of files
• The small manufacturer tracking production on Excel
• The mom and pop shop with zero ecommerce presence

Every single one of these wants software. They just could not afford it. AI drops the cost floor dramatically, and suddenly millions of latent demand points become active.

Every Wave Unlocked a New Floor

Each wave did not replace demand. It unlocked a new floor of demand that previously could not afford to participate.

The Blue Collar Shift

If demand is elastic, Jevons fully applies. And the shift is not just about fewer jobs. It is about a restructuring of what the job is.

We went through industrialisation before. Some white collar jobs became blue collar jobs. The same thing is happening in software.

Top tier engineers are the ones who solve problems, particularly hard problems. They define what gets built and why.

Mid tier engineers become the executors. High volume, lower pay. They leverage AI to ship fast. This is the blue collar layer of software engineering.

Junior and entry level engineers face the hardest reality. The mid tier, armed with AI, is already as cheap as a junior and can do significantly more.

The paradox does not eliminate software engineering. It reshapes the entire ecosystem.

The Foreman, Not the Bricklayer

The software engineer of the future might look less like a craftsman and more like a construction site foreman. They do not lay bricks. They operate the machines that lay them down, ensure quality, catch structural errors, and translate the client’s vision into execution.

It is less about creating logic from scratch and more about supervising, validating, and directing AI generated code.

The premium shifts from typing code to judgment about what code should do.

But if demand is elastic, the job is still there. Just different. The more uncomfortable question is what happens when AI can eventually identify its own problems to solve, not just execute. Demand might stay elastic but the human role in fulfilling it could shrink.

Right now we are safe because AI still needs us to tell it what to build and what to fix.

What I Have Seen Firsthand

I have been using AI to build one iOS app, one Android app, and three web apps. Some built from scratch with AI, others polished with AI on top of pre AI foundations.

What I can say with confidence is that I still need to be very hands on in terms of code and architecture direction. AI fails to fix complex bugs without human intervention. It handles the easy stuff, but anything with real depth requires me to guide the AI through the problem effectively.

One of the apps I am working on is an accounting system. The work there is heavily about understanding best practices in accounting, single entry versus double entry, reconciliation flows, audit trails. It is no longer about how to write a function. It is about understanding the domain deeply enough to build the right thing.

What to Prepare For

1. Judgment over Syntax

Develop strong product acumen. Learn to ask “should we build this” rather than “how do we build this.” Study business fundamentals. The engineers who understand business context become the foreman, not the labourer. Think of yourself as the business expert.

2. System Thinking

Architecture design. Scalability, fault tolerance, security, tradeoffs. Knowing when AI generated code is structurally wrong even if it looks right. Think less “how do I write this function” and more “how does this perform under high load.”

3. Domain Expertise Combined with Coding

This is likely the biggest opportunity. An engineer who deeply understands a specific industry becomes extremely hard to replace.

• A healthcare engineer who understands clinical workflows
• A fintech engineer who understands regulatory constraints
• A supply chain engineer who understands logistics tradeoffs

4. Prompt Engineering and AI Orchestration

Learn how to specify problems precisely. Vague prompts produce garbage. Understand AI limitations and when not to trust it. Build workflows that chain AI tools together. Evaluate and audit AI generated code like a senior reviewer would.

5. Communication and Translation Skills

Translate business requirements into precise technical specs, with or without AI help. Explain technical constraints to non technical stakeholders. Write clear documentation. AI produces it, but humans need to verify if it is correct. Soft skills become a differentiator in a world where raw coding is cheap.

6. Quality, Testing, and Verification Mindset

When code is cheap and fast, it scales the quantity of bugs and tech debt. Deep expertise in testing strategies matters more than ever. Security auditing of AI generated code. Performance profiling. Load testing. Challenge the AI.

The New Mental Model

Final Thought

The ability to learn and adapt fast is essential. Claude Code, Cursor, and similar tools might exist today but might not in the future. The tools will keep changing. The mindset of judgment, domain depth, and orchestration will not.

Software engineering is not dying. It is splitting into tiers. The question is which tier you are building toward.