In 1943, from a Nazi prison cell, Dietrich Bonhoeffer wrote something that cuts through to the heart of why organisations fail at change:

"In conversation with him, one virtually feels that one is dealing not at all with a person, but with slogans, catchwords and the like that have taken possession of him. He is under a spell, blinded, misused, and abused in his very being."

He wasn't writing about enterprise software development. He was writing about stupidity — not as an intellectual defect, but as a sociological phenomenon. A moral failure where people surrender their independent judgment to the systems around them.

Sound familiar?

Every developer who's sat in a sprint planning meeting, watching the ritual unfold while nothing actually improves, knows this feeling. You're not talking to people anymore. You're talking to a process.

And here's the devastating part of Bonhoeffer's insight:

"Only an act of liberation, not instruction, can overcome stupidity."

You cannot teach your way out of this. You cannot present another framework, another methodology, another transformation programme. The person — or the organisation — must first be freed from the system that has possessed them.

The CIA Knew This in 1944

The same year Bonhoeffer was writing from prison, the Office of Strategic Services (the CIA's predecessor) published the Simple Sabotage Field Manual. It was meant to help citizens in occupied territories undermine enemy organisations.

The tactics for sabotaging organisations through "purposeful stupidity" read like a checklist of enterprise software development:

  1. Insist on doing everything through "channels." Never permit short-cuts to be taken in order to expedite decisions.
  2. Make "speeches." Talk as frequently as possible and at great length.
  3. When possible, refer all matters to committees, for "further study and consideration." Attempt to make the committees as large as possible — never less than five.
  4. Bring up irrelevant issues as frequently as possible.
  5. Haggle over precise wordings of communications, minutes, resolutions.
  6. Refer back to matters decided upon at the last meeting and attempt to reopen the question of the advisability of that decision.

This was written as sabotage. We adopted it as best practice.

Agile Was Supposed to Be the Liberation

The Agile Manifesto put "Individuals and interactions over processes and tools" first. Not because it sounded nice, but because the signatories had lived through the alternative. They understood that people create value, not processes.

Agile was meant to be the act of liberation — freeing developers from the waterfall documentation hell, from the eighteen-month requirements phases, from the illusion that you could plan your way to working software.

And then corporations got hold of it.

What happened next has been called "Cargo Cult Agile" — a term that cuts to the heart of the problem. The original cargo cults emerged in the South Pacific during World War II. Indigenous peoples watched American planes land on airstrips and deliver valuable supplies. After the war ended, some communities built replica airstrips from bamboo, carved coconut headphones for "controllers," and waited for the planes to return.

They had perfectly replicated the rituals without understanding the mechanism.

This is enterprise Agile in 2025. Teams perform their daily stand-ups, hold their retros, and religiously follow their two-week sprints, whether they work or not. Project managers become "Scrum Masters" by leadership fiat. Business analysts become "Product Owners." The waterfall phases get swept under the rug but really just renamed "dev sprint 1" and "dev sprint 2" and "SIT sprint 1."

The result? An "Agile Industrial Complex" of consultants and certification bodies selling liberation as a purchasable product. But you cannot buy liberation. You can only enact it.

Bonhoeffer again: "In most cases a genuine internal liberation becomes possible only when external liberation has preceded it."

The external liberation hasn't happened. The organisations are still the same. So the internal change cannot follow.

Digital Transformation: The Evidence of Failure

The numbers are damning.

70% of digital transformations fail (BCG/McKinsey). 88% miss their original ambitions (Bain 2024). Of $1.3 trillion invested annually, an estimated $900 billion is wasted.

And here's the critical insight from McKinsey: "Culture, more than technology, is the biggest obstacle to digital transformation." Organisations that invest in cultural change see 5.3x higher success rates than those focused only on technology.

They're not failing because they picked the wrong cloud provider. They're failing because they're trying to bolt new technology onto unreformed organisations. They're reciting new catchwords while remaining possessed by the old systems.

This is precisely what Bonhoeffer warned: instruction cannot overcome the problem. A new PowerPoint deck on "digital-first thinking" doesn't liberate anyone. It just adds another layer of slogans.

AI Slop Isn't New — We've Been Producing Slop for Decades

The current panic about "AI slop" — low-quality AI-generated code flooding codebases — misses a fundamental point: we've been producing slop for decades through entirely human means.

Poor requirements. Unrealistic deadlines. Not focusing on solving the actual problem at hand. Developers under pressure shipping whatever works, documentation be damned. Management that doesn't understand software maintenance isn't free, that every feature adds surface area, that every dependency needs updating.

The AI didn't create this. The AI inherited it.

When developers complain about AI-generated code lacking "structure, documentation, and clarity necessary for long-term maintenance," I have to ask: how much of your existing codebase meets that standard? How much of what humans wrote under deadline pressure and changing requirements and unclear specifications would pass that test?

The real question isn't whether AI produces perfect code. The real question is whether experienced architects can shepherd AI agents toward reasonable solutions faster than they could write it themselves. And increasingly, the answer is yes.

Fred George and the Philosophy of Disposable Services

Back in 2012, Fred George — one of the co-inventors of the microservices architecture — was already articulating a different philosophy of software. His slides from that era contain a radical observation: "Services became disposable."

Martin Fowler's seminal article on microservices (which cites George's work) puts it this way:

