Jevons' Paradox Comes for Software

A few weeks ago I wrote about the changing calculus of software stewardship: a Rails upgrade that would have taken 100 hours got done in about 10, working alongside an AI coding agent. What stuck with me afterward wasn’t the tool. It was the conclusion I landed on at the end, that when building gets this much cheaper, it changes the answer to the question of which work is worth doing at all.

That post was about one app. I’ve been thinking since about what happens when the same change applies to all of them at once, because there’s an economic story here that I find genuinely surprising.

Start with the worry. If the cost of building and maintaining software is dropping by an order of magnitude, the natural assumption is that we’ll need less of it, with fewer developers and fewer projects, since each one now takes so much less effort to deliver. I think that assumption is mistaken, and there’s a well-documented reason why.

What William Jevons noticed about coal

In 1865, the economist William Stanley Jevons was studying coal. Steam engines were getting much more efficient, wringing more work out of every ton burned, and most people assumed that meant England would burn through less coal over time. Why would you need as much of it once each engine got by on less?

Jevons found that the opposite happened. As engines got more efficient, coal became cheaper to put to work, and so people found far more things to do with it. Total consumption climbed. When a resource gets cheaper to use, we tend to discover a great many new uses for it, and those new uses more than swallow the savings.

We call this Jevons’ Paradox now, and the pattern has repeated many times since. More fuel-efficient cars encouraged more driving, so gasoline demand kept rising. Cheaper electric light led us to illuminate far more of the world, for far more hours of the day, than we ever did when light was dear. Cheap computing led us to put a computer in our phones, and then into nearly every other object we own.

Software looks like the next chapter.

The thing we were rationing was developer time

For the entire history of the industry, the binding constraint on software has been the cost of building it. Skilled developer time is expensive and scarce, so every organization keeps a long list of software it would like to have and will never get around to building.

Think about what tends to be on that list. There’s the internal tool that would save the ops team ten hours a week but never justified a quarter of engineering effort. There’s the integration between two systems that everyone agreed would be nice and nobody could cost-justify. And somewhere on there is the rough little app a small-business owner sketched out for their own workflow and never had the budget to commission.

Every company has a list like this, and most of what’s on it has been economically irrational to build. The demand was real the whole time. It just sat below the price line, where nobody could afford to act on it.

Lower the cost of building, and a good share of that backlog crosses over into worth-doing. Work that used to get priced out becomes ordinary work. Demand that had been held back by cost gets released.

The same shift, multiplied

This is where the stewardship piece and this one meet. Taking that upgrade from 100 hours to 10 saved a single aging app, but the more important effect was on the math itself, because it lowered the bar for what’s worth starting. The arithmetic that rescued one legacy Rails app applies just as well to the whole backlog sitting behind it.

The internal tool that now pencils out in weeks instead of months gets greenlit. The shelved integration earns a second look. The small-business owner who could never justify paying someone to build their workflow can describe it and get something usable back. Now multiply that across everyone who has been sitting on a list like that: developers, founders, operations leads, and the domain experts who know exactly what they need and have never been able to afford it.

Individually these are small decisions. Added together they move the whole economy of software. More projects get attempted because more of them are now affordable to attempt, and a fair number of those ship. Each thing that ships tends to expose the next problem it didn’t quite solve, which becomes the reason to build again. The appetite feeds itself. It’s the coal story playing out through a different resource: cheaper to produce, so we produce far more, so total demand grows.

So the market for software grows rather than contracts, and it grows for the same reason it used to stay small. The cost of skilled building, which once capped the whole thing, has fallen through the floor.

Where the work actually goes

I don’t read cheaper building as less work for the people who build software. I read it as far more software in the world, with the genuinely hard human work shifting to a different place. That shift is the part I’d want any team to see clearly.

Once building is cheap, building is no longer the constraint. The constraint moves downstream, to the things that decide whether a piece of software is any good a few years on. Someone still has to judge what’s worth building. The agent’s output still needs a skeptical review, the way that Rails upgrade needed a person to tell the real blockers apart from the agent’s overcautious suggestions. And all this new software still has to be kept secure and maintainable, so that the year-five version of it is still standing instead of collapsed into a pile of plausible-looking code that nobody on the team understands.

Jevons’ world ended up with far more engines, not fewer, and that meant far more demand for the people who could build them and keep them running. I expect the same here. A world awash in cheaply built software is a world that needs more judgment applied to that software, not less. As the volume rises, the value of doing it well rises with it.

That’s the thread running through most of what we write about here. The cost of building well has dropped, which is good news. It also means far more software that someone will have to keep alive for years. The new leverage is what makes all these projects possible; making sure they end up somewhere worth being is still human work, and there’s about to be a lot more of it to do.

One last thought I keep turning over. Software is close to the ideal case for this argument, because the backlog of things we’d build if only they were cheaper is so large and so visible. Plenty of other kinds of work don’t have that pent-up demand waiting behind them, and I suspect that’s where most predictions about what AI will do to every job go wrong, the hopeful ones and the gloomy ones alike. That’s a post for another day.

If you’re looking at your own backlog of software you could finally afford to build, and wondering how to do it without drowning in next year’s maintenance, we’d love to talk.