We will need more software engineers. Not fewer.
That sounds wrong in 2026, with layoff headlines arriving every week and every other commentator telling developers to retrain. But the contrarian position has more than a hundred and fifty years of economic precedent behind it.
When Eli Whitney's cotton gin was introduced in 1793, it made cotton processing roughly fifty times more efficient. Logic — and the prevailing fear of the time — said it would put cotton workers out of work. The opposite happened. By removing one massive bottleneck in the supply chain, the cotton gin triggered an explosion in demand for the raw material. Cotton output in the United States grew from roughly three thousand bales a year in 1790 to over four million bales by 1860, a multiplier north of one thousand times. The shape of an entire industry changed.
This pattern has a name. The economist William Stanley Jevons described it in 1865 in The Coal Question, observing that when technology made coal-fired engines more efficient, total coal consumption rose rather than fell. People did more things, more often, with the cheaper resource. The pattern has been replicated again and again across industries — energy, transport, manufacturing, communications.
If the Jevons Paradox holds for software, the implications for AI are striking. If AI reduces the cost and time of writing code, demand for software should explode, driving a hiring boom for engineers to harvest the new opportunities. Logically, that should already be happening.
It is not. At least, not visibly. So either the Jevons Paradox does not apply to software — or there is a time lag, and we are inside it. The argument that follows is that we are inside the lag, and that the businesses paying attention now will be the ones who move first when it ends.
The cotton gin story is worth pausing on, because it is the cleanest version of the pattern. Before Eli Whitney's invention in 1793, cleaning short-staple cotton by hand was so labour-intensive that it acted as a hard ceiling on how much cotton the South could process. Once that bottleneck was removed, the constraint moved upstream to harvesting — which scaled badly with technology of the time, requiring more land and more labour. Cotton production in the United States grew from roughly three thousand bales a year in 1790 to over four million bales by 1860.
The pattern is general. Every time a technology dramatically reduces the cost or effort of one step in a value chain, the constraint moves to the next step. That next step often requires more of some other resource, not less.
This is the lens through which to think about AI in software. The cost of writing code is genuinely dropping — not by a small margin, but by an order of magnitude in some categories of work. So where does the constraint move next?
The key question: Not "will AI replace software engineers?" but "where does the bottleneck move when typing code stops being one?"
If the Jevons Paradox is going to play out, we should expect to see businesses queue up to commission new software products, demand for engineers rise, and entire new categories of applications emerge. None of that is visibly happening at the scale the theory predicts. There are three reasons, and they each say something different about the timing.
The AI boom arrived at exactly the wrong moment for capital allocation. For more than a decade leading up to 2022, the technology sector operated with effectively free capital. Interest rates were near zero, venture capital was cheap, and large companies could place massive speculative bets on products that might not yield returns for years.
Then central banks raised rates aggressively to tame inflation, and the cost of capital changed overnight. Boards stopped asking "what could this become?" and started asking "when does this pay back?" Speculative software bets became unattractive. Layoffs followed.
We might now have a more efficient way to process the cotton, but the banks have stopped handing out cheap loans to buy new fields. The Jevons response — invest in expanding capacity to exploit the cheaper resource — requires capital that, for the moment, is expensive.
This is a temporary condition, not a permanent one. When rates normalise — and they will — the constraint shifts back to opportunity rather than affordability of debt. The investment thesis for new software returns.
Picking cotton scales linearly. You add ten labourers and you harvest, in rough terms, ten times more cotton. Software engineering does not work that way, and never has. Fred Brooks's The Mythical Man-Month, published in 1975, captured this in what is now called Brooks's Law: adding people to a late software project makes it later. Communication overhead, onboarding cost, and architectural coordination grow non-linearly with team size.
AI is excellent at removing one specific bottleneck — the typing of boilerplate code. It is much less effective at the bottlenecks that actually constrain mid-market software delivery:
Designing robust, scalable system architecture. AI can sketch a plausible architecture diagram, but it cannot stand in a discovery workshop and challenge a finance director on whether they really need a new ledger, or just clearer reporting from the one they have. That conversation determines the shape of the system, and it is not a code-generation problem.
Executing complex integrations. Most real-world systems live in messy environments — legacy ERP modules, half-documented APIs, pre-cloud middleware, regulatory constraints, security boundaries. Getting them to talk to modern cloud platforms reliably is a discipline that requires deep familiarity with both ends and the politics of who owns what data.
Translating ambiguous business needs into precise technical parameters. Most senior engineers' value sits here: turning a vague request like "we need better visibility into our supply chain" into a sequence of decisions about which data, in which format, displayed to which user, on which cadence, with which permissions. AI can help draft the artefacts, but it cannot replace the judgement.
You cannot solve these bottlenecks by hiring armies of junior developers and pointing them at AI tools. The constraint is not headcount. It is the alignment between business intent and technical reality.
The shift: The bottleneck used to be how fast we could write code. Now it is how clearly we can decide what to build and how cleanly it integrates with what already exists.
Cotton is fungible. A bale from Mississippi sells for the same price as a bale of equivalent grade from Georgia. You can produce more, ship it to any textile mill, and it gets used.
Code is not like that. We do not have a market deficit of raw code — we have a deficit of profitable solutions to specific problems. A million lines of generated code that does not solve a monetisable business need are entirely useless. Worse, they are a liability: more code means more bugs, more attack surface, more maintenance cost.
This is why the early adopters of AI in software have mostly used it to do more with less rather than to expand into new markets. Existing teams are absorbing the productivity gain. Headcount is flat or down. New software categories — the equivalent of an entirely new use for cotton — are still mostly in the venture-funded experimentation stage rather than at scale.
For the Jevons effect to fully kick in, two things need to happen. First, the cost of capital has to make speculative new categories investable again. Second, businesses need to identify new categories of profitable software that AI makes economically possible — software that simply could not have been built at acceptable cost before.
If you run a mid-market business — somewhere between fifty and a thousand staff — the macro debate about AI and engineering jobs can feel abstract. It is not. The argument has three concrete implications for your technology decisions in the next twelve months.
Most AI value cases are framed as cost savings: "AI handles the work three full-time analysts used to do." That framing limits your ambition to the size of the team you are replacing. The bigger value, almost always, sits in what AI lets you do that you could not do before — new reporting cadences, new customer touchpoints, new operational signals. Frame your AI roadmap around expansion, not subtraction.
If you are competing for talent, the engineers you most need now are not the fastest typists. They are the people with deep enough code fluency to direct AI rather than be directed by it — to read its output critically, catch its mistakes, design what it cannot, and integrate it into systems it cannot reason about. Solution architects, senior developers, integration specialists who have seen messy environments before. AI tools amplify their output dramatically. They are also the hardest hires to make.
When the next wave of demand arrives — and it will, when capital markets stabilise — the businesses that move fastest will be the ones whose data is already in shape and whose systems already speak modern protocols. If your finance, operations, and customer data still live in a tangle of spreadsheets and disconnected legacy systems, no amount of AI will get you out in front of competitors who solved the foundation problem two years ago. Modern ERP, clean integration, governed data — these are the prerequisites for participating in the boom, not the boom itself.
This is the practical implication of the architecture-bottleneck argument. The future belongs to businesses whose technology platform is ready for things that have not been invented yet. That platform is not built by AI. It is built by people who understand the business, the systems, and the ten-year path between them.
The Jevons Paradox is not failing to apply to AI in software. It is on a time lag, set by the cost of capital, the location of the real bottlenecks, and the absence — for now — of fully formed new product categories that did not exist before.
When capital markets stabilise, when AI tools mature past code generation into integration and architecture support, and when entrepreneurs identify the new categories of software that AI makes economically possible, the expansion will come. We will absolutely need engineers to build these vast new systems, but the nature of the work will look very different from the last decade.
Knowing how to code well isn't a depreciating skill. It's the one that decides who commands AI — and who gets commanded by it. Mid-market businesses that hire and retain engineers with deep code fluency now, and that put their data and systems foundation in order, will be the ones who can move when the wave breaks.
I'm early. But I'm not wrong.
If you are weighing how AI changes your roadmap — what to build, what to buy, who to hire — book a discovery call. We help UK mid-market businesses turn ambiguous AI strategy into specific, fundable next steps.
Or call us directly: 01625 569 777