"The key property of a component is the notion of independent replacement and upgradeability — which implies we look for points where we can imagine rewriting a component without affecting its collaborators. Indeed many microservice groups take this further by explicitly expecting many services to be scrapped rather than evolved in the longer term."

This was heresy at the time. The conventional wisdom was to build for the ages. Design patterns. SOLID principles. Architecture that would last.

George went further. His microservices were less than 100 lines of executable code. Usually less than 20. Small enough that any single developer could design, implement, deploy, and maintain them. Small enough to throw away and rewrite when requirements changed.

The philosophy was simple: engineer for what you need to solve right now. Better languages, better libraries, better tools will likely be available in the future. Your job isn't to predict that future and build for it. Your job is to solve today's problem in a way that tomorrow's solution can replace.

The Changing Economics of Technical Debt

Here's where it gets interesting.

The term "technical debt" was coined by Ward Cunningham — one of the Agile Manifesto signatories — as a metaphor to explain the value of refactoring to business colleagues. Like financial debt, you borrow time now (by cutting corners) and pay it back later (by refactoring), with interest (the accumulated friction of working with suboptimal code).

But the metaphor has been corrupted beyond recognition. It's become a weapon for blame rather than a tool for understanding.

Some are now arguing that technical debt itself is a myth — or at least a misleading framing. Quentin Adam, CEO of Clever Cloud, puts it provocatively:

"The accounting approach to depreciation over X number of years is completely inadequate when it comes to talking about code. Throwing out code that is no longer needed, because it was written at a certain moment to respond to a certain need, and taking the time to rewrite it because it's no longer responding to that need, is a good investment."

What if the real value isn't in the code at all, but in the team? In their understanding of the domain, their knowledge of what doesn't work, their ability to rebuild faster and better?

Adam has seen this at Clever Cloud: systems that were "technical debt" one year get rewritten in two days by the same team that took eight months the first time. The first attempt wasn't wasted — it was learning. The team now knows more than they did. The second system is better because of the first one's failure.

If technical debt is like financial debt, then the interest rate matters. And AI is about to dramatically change that interest rate.

When rewrite costs drop — when an experienced architect with AI agents can rebuild a service in hours rather than weeks — the calculus shifts. Carrying "debt" matters less when you can pay it off cheaply. The economics of "build it right the first time" start to look like premature optimisation.

The Evidence: Solo Founders Building Real Businesses

The proof is emerging in the market. According to Carta, the share of startups with solo founders and no VC cash has climbed from 22.2% in 2015 to 38% in 2024. These aren't hobby projects — they're real businesses.

Consider:

These aren't exceptions anymore. They're the new pattern.

The critical insight from practitioners: AI coding tools work brilliantly for experienced developers because they can guide the AI and spot its mistakes. Pattern recognition is the key differentiator. When you've written thousands of lines and debugged countless production issues, you know what good code looks like — even when an AI is generating it.

The inverse is also true. Junior developers struggle with AI tools precisely because they lack the experience to recognise problems. As one analyst put it: "The most effective AI users are those who could solve the problems manually but use AI to work faster. The least effective users are those who rely on AI because they don't know how to solve the problems themselves."

This creates an interesting paradox: AI amplifies experience rather than replacing it. The senior architect who understands system design, security patterns, and domain constraints can direct AI toward sound solutions. The vibe-coder who accepts whatever the AI suggests ends up with exposed API keys and architectural time bombs.

The Liberation

So where does this leave us?

The constrained thinking that Bonhoeffer identified — the surrendering of judgment to slogans and catchwords — hasn't been addressed by digital transformations. It's been reinforced by them. Another framework, another methodology, another instruction manual.

But instruction cannot overcome stupidity. Only liberation can.

For software organisations, that liberation might look like:

The organisations that will thrive aren't the ones that successfully "transform" their existing structures. They're the ones that liberate their people to build, experiment, fail fast, and rebuild — with AI as an amplifier rather than a replacement for human judgment.

Bonhoeffer was executed in 1945, two weeks before the camp was liberated. He didn't live to see the world he was writing toward. But his insight endures: you cannot instruct your way out of systemic capture. You cannot teach organisations to be agile while they remain imprisoned by their own processes.

Liberation first. Then, and only then, can the real work begin.

References

Bonhoeffer

CIA Simple Sabotage Field Manual

Digital Transformation Failure

Cargo Cult Agile

Fred George & Microservices

Technical Debt

Solo Founders & AI

AI Code Quality