Part II — Understanding Flow · Chapter 17 · First Public Draft

Artificial Intelligence

The same friction, amplified — and far less forgiving of what it lands in.

BothAll four

Everything in the previous chapter is true of AI, more so, and faster.

That is the whole of the sober case, and it is worth stating plainly before anything else, because AI is currently discussed as though it were a different category of thing rather than the same category operating at a different speed.

AI amplifies organizations. It doesn’t repair them. It reveals them.

It is worth being plain about what the word covers, because the public conversation carries a great deal of inherited fiction.

Despite the name, today’s AI is not intelligence in the human sense. It has no goals of its own. No intent. No understanding of why anything matters. It is an extraordinarily capable prediction system, generating outputs from patterns, instructions and context — and being extraordinarily capable is not the same as being autonomous.

That distinction is not a way of talking AI down. It is the reason the rest of this chapter holds. The AI of science fiction pursues its own objectives; today’s AI executes ours. A system that executes our objectives inherits whatever clarity we had when we set them, which is exactly why it amplifies an organization rather than replacing one.

An organization with clear ownership, capabilities it can name, and decisions made close to the work will get compounding value from AI, because it has something coherent to amplify. An organization where nobody can say who owns what will get faster production of things nobody owns.

AI also changes where complexity lives. Every major reduction in technical friction increases the importance of organizational architecture.

For decades, building software was constrained by scarce technical expertise. Ideas waited for engineering capacity. Improvements competed for developer time. Organizations naturally optimized around that constraint.

AI is rapidly changing it. More people can now describe software instead of writing it. More ideas become working systems. More experiments become products. Technical friction is falling at a pace few organizations have experienced before.

But removing technical friction does not remove complexity. It relocates it. Into ownership. Into interfaces. Into information. Into decisions. Into the architecture of the organization itself.

The friction does not disappear. It changes form.

AI removes technical friction. It exposes structural friction.

Every unclear ownership, every unnecessary dependency, every weak interface and every ambiguous decision becomes more visible when software can be created in hours instead of months.

Organizations rarely become chaotic because AI is fast. They become chaotic because their structures were already struggling to absorb change.

There’s a more specific version of this that matters for how you organize. An AI system performs best under the same conditions a team does: a clear purpose, explicit boundaries, and a well-defined responsibility. Ambiguity doesn’t get smarter because you automated it — it produces confident output built on an unclear question, which is considerably harder to catch than a person saying “I’m not sure what you’re asking.”

Which brings the chapter to the question being asked badly almost everywhere.

The public conversation is about what AI will replace. I think that’s the wrong question, and it’s the wrong question in an interesting way. Whether AI can do the work is increasingly settled. Plenty of it, it can, and the remaining argument is mostly about timing.

The question that isn’t settled is who owns the outcome.

A system can execute a decision. It cannot be accountable for having made it, because accountability requires someone who can answer for the outcome, explain the reasoning, absorb the consequence, and decide differently next time.

And ownership is a great deal more than approval, which is where this argument usually gets flattened.

Ownership is judgement. It is deciding what matters, and what matters more. It is weighing outcomes that cannot both be had. It is holding the context that made a decision reasonable at the time. It is accepting responsibility when it turns out not to have been. It is explaining the reasoning to someone who has to live with it. It is learning from the consequence, and choosing differently next time.

AI can assist every one of those activities. It owns none of them.

AI amplifies human capability. It does not replace human judgement. It does not replace human responsibility. It does not replace human accountability. It does not replace human ownership.

That distinction becomes more important as AI systems become more capable, not less. The more decisions AI can support, the more valuable human judgement becomes — not because people can outperform AI at every task, but because an organization still needs someone who owns the outcome.

Execution can be delegated. Ownership cannot.

That isn’t a sentimental distinction, and it isn’t a claim about what AI will eventually be able to do. It’s structural. An organization that quietly moves its people into execution-only roles while AI handles the deciding hasn’t become more efficient — it has removed the part of itself that was supposed to own anything, and it will discover this the first time something goes wrong and there is no one who can say why the decision was made.

The organizations that will do well with AI are not the ones that adopt it fastest. They’re the ones where ownership was already unmistakable, so there was something for the amplification to attach to.

The boundary this dissolves

Everything above is the defensive case. There is a second claim, it is the one I actually care about, and it is the reason this chapter sits where it does rather than at the end of the paper as a topical afterthought.

Building software is on the same path financial modelling took: from a specialist activity you queued for, to something people simply do as part of their work. Financial modelling was once specialist enough that organizations queued for experts; today there is no spreadsheet department and no spreadsheet request process. The competence did not disappear — it dissolved into the work itself. AI is the mechanism that finishes that journey. Not an accelerant on an existing trend — the thing that removes the last structural reason for the boundary to exist.

Consider what the boundary between IT and the business was ever for. Not governance. Not standards. Not security. Those are consequences.

The boundary exists because turning an intention into a working system required a scarce specialist competence, and scarce competences get gathered into a function, given a queue, and managed as a supply. Every artifact of that arrangement — the requirements document, the intake process, the prioritization forum, the delivery contract, the phrase the business used by people who work for the same company — descends from a single premise: that someone has to translate.

That premise is the thing that is going.

Not entirely, and not evenly. Complex systems, integration, data at scale, and the parts where being wrong is expensive remain specialist work for a long time yet. But the large middle — the ordinary building that consumes most of the capacity of most technology functions — is moving to the people who know why the thing is needed. Not eventually. It has already started.

The consequence is profound. When software stops being scarce, organizations will create far more of it. More workflows. More automations. More AI agents. More experiments. More local solutions.

Architecture therefore becomes more important, not less. Not because more control is required, but because more creation requires better coordination.

Which means the question in front of every technology leader is not how to adopt AI. It is what their function is for once translation stops being scarce.

I think there is a good answer, and it is not a smaller version of the same thing. What survives is the part that was never really about translation: guardrails, interfaces, the discipline of ownership, and the judgement about which decisions are cheap to reverse. In other words, the competence this paper has spent Part III describing — moving into the organization rather than sitting beside it. IT not as a better partner to the business. IT as something the organization simply knows how to do.

In many ways, architecture becomes less about technology than it has ever been. Its role is no longer to design systems that people cannot build themselves. Its role is to design the conditions in which thousands of independently created systems can still behave like one organization.

I should be as honest here as I was in Part II: this is a direction I am confident about and a timeline I am not. An organization that misjudges the date loses a year. One that misjudges the direction spends that year defending a boundary that has already gone.

And the condition attached to it is the same condition, only stricter. Distribute the ability to build without distributing the discipline of ownership and AI does not dissolve the boundary. It floods the organization with systems nobody owns, built by people who were never told what good looks like, at a speed no governance process was designed to absorb. The spreadsheet problem, at machine scale.

There is an irony in all of this. For decades we assumed technology was the difficult part. AI suggests something different: technology may become the easiest part.

Coordination remains difficult. Shared understanding remains difficult. Ownership remains difficult.

Organizations that mistake easier software for easier organizations will simply create more software — and more friction. Organizations that reduce structural friction will create something very different. They won’t simply build software faster. They’ll create value faster.

AI is the most powerful multiplier available and the least forgiving of the conditions it is dropped into. It doesn’t make the rest of this paper optional. It makes it urgent.

As technical friction continues to fall, Organizational Flow becomes the primary determinant of how much value an organization can actually realize. Which makes the question of how it is deliberately cultivated the only one left — and that is the whole of Part III.

All chapters17 of 30