By this point, most of us in software have come round to the idea that AI is useful, actually. Maybe you’re fully bought into agentic YOLO-mode, perhaps you hold a firmer hand on the tiller and treat it as a weirdly well-read but lacking-in-common-sense intern that needs careful supervision. But either way, it’s making some types of dev work quicker, sometimes a lot quicker. Great! We can get through building that feature way faster, and focus on the rest of the good stuff: testing, talking to users, and better learning what we should be building.

The Jevons Paradox has done the rounds in recent years to explain and predict demand for AI. The economist William Stanley Jevons introduced it in 1865—as technology improved and less coal was needed to do the same work, you might expect demand for coal to decrease. However, as those costs decreased, demand actually skyrocketed—steam engines became viable to use in more industries, and the profit you could make from burning a lump of coal increased. Swap out coal for tokens and it’s easy to see the parallels (right down to the environmental impact)!

This gets talked about at the level of the global economy, but it applies at a company level, or even down to how a team spends its time. If the value you can deliver from an hour of coding increases, why wouldn’t you spend more of your time doing it? The most enthusiastic vibe-coders are arguably spending more time in front of the computer than ever before, and teams can easily slip into turning on an uncontrolled firehose of code. Features are added at pace, and no-one wants to slow it down.

Agile, the thing the industry has spent the last quarter of a century(!) preaching, is all about iteration, customer collaboration, and responding to change. The more you’re shipping without really validating, the looser those feedback cycles get, the less confidence you can have in the value a given bit of work is delivering. The speed you’ve gained is an illusion, as you head ever faster in not quite the right direction.

The answer is to fight the paradox, or at least to think about it a level deeper. Spend more time on the scoping, designing and user testing rather than less, so that we can fully realise the benefit of those dev gains. Go broader in exploring, for example with ever-cheaper throwaway code for A/B testing, rather than deeper down uncharted paths. Spend more time answering the question of what you should build, rather than rushing to build more of it. Software engineering is an industry with a short memory, but some lessons are worth holding onto.