Jevons, Claude, and the Expanding Surface Area of Work 👩🏻‍💻

I keep seeing variations of the same nonsense: "designers are hosed because engineers can just use AI to do most of their design" or "engineers are cooked because designers can just use Claude code".    It's both true and false.  

I get where that feeling comes from. The tools really are better now than they were even a year ago. Not incrementally better. Structurally better. You can hand them real context, real codebases, and get back something that is often usable on the first pass.

But I think the conclusion people are drawing from that is off.

There’s an older lens that has been more useful for me in making sense of this. It comes from a 160-year-old economic observation called Jevons Paradox.

The short version is simple: when something becomes more efficient, we don’t end up using less of it. We end up using more.

The original example was coal. As steam engines became more efficient, the expectation was that coal consumption would drop. Instead, it increased. Dramatically. Efficiency made coal more useful, which made it worth using in more places, which expanded total demand.

That pattern shows up everywhere once you start looking for it.

Computing got cheaper, but we didn’t conserve it. We built entire industries on top of it. Storage got cheaper, but we didn’t store less. We started recording everything. Bandwidth improved, and now video is the default medium for the internet.

So when I look at tools like Claude Code, Cursor, and Codex, I don’t see a contraction in demand for engineers. I see an expansion in what is practical to build.

And that changes the shape of the work.

What I’ve noticed recently is that the bottleneck is already shifting. It’s less about whether code can be written and more about whether the right thing is being built, whether the system boundaries make sense, and whether the iteration loop is tight enough to actually explore the space.

The tool removes friction from implementation. It does not remove the need for direction.

In fact, it kind of amplifies it.

Because when the cost of trying something drops, you try more things. And when you try more things, you generate more surface area. More decisions. More edge cases. More integration points. More things that need to be understood, not just executed.

This is the part that doesn’t show up in the “engineers are cooked” framing.

The work doesn’t disappear. It spreads.

It moves outward into problem selection, system design, constraint definition, and evaluation. The implementation layer becomes more fluid, but the system still needs shape.

And someone has to be responsible for that shape.

Might as well be me.