In the Future, You'll Need More Engineers, Not Fewer.
Three times in the last month, a CEO has told me some version of the same thing on the podcast: “We adopted Copilot across the engineering team. Output is up 40%. So we are looking at whether we can reduce headcount.”
Every time, my response is the same. You are looking at the wrong metric. Output is up, yes. But what happened to your backlog? It did not shrink. It grew. What happened to your integration complexity? It expanded. What happened to the number of systems your team is now responsible for maintaining? It doubled.
They are describing a pattern that we have seen at Sonatafy and which economist William Stanley Jevons identified in 1865, and it is about to reshape how every technology leader thinks about AI, engineering teams, and software delivery.
A 160 Year Old Prediction About Your Engineering Org
Jevons studied coal. In the mid 1800s, Britain was making steam engines dramatically more efficient. The assumption was that better efficiency would reduce coal consumption. Use less coal per unit of work, use less coal overall. Simple.
Jevons argued the opposite. When coal became more efficient to use, it became cheaper per unit of output. When it became cheaper, industries found new uses for it. Factories that could not have justified the cost suddenly could. Applications that did not exist were invented. Total coal consumption did not decline. It exploded. Efficiency did not reduce demand. It unlocked it.
That is exactly what is happening with code in 2026.
AI tools have made it dramatically cheaper to produce software. GitHub Copilot, Claude, GPT, and a growing ecosystem of coding assistants generate boilerplate, write tests, refactor legacy functions, scaffold entire services, and suggest architectural patterns. What used to take a senior engineer a day now takes an afternoon. What used to require a team of three can often be prototyped by one.
The linear conclusion is that companies will need fewer engineers. The Jevons conclusion is that they will need more, because the volume of software being built, deployed, and maintained is about to expand faster than anyone’s headcount plan accounts for.
The Backlog Illusion at Scale
Here is where the pattern becomes visible if you know what to look for.
When the cost of producing software falls, projects that were once too expensive suddenly make sense. Internal tools that lived on a wish list move into active development. Small firms that relied entirely on SaaS subscriptions start commissioning custom integrations. Mid sized enterprises invest in bespoke analytics dashboards they never would have approved two years ago. Local governments experiment with AI driven tools to manage data and services. The barrier to custom software collapses, and with it, the ceiling on demand.
I call this the Backlog Illusion operating at the organizational level. Your engineering team is closing tickets faster than ever. The velocity charts look excellent. But the total surface area of software your company is responsible for is expanding faster than your team’s capacity to secure it, maintain it, govern it, and evolve it. The backlog is not shrinking. It is shapeshifting. What used to be a queue of features is becoming a permanent, expanding obligation of enhancements, compliance updates, integration maintenance, and architectural refactoring.
After 180+ conversations with CTOs on the podcast, I can tell you this is not theoretical. Every engineering leader I talk to is experiencing the same dynamic. They shipped more this quarter than last. And they are more behind than they have ever been. That is the Jevons Paradox in action.
More Code, More Coordination Tax
There is a second order effect that most CEOs miss entirely.
When your team produces more software, you do not just produce more code. You produce more systems. More services. More APIs. More data pipelines. More internal dashboards. More automated workflows. Individually, each one feels manageable. Collectively, they form a sprawling digital nervous system that grows more intricate every quarter.
That complexity carries a cost I call the Coordination Tax. Every new system your team builds creates dependencies. Every dependency creates coordination overhead. Every layer of coordination requires communication, alignment, testing, and handoffs that consume engineering time without producing features. Research consistently shows that each engineer added to a misaligned model increases overhead 15 to 25% while increasing output only 5 to 10%. AI accelerates the input side of that equation (more code, more systems, more surface area) without addressing the coordination side.
The result is that teams feel faster at the individual level and slower at the system level. An engineer can generate a microservice in an afternoon. But integrating that microservice into the existing architecture, securing it, testing it against edge cases, documenting it, and ensuring it does not introduce a regression somewhere else still requires judgment, context, and coordination that AI does not provide.
What Actually Becomes Valuable
This is the part that matters for anyone making hiring, team structure, or investment decisions right now.
Routine syntax level coding is increasingly automated. That is real and it is not reversing. But that does not mean engineers become obsolete. It means their comparative advantage shifts. The most valuable engineers in 2026 are not the fastest code producers. They are the ones who can design resilient distributed systems, evaluate AI generated output for hidden flaws, anticipate scaling bottlenecks before they become production incidents, and govern complex ecosystems without creating bureaucratic drag.
Judgment replaces repetition as the core differentiator. And judgment is the one thing that does not scale through automation.
For business leaders, this carries a specific strategic implication. Treating AI purely as a cost cutting mechanism is a misread of the cycle. Individual productivity gains do not automatically translate into reduced aggregate demand. Efficiency lowers the marginal cost of innovation. When innovation becomes cheaper, organizations attempt more of it. They automate more workflows, deploy more microservices, integrate more data streams, and embed AI into more operational layers. Each initiative increases reliance on software as critical infrastructure. And each one increases the Coordination Tax.
The Constraint That Actually Matters
The real constraint in 2026 is not the ability to generate code. It is the capacity to manage complexity safely and sustainably. Governance frameworks, cybersecurity oversight, architectural discipline, and long term maintainability become the bottleneck. Companies that expand their software footprint without strengthening their systems thinking will experience fragility. Those that anticipate the paradox and invest in architectural rigor will convert efficiency gains into durable advantage.
This is the decision that our team at Sonatafy keeps seeing technology leaders face. You can use AI to produce more software faster. That is the easy part. The hard part is building the delivery system, the ownership model, the review discipline, and the coordination framework that ensures all of that software actually serves the business instead of slowly becoming a liability.
Jevons saw this pattern in coal powered Britain. Efficiency did not reduce consumption. It expanded it into industries and applications that did not previously exist. AI driven coding efficiency is doing the same thing to software. As code becomes cheaper to create, it becomes embedded in more processes, more industries, and more decisions.
The result is not less code. It is more pervasive code. And the companies that understand the difference between producing more software and delivering more value will be the ones that come out ahead.
Steve Taplin is the CEO of Sonatafy Technology, host of the Software Leaders Uncensored podcast (180+ episodes), and author of Fail Hard, Win Big. He writes about the decisions technology leaders actually face at thetechdilemma.com.





Great article.