The Cascading Experiences Model makes ownership visible across a complex system.

It starts with a moment, traces that moment into an experience, refines the experience into capabilities, and keeps the people shaping it in view.

That leaves an uncomfortable question.

What happens to those people when AI makes execution dramatically cheaper?

The answer circulating through many executive teams is simple: the same work should now require fewer people.

You can see how they get there.

A developer completes a task in a third of the time. A product manager turns meeting notes into a polished brief before the call ends. A designer generates ten plausible directions in an afternoon. The productivity chart moves up and to the right.

Then somebody applies the ratio to the org chart.

This is where the arithmetic breaks down.

The chart measures how quickly artifacts appear. It says very little about whether the team chose the right problem, understood the consequences, protected the integrity of the system, or improved the customer's experience.

AI makes those questions more urgent because it allows us to act on weak answers much faster.

Code Became Cheap. Coherence Did Not.

I previously argued that the “code is too expensive” excuse is dead.

AI has reduced the cost of exploring an idea. Teams can scaffold a working prototype, simulate edge cases, generate test data, and compare technical approaches before committing months of engineering effort.

That is an extraordinary advantage during discovery.

It also creates a second-order problem.

A team can now produce a convincing solution before it has developed a convincing understanding of the problem.

Imagine a customer asks for a new authentication option. Within hours, a team can generate the interface, API contract, data model, telemetry, tests, and deployment configuration. Everything looks reassuringly complete.

The harder questions arrive later:

Which customer moment is this supposed to improve?
Who decides when the option is enabled?
How does it interact with existing identity policies?
What happens when authentication succeeds but downstream authorization fails?
Which experience level owns recovery?
What evidence would tell us that trust improved?

None of these questions requires much code. All of them require context, judgment, and somebody willing to own the consequences.

Cheap execution lets a coherent team learn faster. In an incoherent team, it gives every unresolved assumption a faster route into production.

Moving Up the Stack

The pattern is familiar.

Writing once demanded careful handwriting and expensive rework. Typewriters reduced the physical burden. Word processors made revision cheap. Spellcheck absorbed a layer of mechanical accuracy. Generative AI can now help with structure, synthesis, and the first draft.

Editors still have plenty to do.

Their contribution has moved toward argument, audience, evidence, rhythm, and the judgment to remove a paragraph that is perfectly written but does not belong.

Software work is following a similar path.

For years, professional value was easy to associate with visible production: requirements written, screens designed, tickets closed, code committed, incidents resolved. Those artifacts remain useful, but their production tells us less about the quality of the thinking behind them.

The valuable work increasingly happens before, around, and after generation:

noticing that the requested feature addresses the wrong moment
identifying an assumption shared by nobody outside the meeting
tracing a local decision across the five experience levels
protecting an architectural constraint when a shortcut looks harmless
deciding which edge cases deserve first-class treatment
recognizing when the available evidence is too weak to proceed
validating that a shipped capability changed the intended outcome

This work is difficult to count. It often looks slower than generation because its purpose is to prevent the wrong thing from accelerating.

That makes it easy to undervalue right when it becomes most important.

A Different Bottleneck

Consider what happens when a team can generate thousands of lines of plausible code in a day.

Review capacity does not expand at the same rate. Neither does domain knowledge. Security context, customer history, operational awareness, and architectural memory remain distributed across people who have acquired them over time.

Soon the scarce resource is confidence.

Can we explain why this approach belongs in the system?

Can we describe what it will change for a customer administrator, an end user, and the person they serve?

Can we tell the difference between a reusable platform capability and an exception for one customer?

Can we recover when the generated implementation encounters the parts of reality that were absent from its prompt?

These are judgment calls. They draw on technical skill, but also on experience, curiosity, restraint, and an understanding of the whole system.

AI can contribute to that process. It can expose alternatives, challenge assumptions, summarize evidence, and make consequences easier to explore. The quality of the result still depends on the context we provide and the standard we apply.

A weak question answered quickly remains a weak decision.

How Roles Change

The practical response is to redesign work around the decisions that matter.

For product managers, the centre of gravity moves away from maintaining a backlog. More time goes into clarifying the moment, gathering evidence, exposing assumptions, and helping a team understand where ownership belongs.

Designers gain more ways to explore an experience before production. Their judgment shows in the frames they choose to investigate, the behaviours they make tangible, and the human consequences they refuse to hide behind a polished screen.

Engineers spend less time reproducing familiar syntax. Their leverage comes from shaping boundaries, evaluating generated approaches, protecting invariants, designing recovery, and seeing how a convenient local change behaves under real scale.

Architects become more involved in the flow of decisions rather than appearing at review gates. As implementation options multiply, teams need help understanding which choices preserve future freedom and which quietly narrow it.

Operations and support teams bring the evidence that generated prototypes rarely contain: unusual customer behaviour, recurring failure modes, policy constraints, and the practical work required when the happy path ends.

Leaders have perhaps the largest adjustment to make. Output volume is an increasingly poor proxy for progress. They need to create space for sound decisions, make ownership explicit, and reward people who prevent avoidable complexity even when prevention produces no impressive demo.

Every role moves closer to consequence.

What “Better” Means

“Better people” is an easy phrase to misuse.

It can sound like a call to replace a team with a smaller collection of exceptional performers. That interpretation misses the opportunity.

The better organization helps more people exercise better judgment more often.

It gives them enough context to understand the system they are changing. It makes decision rights visible. It creates a shared language for moments, experiences, capabilities, and outcomes. It allows disagreement before commitment and expects accountability after it.

Hiring matters, of course. So do experience and technical depth. Yet even excellent people make poor decisions inside an organization that fragments context, rewards activity, and leaves ownership ambiguous.

The environment determines whether judgment can compound.

A team with clear intent can use AI to test more possibilities, find weaknesses earlier, and spend its time on the decisions that deserve human attention. A team working from an ambiguous brief will simply manufacture ambiguity at greater speed.

This is why headcount reduction is such a narrow way to understand the opportunity.

Some tasks will require fewer people. Some roles will change substantially. New products may reach the market with teams that would once have seemed impossibly small.

But a platform is more than the sum of the artifacts required to build it. It carries policies, promises, dependencies, exceptions, and consequences across many experience levels. As the cost of adding to that system falls, the discipline required to keep it coherent rises.

The Work Ahead

We are still early in this transition. Teams are learning where AI genuinely expands their judgment and where it merely creates the appearance of progress.

The organizations that learn fastest will resist the temptation to measure the future with yesterday's units. Lines of code, tickets completed, documents produced, and screens generated describe activity. They rarely describe whether a customer can now authenticate with confidence, whether an agent can recover from failure, or whether a platform can absorb the next change without losing itself.

Those outcomes belong to people.

AI gives them better instruments. It shortens the distance between an idea and something that can be examined. It makes alternatives cheaper and feedback earlier. Used well, it creates room for deeper attention.

That room should be spent deliberately.

On understanding the moment.

On reducing ambiguity.

On protecting coherence.

On making ownership real.

On deciding what deserves to enter the system at all.

The future of software will involve fewer hours spent producing familiar artifacts. Whether that leads to better products depends on what we ask people to do with the hours we get back.

The opportunity is larger than efficiency.