Resistance Is Not the Problem
The AI transformation is already happening — as a loop, not a programme
Deep Dive #3 in “The Centrifuge” Series — Organisation Level
Last week I wanted to make AI-generated comics. Not a generic “show me a comic” request — a real one, with panels, characters, a visual style I had in mind, and a workflow that would let me produce more without starting from scratch each time.
I opened Claude Code and described the goal. A few hours later I had a working skill that could drive the whole pipeline: prompt engineering, image generation, layout, post-processing, the creative and mechanical steps stitched into a rough workflow that actually worked end-to-end. Along the way I’d installed software I didn’t previously know I needed, run test iterations, and discovered where the boundary sat between what AI could fully automate and what still required my own creative judgement. That was the first loop. It closed with a working capability.
Then the second thing happened, the thing nobody warned me about. The skill worked correctly — that was the problem. Every run produced too much. Intermediate prompts, draft panels, alternative compositions, failed experiments, finished pieces, project state, logs. The output grew faster than my ability to make sense of it. I lost the overview. I couldn’t tell which artifact was the current one, which branch of the experiment had succeeded, where the pipeline stood, or what the next move should be. The skill was shipping faster than my head could absorb.
I built a second thing. A small helper app that read the skill’s project status files and showed me a viewer of results and next steps. That restored the overview. I could see what had been produced, what was pending, where each run was in its cycle. The app wasn’t part of the skill. It was a meta-layer on top of it — a management surface that existed to track what the skill had outrun. That was the second loop.
Now I want the third. Claude Code embedded as a terminal inside that app — the skill runs from within the management layer, results land in the same view, the two systems update each other tightly. I haven’t built it yet. The projection is clear. The app becomes the lifecycle manager. More features migrate inward from the skill over time. The skill itself gets modified from within the app. A single integrated surface for plan, overview, outcome, and process. That will be the third loop. It will produce a fourth constraint I haven’t seen yet. That will trigger the fourth loop.
What I have at the end of this sequence is not a project. It’s a capability stack — three artifacts that didn’t exist before and now do: a domain repo (the skill), a project repo (instances of the capability applied to specific comics), a management tool (the lifecycle app). All three evolved together, each triggered by the limits of the one before. I didn’t plan this architecture. I discovered it by hitting walls and building the next thing that removed each wall. The whole process took hours, not months. It produced something I could not have scoped in advance. The meta-layers only became necessary once the layer below existed.
I’m telling you this story because the usual essay-opening about AI and organisations — the failed steering committee, the dashboard of stalled initiatives, the change management team rehearsing its scripts — is less honest than this. I haven’t been in many of those rooms recently. Most organisations haven’t launched big AI programmes yet. What I have been doing, and what I’ve been watching colleagues and clients do, is this loop. The gap between what the loop actually produces and what organisations know how to see is the real story of AI at the organisational level right now.
Let me name what I think is actually happening.
The traditional unit of organisational transformation was a programme. A programme has a named sponsor, a plan, a budget, a schedule, a set of deliverables, a rollout. Change management was invented to move programmes through organisations. Every muscle a transformation office has is a muscle for running programmes — announcing them, resourcing them, measuring them, explaining them, defending them when they stall.
The new unit of AI-enabled work isn’t a programme. It’s a loop. A loop has a goal, an initial attempt, a discovery of overshoot, a meta-layer built to manage the overshoot, an integration of the meta-layer with the work, a capability stack that emerges at the end. Loops run in hours or days, not months. Loops produce three kinds of artifacts simultaneously — domain knowledge, project instances, management tooling — where traditional projects produce those sequentially and separately. Loops can’t be planned in advance. The meta-layer is triggered by the limits of the first attempt. You don’t know those limits until you’ve made the attempt. Loops look like nothing from the outside until they resolve into a working stack. By then the next loop is already running.
Organisations have no muscle for loops. The measurement systems are at the wrong resolution — they can’t see a three-hour capability stack, only a quarterly programme. The authorisation systems assume a named sponsor and an approved scope, not an iterative architecture discovered in motion. The governance systems are built to evaluate deliverables, not running processes. The HR systems reward completed projects, not the meta-layers that made the projects possible. Even the tool budgeting process — “which AI platform do we license?” — is the wrong question. Loops produce tools. They don’t consume them.
What happens is that individuals run the loop quietly, on their own time, on their own accounts. The organisation sees nothing. It sees a developer “spending time on side projects.” It sees a vague uptick in productivity it can’t explain. The capability stacks accumulate in individual laptops and individual heads. The domain repos sit in private GitHub. The management tools get shared informally between two or three colleagues who happen to work on adjacent problems. The organisation’s actual capability grows rapidly without anyone being able to account for it. When the person leaves, the stack walks out the door with them.
Meanwhile, the organisation’s formal AI story is stuck in a completely different mode. The sociologist Anita Engels has a name for it: Akzeptanzfixiertheit — Fixation on Acceptance. The assumption that before you can move, you need everyone on board. That your job is to persuade, align, and convince. That the effort only becomes legitimate once the room nods. Niels Pflaeging, who has spent years arguing against this mode, is blunter: it’s a failure logic disguised as common sense. Committees chase consensus for programmes that haven’t been authorised. Readiness assessments measure readiness for rollouts that don’t exist. Change management teams rehearse their scripts for initiatives that haven’t been scheduled. The acceptance chase runs on empty at the top while loops produce the real transformation at the bottom.
The Fixation on Acceptance mode and the loop mode aren’t just out of sync. They’re optimising for opposite things. Fixation on Acceptance optimises for agreement before action. Loops optimise for action that discovers what it’s agreeing to only after the fact. A room of executives who’ve been talked into an AI initiative has produced exactly zero capability. A developer running the third iteration of their loop has produced a capability stack with three live artifacts and a clear next step. Both sides are rational inside their own frame. The frames are incompatible. Nobody is translating between them.
The result is the most peculiar form of organisational dysfunction I’ve seen in twenty years of watching this sort of thing. It isn’t that the transformation is failing. It’s that the transformation is succeeding, in hours, in scattered terminals, in private repos, and the organisation that will eventually need that transformation has no idea it’s been happening.
What works, in practice. Not a change management template. A different logic.
Stop planning the programme. Start hosting the loops. The organisation’s job is not to launch an AI initiative. Someone in the organisation is already running one, probably several. The organisation’s job is to find them, understand them, and make the conditions for more of them. Everything else follows from this reframe. The programme language — rollout, adoption, readiness, phases — is the wrong language for what’s actually happening. Replace it with host language: visibility, reuse, protection, integration.
Measure at loop resolution. Quarterly dashboards can’t see a three-hour capability stack. Build visibility into the units of change that actually matter: what loops are running, what stacks they’ve produced, which domain repos exist, which management tools have been built, who’s using them. This is not more governance. It’s more sight. You cannot protect what you cannot see. You cannot route work to the right loops if nobody knows which loops exist.
Authorise what’s already been built. The people running loops are producing capability stacks that belong to the organisation in every way except the formal one. Find them, surface what they’ve built, and give the work legitimacy — a sponsor, a principle set, a shared forum, a place for the artifacts to live other than someone’s laptop. This isn’t the same as taking the work over. It’s giving the work a home that survives the person who built it.
Fund the slow-variable work that the loops are skipping. Loops run fast at the top layer — domain repo, project instances, management tool. What they leave behind is the slow variables: shared architecture, cross-team integration, documentation that other people can read, onboarding paths for the next person who needs the capability. The person running the loop doesn’t have time for any of this. The loop wouldn’t have closed if they did. The organisation’s job is to fund the slow-variable work that turns a capability stack into a capability platform. Unfunded, the stack stays private, stays fragile, walks out the door.
Hold the line on principles. A small number of non-negotiable ones. How customer data flows through the tools the loops are producing. How humans stay in the loop for decisions that affect other people’s lives. How mistakes get surfaced early. What the organisation will not allow, even if an individual loop could do it. Principles make invisible work legitimate to host. Without them, “we’re all running loops” becomes chaos. With them, it becomes coordinated capability-building by willing people, which is the only kind that holds up under the spin.
There’s a harder question underneath all of this. Maybe the problem isn’t how organisations run AI transformation. Maybe it’s that AI transformation isn’t something organisations can run at all, in the sense that they’ve always meant that word. Programmes are something a sponsor can own. Loops aren’t. Loops belong to whoever is running them in the moment, and the organisation’s relationship to loops has to be a hosting relationship, not an owning one.
This is uncomfortable because it redefines what “transformation leadership” even means. The instinct when leadership finally notices what’s happening is to impose order — launch the programme, roll out the official tools, shut down the personal accounts, get everyone onto the same platform. That instinct is almost always wrong, for the same reason top-down transformation has been failing for decades. It treats the actual transformation — the one already underway in scattered loops — as something to be managed rather than something to be respected.
The alternative is not a direction. It’s a different mode. Authorised invitation. Willing participation. System as target, not people. Action over convincing. Principled consequences. These aren’t top-down or bottom-up. They’re orthogonal to the whole debate. The work has clear authority behind it, letting it move. It has invitation built in, letting people self-select. It targets the system — the conditions under which loops can run — not the individuals running them. It prioritises action, not endless deliberation. It holds principles, giving willing people something they can trust.
Most organisations struggle with this. It requires the honesty to say who is authorising the work, who is invited to do it, and who isn’t. Top-down feels safer; it hides the authorisation inside committees. Deliberating feels safer still; it avoids the responsibility of naming a sponsor at all. Both let everyone off the hook for the hard part — taking a position and standing behind it while others decide whether to join.
The hardest part of this moment is that almost nobody in the room is wrong. The committee members deliberating about AI adoption are being responsible. The engineers quietly running loops at AI speed are being productive. The finance function questioning ROI is being careful. The compliance team worried about data handling is being vigilant. Each local choice is rational. The aggregate effect is an organisation that has already changed shape without a decision being made.
The goal was never uniformity. That’s worth saying plainly. Uniformity is everyone agreeing, everyone on the same page, everyone having been persuaded — the fantasy that every transformation programme sells and none has ever delivered. What real change actually needs is unity. Something very different: willing people acting together on the same system, authorised to do so, holding the same principles, not necessarily agreeing on everything else. Unity is a product of common action, not of convincing. You can reach it in a week with five willing people who are already running loops. You can fail to reach it in two years with two thousand reluctant ones who are still in the deliberation phase.
The centrifuge spins. Things separate. Most organisations haven’t noticed they’ve been spinning for a while. The loops were already producing capability stacks while the committee was still comparing vendors. The ones that survive the spin aren’t the ones that eventually launched a big programme. They’re the ones that looked at the ground, saw what had already been built, and had the honesty to name it as theirs.
This concludes the initial trilogy of The Centrifuge. More deep dives will follow as the spin continues. If you’re already running loops — or watching your organisation fail to see them — let’s talk.