You Cannot Outsource Understanding

Don’t try to eliminate developers; don't sell that as the promise of AI; design platforms and practices that amplify their understanding

Oct 17, 2025

(This entry in the Enchiridion follows on from the short story, “The Mirror Factory”)

Every few years, business leaders rediscover a familiar fantasy: that they can have the benefits of software without the inconvenience of developers.

It doesn’t work. It is often disastrous to the company and individuals. It fundamentally misunderstands what a developer does.

The War That Never Ends

In every generation of business leadership, there’s a moment of revelation: “We depend too much on developers.”

It starts as a murmur in the boardroom, hardens into a cost-optimisation initiative, and eventually mutates into a strategic delusion: “This time, we’ll reduce our need for them.”

In the 1990s, it was outsourcing — ship it offshore, let others deal with the messy parts. Developers were expensive, demanding, and always seemed to have opinions about “quality” and “architecture.” Somewhere, surely, there was a cheaper, quieter army of coders ready to build what the business needed.

But it turned out that while you can offshore labor, you can’t offshore context. The business learned, painfully, that the map is not the territory. Requirements rot faster than they can be written, and empathy doesn’t scale through contracts. So they brought the developers back.

Then came the no-code revolution. The dream was elegant this time — let anyone build software. Democratise it. Remove the gatekeepers. What could go wrong?

The answer: everything that depends on understanding.

Soon, “citizen developers” were neck-deep in unmaintainable automations, and developers were called back in, again, to clean up the mess. Every shortcut to eliminate them made the dependency deeper.

Now, with AI, the dream has taken on an almost religious fervour. “The machine will code for us.” Chatbots, copilots, and code gen systems promise infinite velocity. But every line of AI-generated code is another line that someone must understand, test, integrate, and operate. Jevons’ Paradox strikes again: the more efficient the coding becomes, the more code we produce — and the more developers we need to make sense of it all. An illusion of independence always collapses back into the gravity of dependency.

At the heart of this toxic cycle lies a discomfort with complexity. Businesses crave predictability — timelines, budgets, deliverables. Developers, meanwhile, live in a world of emergence — systems that evolve, adapt, and occasionally rebel against control1. When these worlds collide, resentment brews. Each new technological shift becomes a chance to believe, once more, that this time the developers won’t be necessary.

But software is not a department. It is not a service line. It is the medium of modern business itself. Trying to remove developers from it is like trying to remove oxygen from air because breathing costs too much. You can automate syntax, not semantics. You can accelerate creation, but not comprehension.

You can reorganise the people, but you still need the people because the problem is not one of production, but understanding and problem solving.

“the application of an empirical, scientific approach to finding efficient, economic solutions to practical problems in software” — Dave Farley

The truth is as old as craftsmanship: if you want to build something that lasts, you need people who understand the material. The healthy company stops trying to eliminate its dependency on developers and instead learns to share understanding with them — through good design, clear interfaces, and genuine collaboration.

The war ends when both sides realise they are fighting on the same side.

Don’t Outsource Understanding

Don’t try to eliminate developers; design platforms and practices that amplify their understanding — because that’s the one thing the machine still can’t do for you.

Business leaders crave predictability and control. Developers live amid uncertainty and complexity. Attempts to reduce that tension by removing developers always backfire. The dependency on developers’s skills is not a flaw — it’s a reflection of how learning happens in a changing environment.

Some Practices

Build shared understanding loops pairing developers with domain experts.
Focus on context ownership, not cost optimization.
Use AI as an accelerator of comprehension, not a replacement for it.
Make platform teams responsible for enabling understanding, not just delivering tooling.

Some things to avoid

Mistaking efficiency for understanding.
Viewing developers as interchangeable labor.
Believing abstraction eliminates complexity — it only hides it.
Treating software as a cost, not a capability.

A helpful checklist

Do developers and business teams share language, goals, and context?
Can your platform explain itself — through documentation, observability, and self service?
Are tools used to read and explore as much as to write code?
Do leadership metrics reward learning velocity, not just delivery speed?

Software systems are mirrors of their makers. Each time you try to remove the makers, you only obscure the reflection — until something breaks. AI, outsourcing, and no-code can amplify productivity, but none can replace comprehension. Understanding is the rarest and most valuable commodity in software engineering, and it cannot be automated.

The endless cycle of outsourcing, abstraction, and automation stems from a misunderstanding: software development isn’t a service dependency — it’s the core act of learning and adapting in digital business.

Don’t try to eliminate developers; design platforms and practices that amplify their understanding and impact — because that’s the business and technical advantage they bring, and that edge is only going to be more important to your success in the future.

A Software Enchiridion

Discussion about this post