The Jevons Paradox of Software Engineering

Why Software Engineering Isn't Going Anywhere

In 1865, Britain had a problem. Steam engines were getting dramatically more efficient: better engineering, less coal per unit of work. The logical conclusion was obvious: coal consumption would fall. Jevons disagreed. He argued that cheaper-to-run engines wouldn't reduce coal use. They would make steam power economical for applications that couldn't justify it before. Factories, railways, pumps, mills, everything that had been on the edge of viability would tip over into it. He was right. Britain burned more coal than ever.

He called it a paradox. It isn't really. It's just what happens when the cost of something drops: you use it for more things.

Software engineering is the resource. AI is the efficiency improvement.

When writing software gets cheaper, in time, in expertise required, in barrier to entry, the number of things that get software goes up. Products that were too expensive to build become viable. Startups that couldn't afford a full engineering team can now prototype. Companies that shelved features for years put them back on the roadmap. In embedded specifically, this effect is enormous: there are billions of devices that are still "dumb," waiting for firmware that was previously too expensive to justify. Every one of those projects still needs someone who understands what the generated code is actually doing, and what happens when it doesn't.

The bottleneck was never the typing. It was the thinking and the creativity.

What AI Is Already Better At

Every profession has two layers. The part that requires genuine judgment, creativity, and context. And the part that is essentially pattern matching executed by hand. For most of history those two layers were inseparable, you had to do both. AI is peeling them apart.

It excels at the second layer: repetitive, well-defined work where the pattern is known, the context is stable, and the output can be verified against a clear standard. In software engineering that layer is bigger than most of us would like to admit.

Most engineers I talk to know this is true. Few say it out loud.

AI is already better than me at several things I used to spend real time on:

• Boilerplate. Initialization sequences, configuration structs, scaffolding, the kind of code where you're transcribing a specification into syntax. I can get a working driver skeleton in 30 seconds. That used to take an hour including the documentation lookup.
• API recall. Framework-specific syntax, library semantics, register definitions. I still verify the output, but I don't open the documentation for the first pass anymore.
• Unit test scaffolding. Given a module interface, generating a test harness is now trivially fast. The tests themselves still need thinking. The structure doesn't.
• First-draft documentation. Comments, README sections, changelog entries. Not great, but good enough to edit rather than write from scratch.

This is a real shift. It's also fine. These were never the interesting parts of the job anyway.

The Skills That Actually Compound

AI can execute. What it can't do is care. It doesn't know which problem is worth solving. It doesn't know when the answer it gave you is plausible but wrong. It doesn't know what failure looks like in your specific system. That gap, between execution and judgment, is where the interesting work lives.

Here's what I've noticed in my own work. The more AI handles the execution layer, the more the job becomes about everything that surrounds the code. The context. The constraints. The judgment calls that don't have a right answer in a documentation page. Those skills don't compress. They compound.

• System-level thinking. AI solves the problem you describe. It doesn't know about the problem you didn't think to describe. The interaction between components. The edge case that only appears under load. The failure that only happens in production. Holding the entire system in your head at once is still a human job.
• Architecture. AI generates code that solves today's problem. Architecture is about solving tomorrow's problems without knowing what they are yet. Which boundaries to draw. Which complexity to hide. Which decision to defer and which to commit to now. That requires experience, taste, and a tolerance for uncertainty that no model has.
• Debugging at depth. This skill is getting rarer and more valuable simultaneously. When AI-generated code works in testing but fails in integration, someone has to go find out why. In embedded that means a logic analyzer and a core dump. In backend systems it means distributed traces and memory profiles. The engineer who can correlate a symptom to a root cause, across layers, across systems, is not becoming less relevant.
• Translating intent into constraints. A requirement is what someone wants. A specification is what a system needs to do to deliver it. The gap between those two things is where most projects fail. AI can help you implement a specification. It cannot write one for you, because writing one requires understanding the domain, the constraints, and the consequences of getting it wrong. That knowledge lives with the engineer, not the model.

What Changes in the Craft

The job isn't disappearing. It's changing shape.

A modern car nowadays can steer, brake, and accelerate itself through most of a journey. That's not an argument for removing the driver, it's an argument for a different kind of driver. One who monitors, intervenes at the right moment, understands what the automation is doing and why, and knows exactly when to take the controls back.

That's what software engineering looks like with AI tooling. The craft doesn't disappear, it moves one layer up the abstraction. Less time writing scaffolding, more time deciding whether the architecture that just got generated is actually correct, safe, and maintainable.

Prompting becomes a real skill. Not in the buzzword sense, but the ability to give a model the right context: the constraints, the failure modes, the reason a standard approach won't work here. The prompt is the new spec.

And knowing what not to delegate matters just as much. AI-generated code that touches critical paths, interrupt handlers, authentication logic, financial calculations, safety-relevant behavior, needs human review before it ships. The cost of getting it wrong isn't a runtime exception. It's a production failure you find out about too late.

What I'd Tell You If You Feel Like You're Falling Behind

The anxiety I hear from engineers usually comes from the wrong question. They're asking whether AI will replace them, when the real question is what's left when it does the easy parts.

If you're early in your career: go deeper on the fundamentals, not shallower. The engineer who understands what's happening beneath the abstraction layer, who has debugged a real concurrency issue, who has read a spec end to end and understood why the edge case matters, that engineer uses AI better than anyone. Not because they resist it, but because they can verify its output.

The dangerous position is the opposite: relying on AI output you can't evaluate. That works until it doesn't, and when it doesn't, the failure is in a place you didn't think to test.

And lazy prompting makes it worse. Vague input gets confident-sounding output. The engineer who doesn't specify constraints, edge cases, and failure modes gets code that looks right and isn't. Garbage in, garbage out didn't go away. It just got better at hiding.

Understand the layer below the one you work in. Write something without the framework. Read the source instead of the docs. These feel like overkill right now. They are not.

The floor is getting lower. The ceiling is getting higher. That's the position worth being in.

Key Takeaways

1. Apply the Jevons Paradox before predicting your field's future: efficiency gains in software production expand total demand, they don't contract it. More projects start when the barrier drops.
2. Audit which parts of your current work are boilerplate and intentionally offload them to AI, then redirect that time toward the skills that don't compress: debugging, architecture, systems thinking.
3. Treat AI output as a first draft, never a final answer. Generated code needs the same review discipline as code from a junior engineer: correct intent, unknown edge cases, untested under real conditions.
4. Invest downward in the stack, not upward. The engineer who understands the layer beneath their abstraction is more valuable in an AI-augmented world, not less.
5. Treat prompting as a technical skill. Giving a model the right constraints, the system context, the failure modes, the non-obvious requirements, is the difference between useful output and plausible-looking garbage.