Jevons Paradox Applied to Software: Easier to Build, More We Want

Andrej Karpathy posted a thread on X on June 9th that Simon Willison captured in his blog with an observation worth more attention than these brief posts typically receive: as software flows freely, demand doesn't stabilize or decrease. The opposite happens.

Karpathy states it plainly: "I feel my own demand for software growing substantially". Visualizers, dashboards, hyper-specific single-use apps for a particular project, test suites multiplied tenfold, auto-optimized code, research projects with custom HTML for results. The list isn't speculative; it describes what he does today.

Jevons Paradox Isn't New, But Its Application to Software Is

Jevons Paradox dates from the nineteenth century: when efficiency in using a resource improves, total consumption of that resource tends to grow, not shrink. It was first formulated for coal and steam engines, and has since resurfaced in nearly every sector where technology makes access to something scarce cheaper.

In software, the scarce resource has always been development time. A bespoke app—custom-built for a single purpose and discarded after—was economically unviable for most projects. Nobody commissioned a personalized dashboard to analyze the results of a single experiment. The opportunity cost was too high.

That cost has now dropped noticeably. And the effect, as Jevons predicts, isn't that developers rest more. It's that they open the door to dozens of tools they would have mentally dismissed before even considering them.

Why This Matters for Those Working with Claude

This has practical implications for teams already using Claude Code or integrating Claude via API. The value of having reusable skills, sub-agents, or automated workflows doesn't lie solely in executing existing tasks faster. It lies in how reduced friction surfaces latent demand that previously went unexpressed.

Put another way: the value isn't only in replacing work already being done, but in enabling work that simply wasn't happening. An expanded test suite, an ad-hoc visualizer for sprint data, a small dashboard to share with a client in a meeting and never open again. Use cases the team would have dismissed at the ideation stage because implementation effort didn't justify it.

That changes how it makes sense to plan a team's technical capacity. It's not just about "doing the same with fewer people". It's that the surface of what's considered feasible expands, and with it the backlog of what gets prioritized.

A Note on the Source

Willison's post cites Karpathy's tweet mentioning "Claude Fable 5". No model by that name exists in Anthropic's public catalog as of today—current models are Claude Opus 4.8, Sonnet 4.6, and Haiku 4.5—so we reproduce the name as it appears in the original source without interpretation or correction. It could be an internal name, an unofficial alias, or simply an error in the original tweet.

What Remains Unresolved

Karpathy speaks from the perspective of someone with deep technical context and judgment to assess what deserves building. Jevons Paradox also has a less comfortable side: more consumption doesn't automatically equal more value. The symmetric risk is the proliferation of disposable software nobody maintains, nobody documents, and that generates invisible technical debt because "it was easy to make anyway".

Karpathy's observation is valid and reflects something we at ElephantPink have been seeing in client projects for months. But it's worth pairing it with a second question: of all that new demand the tap releases, how much becomes sustainable infrastructure and how much becomes accumulated noise?