--- title: "Why AI will not replace the need for engineers: the Jevons paradox comes to software engineering" date: 2026-04-01T09:18:13.000Z canonical: https://www.ekino.com/publications/why-ai-will-not-replace-the-need-for-engineers-the-jevons-paradox-comes-to-software-engineering/ --- Accountants, physiotherapists and estate agents are now building their own working applications in a matter of days. Those applications answer real needs, but they run on fragile infrastructure, with no GDPR safeguards, no tests and no deployment strategy. **This democratisation of development is going to create a Cambrian explosion of software.** Every profession, every niche will want “its” application. And turning those prototypes into reliable, secure, maintainable systems will require more engineers than ever. ### The Jevons paradox: when efficiency creates demand In 1865, the British economist William Stanley Jevons published “The Coal Question”. His thesis is counter-intuitive: improvements in the efficiency of steam engines, far from reducing coal consumption, made it soar. The mechanism is straightforward: a more efficient engine makes coal more profitable to use, which encourages its adoption in settings where it would never have been considered before, which in the end increases overall demand. **That is the Jevons paradox: when a resource becomes easier to exploit, we do not save it, we consume more of it.** Two modern examples to make it concrete. Motorways first: you widen a lane to ease traffic, but new journeys become “acceptable”, new drivers appear, and congestion returns. Supply has generated its own demand. Digital storage next: in the 1990s, a 1 GB hard drive seemed infinite. Today we juggle terabytes and are still short of space. The cost per gigabyte has plummeted; our consumption has followed exactly the same curve, upwards. **The mechanism is always the same: making something more accessible does not reduce the need, it multiplies it.** ### The physiotherapist who ships an application in a weekend thanks to coding agents Something unprecedented is happening right now, and I see the signs of it every day. **Professionals who have never written a line of code are building working applications around their own trade.** An accountant who automates the reconciliation of expense claims. A physiotherapist who creates a rehabilitation tracking tool for their patients. An estate agent who puts together a bespoke customer relationship tool, tuned to the specifics of their local market. **And the most unsettling part: it works.** Not “it sort of works, for a non-developer”. It genuinely answers their need, sometimes better than an off-the-shelf product, and infinitely better than anything an outside developer could have delivered. The reason is structural: that accountant knows the edge cases of their trade, the ones no specification would ever have captured. They know that a particular client always sends invoices in an absurd format, that a particular VAT calculation has an exception specific to their sector. That domain knowledge is an advantage that a specification, however well drafted, only captures imperfectly. The domain expert does not merely describe their need. They live it, with its exceptions, its shortcuts, its daily irritations that they would not even think of writing down. These applications are real wins. They solve concrete problems, for small audiences, with surgical precision. And they simply did not exist two years ago. ### The garden shed and the apartment block: from prototype to production system Except that the accountant’s application runs on fragile hosting that will fall over at the first load spike. There is no robust error handling, no monitoring, no deployment pipeline, no automated tests, no data migration strategy. Security is naive at best, non-existent at worst. The personal data of the physiotherapist’s patients is probably stored in the clear, without encryption, without GDPR compliance, without any access audit trail. **And that is normal. It is not a criticism, it is an observation from the field.** This is exactly the phenomenon I described in an earlier article on context engineering: AI produces code that works, but it has no awareness of the ecosystem that code has to live in. It does not think in terms of systems. It answers an instruction. Building software that holds up in production, that scales, that survives failures, that protects its users’ data and that stays maintainable over time is a profession. A profession that does not boil down to “writing code that passes the tests on my machine”. **It is the difference between building a shed in your garden and designing an apartment block.** Both are useful. Both answer a real need. But one of the two requires an architect, an engineer, a structure, and planning permission. ### Coal, steam and our lines of code: the Jevons paradox applied to software engineering Here is my conviction, and it has grown stronger month after month watching our teams and our ecosystem: the new accessibility of software development — carried by large language models and generative AI — is not going to replace software engineers. It is going to create a Jevons paradox. Let us take the mechanism again and follow the metaphor through. Jevons’s coal is software. The improved steam engine is generative AI. Today**, the “cost” of producing an application is falling drastically**: a well-formulated instruction, a few iterations with a language model, and you get an application that works. **The barrier to entry is collapsing.** And what happens, according to Jevons, when the cost of exploiting a resource falls? Demand explodes. Every profession, every niche, every specific need that would never have justified a development budget becomes a legitimate candidate for having “its” application. The accountant, but also the craftsperson, the researcher, the teacher, the charity manager… each with their bespoke tools. We are going to witness a Cambrian explosion of software. **This is where the “AI replaces developers” reasoning collapses.** Because that explosion mechanically creates a cascade of engineering needs that nobody is anticipating: - **Interoperability.** Sooner or later, these thousands of new applications will have to talk to each other. Exchanging data reliably between the estate agent’s homemade management tool and their network’s information system is not something an instruction to a model resolves. It has to be designed, with interface contracts, protocols and error-handling strategies. - **Security and compliance.** Every new application handling personal data is a potential attack vector and a matter of regulatory compliance. GDPR, NIS2, DORA depending on the sector — frameworks the accountant does not know and the language model does not spontaneously check. - **Resilience and scaling.** The prototype that works for 10 users and the system that serves 10,000 have nothing in common, neither in architecture nor in operations. When the physiotherapist’s application goes from their own practice to a network of 200 practitioners, someone will have to rethink storage, caching, distribution and monitoring. - **Maintenance over time.** This is perhaps the most underestimated point. The model that generated the application today will produce different code in six months. Dependencies evolve. Third-party interfaces change. Without regression tests, without a continuous integration pipeline, without a version management strategy, these applications are sandcastles facing the tide. - **The debt of legacy systems.** And there is a whole area we forget in this equation: IT departments are full of ageing systems that are still running. COBOL mainframes, software packages last updated a decade ago, obsolete technical foundations held up as much by habit as by necessity. These systems no longer meet security standards, no longer answer current regulatory requirements, and nobody dares touch them for lack of budget or available skills. Yet the democratisation of access to development will free up budgets and ambitions: if producing new software costs less, part of that recovered margin will naturally be redirected towards bringing these software estates up to standard. Rewriting, modernising and securing those foundations is a colossal undertaking that also demands engineers. Who is going to take all that on? Not the accountant. Not the physiotherapist. Not the estate agent. They have done their part — brilliantly — by expressing the business need and building the first draft. **But turning that prototype into a reliable product is the job of software delivery teams**. And not the engineer alone. Because a system that holds up also means a user journey that has been thought through, tested and iterated. And that is the work of the user experience designer. It means accessibility that cannot be improvised. It means visual and functional consistency — the difference between a tool you use once and a product you adopt. The software explosion will multiply the need across the whole chain: engineers, designers, product managers; the entire team that turns an idea into a reliable experience. On the engineering side, this demands thinking about a system holistically: deployment, service orchestration, design patterns as tools for structuring complexity rather than as answers in a technical interview, observability, performance, cost. And, yes, **the ability to steer language models intelligently, knowing exactly when not to trust them.** The easier it is to create software, the more of it we create. The more we create, the more people we need who know how to keep it alive in production. AI makes code accessible to everyone. But it makes software engineering — the real kind, the systems kind — more indispensable than ever. Jevons would have smiled.