Loops within loops

The phases were always a fiction

Ask anyone who builds products whether the work is linear and they'll say no, obviously not. Discovery never really stops. Prototypes expose the problem you misunderstood. Delivery teaches you things that send you back to the drawing board. Growth feeds new audiences and new use cases back into the product.

Every serious framework of the last thirty years says the same: the double diamond loops back, continuous discovery loops, plan–do–study–act loops for continuous improvement, build–measure–learn is the lean startup loop, scrum loops every sprint, CI/CD loops every commit, growth compounds through loops. The textbooks are full of circles.

Strip the labels off and every one of those frameworks is the same shape: sense where you are, work out what to do, do it, look at what happened, go again.

And yet we keep drawing plans (and even roadmaps) as sequences of boxes. We run "discovery, then delivery". We plan in quarters and ship in phases. The loops live in the theory; the phases live in the calendar.

There’s a reason for that, and it isn’t stupidity. Loops are harder to articulate and look more expensive to run. Phases are legible: they have a start, an owner, a date and a deliverable. They fit on a Gantt chart and into a budget. Loops done well are messier. They have a cadence rather than an end. They ask you to keep paying attention. They require a different team mindset.

A common failure is that rationed loops collapse back into phases. You do discovery once, up front, because you can’t afford to keep doing it. You test once, near the end, because that is when there is something to test. You optimise after launch, if there is still budget. The loop survives as language, but too often the operating model is still linear.

This was always an uncomfortable compromise. We knew product work should loop, but loops were expensive to run and hard to govern. AI changes that equation.

The unit of work was always the loop

A recurring pain for product delivery teams has been getting organisations to stop treating discovery, design, delivery and growth as stages you pass through, and start treating them as parts of one continuous product loop. That is how you get to better outcomes: not by making the phase boundaries cleaner, but by tightening the feedback between what you observe, what you decide, what you make and what you learn.

I have lived this inside a full-service digital marketing agency, where lean was sometimes something you did against a wall when there were too many people in a meeting; where linear process inherited from campaigns was always close to hand; and where risk-aversion could easily become decision paralysis. I certainly wasn’t perfect. I was lucky to be educated by brilliant colleagues and by the lived experience of many different transformation and product delivery cycles. The point is simply that you can always do better.

The useful shift is to stop asking, "Which phase are we in?" and start asking, "Which loop are we trying to improve?"

There is the big product loop: observe, plan, act, reflect and learn. But inside it are many smaller loops. A research loop. A prototype loop. A prioritisation loop. A design loop. An architecture loop. A test loop. A deployment loop. A growth loop. Some turn daily, some weekly, some quarterly. Some are mostly human, because they depend on judgement, taste, relationships or accountability. Some are increasingly machine-shaped, because they involve repeatable analysis, generation, testing, monitoring or optimisation. Most are becoming a blend.

That is where AI starts to matter. Not because it magically replaces the product process, but because it changes the cost, speed and shape of the loops inside it.

Reading the model

The diagram is not meant to be a new methodology. It is a way of making visible what already happens when product work is done well.

At the outer level there is one continuous product loop. I use observe, plan, act and learn because they echo the family of feedback-loop models that run through control theory, OODA, plan–do–study–act and, more recently, agentic loops: sense the world, decide what to do, do it, and learn from what happened. 

The words are deliberately more generic than discovery, design, delivery and growth – or discovery, alpha, beta, live. They preserve the reality that different kinds of work happen at different moments, without pretending those moments are always clean phase gates. You observe the world, customers, systems, markets and constraints. You plan what to do next. You act by making, testing, shipping or changing something. Then you reflect on what happened and feed that learning back in.

Inside that outer loop are many smaller loops that have the same basic shape. Research loops, prototype loops, design loops, architecture loops, test loops, deployment loops, optimisation loops, growth loops. They are related, but they do not run in lockstep. Some turn in hours, some in days, some in weeks or quarters. Some depend on other loops. Some should be deliberately slowed down because the stakes are high. Others should be made as fast and cheap as possible.

The second thing the model tries to show is that every loop now has a different human-machine mix. Some loops are still mostly human, because they depend on judgement, taste, trust, relationships, ethics or accountability. Some are increasingly machine-shaped, because they involve repeatable generation, analysis, testing, monitoring or optimisation. Most sit somewhere in the middle.

That is the bridge to AI. The interesting question is no longer simply, “Can AI help with this task?” It is, “Which loops can AI compress, which loops can AI keep alive, and where do human attention, judgement and accountability need to move when more of the loop becomes machine-run?”

What AI actually changes

Two things, and, in my judgement, they aren't equally important.

The first is the one everyone talks about: AI compresses loops, especially when agents let work that used to run in sequence run in parallel. You can go from a problem to a working prototype in an afternoon; discovery and delivery start to blur. I have mixed feelings about this. Compression is real and often wonderful, but it's also the easiest thing in the world to mistake for progress. A loop you got round quickly is not the same as a loop you learned anything from. And the compression is asymmetric: agents are brilliant at building-to-learn and still patchy at building-to-last, so the gate between "prototype" and "production" matters more, not less.

The second change is quieter and, I think, far more important: agents let you run more loops. Where before you could afford one discovery loop and one delivery cadence, you can now afford many more: a research spike here, a validation loop there, a tight build-test-fix loop, a monitoring loop that watches production and feeds itself back in. The number of loops you can keep alive at once can rise dramatically. That is the change that reshapes the work.

Cheap loops create more loops

Loops get cheaper because you no longer have to run every turn yourself.

Each loop, and each stage of each loop, can sit at its own point on a dial between fully human and fully machine. This is not a new idea; human-factors researchers have been describing levels of automation for decades. The key point is that automation is not one setting for the whole task. It can vary by step. You might gather information automatically, analyse it together, decide as a human, and act automatically. Karpathy's "autonomy slider" is the same idea for AI: a control you move to the right as trust is earned, not a switch you flip.

So some loops run almost entirely human: talking to a customer, making a values call, deciding what not to build. Some can run almost entirely by machine: regenerating tests, redeploying, watching dashboards. Most sit somewhere in between, with the human and the agent handing work back and forth within a single turn of the loop. The diagram shows this directly: each ring is coloured by who mostly turns it — human, agent, or both.

And once a loop is cheap to run, you run loops you'd never have bothered with. There is a Jevons-like effect at work: make a resource cheaper and you often consume more of it, not less. Cheaper loops don't necessarily buy you fewer loops and more idle time; they buy you more loops, and a pile of work that was never worth doing suddenly becomes worth doing. That's the part I find most exciting, and it isn't really about AI — it's about what becomes possible when the cost of a feedback cycle falls through the floor.

This doesn't remove the human. It moves them.

Here's the conclusion I keep coming back to: human work is moved, not eliminated. Push a loop hard to the right, let the machine run it, and the human doesn't disappear. They relocate. They stop being the operator and become the supervisor of a verification loop, and the load there goes up, because machines generate far faster than humans can check.

So the binding constraint moves. It used to be production — how fast can we build or create a thing. Now, increasingly, it's verification — how fast can we trust what's been analysed, created or built. The bottleneck moves from writing to reviewing (which is exactly why the companion piece to this one was largely about reviewing code you didn't write). The failure modes are the classic automation ones: the hand-off problem — an agent that runs autonomously and then drops a decision on a human who has stopped paying attention — and over-trust, sliding the dial right faster than the thing has earned it.

None of that is an argument against giving loops more autonomy. It's an argument for being clear about where the human goes when you grant it, and for designing the verification loop as deliberately as you design the work.

What keeps it from flying apart

If you're going to run dozens of loops inside one product loop, a few things hold it together. I've put them on the diagram as guiding principles, but I'm confident these are not really new, just best applied with a systems mindset:

1. Separation of timescales. The inner loops have to run much faster than the outer one. This isn't a preference, it's a stability condition — it's how cascade control works in any nested feedback system. Stick a slow human approval inside a fast agent loop and you get exactly the instability you'd predict.
2. Conservation of human attention. Automation moves attention; it does not abolish it. Plan for where the attention goes, not just where it's saved.
3. Match autonomy to stakes. Reversible, cheap work can run autonomously; irreversible, expensive work stays human-guided-and-gated.
4. The substrate compounds. Context, memory, relationships and tooling make every future loop cheaper. Every loop that writes something down makes the next loop faster. The substrate – human and machine – is the real moat, not any single clever loop.

What it means for how you organise

I'm least certain here, so take it as provocation rather than prescription. If the unit of work is the loop and not the phase, a few things follow that sit awkwardly with how most teams are built.

You stop managing phase-gates and start managing a portfolio of loops — which are running, at what cadence, at what mix of human and machine, and which ones need more human attention than they're getting. Roles stop mapping so cleanly: a product person ends up working inside what used to be "delivery", an engineer inside what used to be "discovery", because the loops don't respect the old boundaries. And the senior job changes shape — less reviewing the output of each loop, more designing the system that produces reliable loops: the substrate, the guardrails, the verification, the decision about where the dial sits.

That's a bigger change than "we adopted some AI tooling". It's a change in what you're managing.

What I’m watching next

I'm working this out as I go. The model in the diagram is as much a description of what I noticed happening as a theory I set out to prove. I don't think it's finished and, in particular, I'm still watching what this does to team shapes and organisational design.

The things I'd watch out for: whether the verification load quietly swamps the gains; whether "more loops" turns into motion that merely looks like progress; and whether the quality of what gets built actually improves, or just the quantity.

But I'm fairly convinced of the shape. Product development was always loops pretending to be phases. The interesting thing about this moment isn't that the machines can build. It's that, for the first time, we may be able to afford to run the loops for real.