Monthly Archives: July 2026

In AI-Native Delivery, Architecture Has to Say Where to Stop

Leave a reply

When you heat metal and cool it slowly, its internal stresses are relieved. The internal structure settles into a more stable state.

This is annealing, and I think it is a useful way to think about software architecture when AI agents are doing part of the delivery work.

Hot and cold are not just descriptions. They are controls.

A hot zone is one where change is permitted, cheap and expected. A cold zone is one where the structure has been deliberately locked. Temperature is not something the code naturally possesses. It is a choice the team makes and then enforces through permissions, repository boundaries, tool access, testing and approval paths.

That kind of graduated control becomes important when agents are the ones making changes.

Most software architecture practices assume that everything is modifiable in principle. Given the right people, the right process and enough time, any part of a system can be changed.

Architecture evolves. It has always been expensive, but it has also been manageable because humans controlled the pace.

AI delivery changes that.

When agents can propose changes, write code and modify configuration faster than any human review process can follow, the question of what they can reach becomes urgent.

Anything within reach becomes a candidate for change in pursuit of the objective the agent has been given. An agent does not intuitively distinguish between a throwaway utility function and the data model that forty other services depend on. If both are in scope, both are available.

The tempting response is to make the entire architecture fair game and trust the AI to find the right shape.

The first problem is comprehensibility. If agents have been free to touch everything, you can end up with an architecture whose design intent nobody can reconstruct. It may work perfectly well. The problem is that no human was accountable for the structure as a whole. You own something you cannot properly explain.

The other problem is economic. The more of the architecture an agent must consider, the more context it needs. That means more tokens, slower reasoning, higher cost and more opportunities for important details to be missed.

An architecture with no cold zones is not only difficult to govern. It is expensive to operate.

The response is to make architecture “temperature” choices explicit.

Some parts of an architecture should run hot.

These are places where change is cheap, feedback is fast and the cost of a wrong move is low. Presentation logic. Integration adapters. Prompt templates. Workflow configuration.

These are the soft spots. They are deliberately kept malleable so that agents can work freely. Their structure is not expected to last. It should be shaped and reshaped as requirements shift and models improve.

Other parts should run cold.

These are decisions with a wide blast radius, many dependants or serious security and regulatory consequences. Domain models. Event schemas. Security boundaries. Contracts between services.

Once these structures have proved themselves, they should crystallise intentionally. The cost of changing them is high, and their stability is load-bearing.

Agents do not modify cold zones. They work within them.

These classifications are not permanent. A domain model may run hot while a team is still discovering it. It cools as the design stabilises and more of the system comes to depend on it.

The hard work is managing that change in temperature.

You need to decide what to harden and when. Sometimes a cold zone must be reheated for a major refactor, then cooled again once the new structure has been established. Early in delivery, more of the system can remain hot while the team learns what the architecture needs to become. As the structure proves itself, the temperature comes down.

I first came across this idea while studying AI at Edinburgh University many years ago.

Simulated annealing is a classical optimisation technique. It runs hot early so that the algorithm can explore broadly, then cools gradually as it converges on a solution.

Here, the same idea is being applied in the other direction. It is not a technique inside the AI system. It is a governance model for the systems that AI is allowed to change.

None of this is entirely new.

Domain-driven design, intentional architecture and event sourcing all try, in different ways, to separate the things that change from the things that need to remain stable.

What changes with AI is the speed and autonomy of the actor.

An agent does not slow down when it reaches a part of the codebase that looks important. It does not become cautious because a change has political, operational or architectural consequences. If the change is within its permissions and appears to support its objective, it will make it.

The discipline that once lived mainly in code review and architectural governance now needs to be built into the system itself.

The teams that get this right will not necessarily be the ones with the best models or the most sophisticated orchestration. They will be the ones that can read the temperature of their architecture: where agents should be free to explore, where they must stop, and when those boundaries need to move.

AI-native architecture is not simply about making systems easier for agents to change.

It is about controlling where change is allowed, how quickly it can happen, and when the boundaries themselves need to move.

The architecture becomes part of the control system.

The AI Jenkins Moment

2 Replies

We have been here before.

When DevOps arrived, a lot of time was spent talking about tools. Jenkins or Bamboo. Puppet or Chef. People drew diagrams of their pipelines and called it a strategy. They were wrong, but productively wrong. At least they were trying to automate something, and it made things better. A bit.

The second argument was more sophisticated. It was about the shape of the pipeline itself. How many stages. Where to gate. Shift left. Continuous deployment versus continuous delivery. This felt like real thinking. It was still solving the visible problem rather than the important one.

In the DevOps transformations I saw work, the decisive shift was not the pipeline. It was developers taking responsibility for what they deployed. That meant tearing down the wall between the people who wrote the code and the people who ran it. The tools were downstream of that insight. The pipeline was simply a means to achieve the outcome. The Jenkins debate was distracting us from the change that actually mattered.

Agile followed the same script. First came the tool debate: Jira, VersionOne or Rally. Then the framework debate: Scrum, SAFe, Kanban or a bespoke playbook. Meanwhile, the people who understood the change were talking about feedback loops, cost of delay and what it really meant to collaborate with a customer.

Now we are doing it again.

Today, the conversation usually starts with models: GPT, Claude or Gemini. This is the Jenkins debate.

From there, it moves to orchestration and architecture: LangChain or LlamaIndex, multi-agent or single-agent, a common workbench or multiple platforms. This is the CD pipeline debate.

The harder question is how we learn to work with systems we cannot fully understand. It requires knowing when to constrain an agent and when to give it room. It is the difference between telling an agent to “review the program plan” and deciding what information it can use, what evidence it must show, when it should stop and when a human needs to step in.

Tooling and vendor selection are only the surface. The real challenge is building this as an organisational capability. Very few organisations know how to develop that capability, govern it and make it repeatable.

And just as with Agile and DevOps, the implications are not the same for everyone. What this means for an engineer is not what it means for an architect. What it means for a tester is not what it means for an executive. Both movements reshaped every one of those roles. We spent years working out what that meant in practice, and we got plenty wrong along the way. AI will do the same. In most organisations, that conversation has barely moved beyond engineering and productivity use cases.

That is the AI Jenkins moment. We are arguing about the tool while a new craft is being invented.

Too few organisations are helping people develop the skills that craft requires: curation, architectural judgement, leading hybrid human-agent teams and working with non-deterministic systems.

I have developed a leadership programme that I am excited to pilot internally in the coming weeks. It is one attempt to move the conversation beyond tools and start building that capability. The tools will change. The capability is what will remain.

Why Upfront Alignment Determines Whether Complex Programs Succeed

Leave a reply

If you have worked with me in a large program, you have probably heard me say: “We need to do more conceptual work.”

What I mean is that we need to understand how the work will actually happen before we start trying to execute it. Not just what the deliverables are, but how the teams will work together, where the dependencies are, who is responsible for what, and what we will do when something goes wrong.

After reading How Big Things Get Done, I realised that what I have been calling conceptual work is really a form of planning.

Most people think planning means building a project schedule. I think the real planning happens before that. It is the work of mentally executing the program before anyone starts doing the work—playing through who will do what, where the handoffs are, what happens when dependencies fail, and where the gaps might emerge.

This kind of planning is especially important in complex programs because alignment is not automatic. Different teams often have different assumptions about scope, sequencing, ownership, quality, risk, and progress. If those assumptions are not surfaced early, they show up later as delays, rework, escalation, or confusion.

What this planning really creates is a shared mental model. Everyone leaves the room understanding not just the plan, but how the program is expected to behave when reality starts pushing back. That shared understanding allows teams to make good decisions independently instead of constantly waiting for coordination.

A couple of years ago, we delivered a large data centre exit. We were working to immovable deadlines. The bulldozers were already scheduled to demolish the building. We spent weeks repeatedly redesigning how we were going to deliver the migration before we touched production. How should we bundle the applications? What testing did we need to perform? How would we get sign-off to migrate?

We went through painful brainstorming to think about what could go wrong. We dug into the tooling to understand what processes it enabled, and where it did not help us. We found problems, misunderstandings, and gaps before they became execution issues.

Were we perfect in execution? No. There were long nights and weekends, unforeseen problems, COVID-19, last-minute rescues, and even some rollbacks.

We succeeded not because execution was flawless, but because we had already thought through most of the difficult decisions before execution pressure arrived. Once everyone agrees how the work will happen, another benefit appears almost immediately: you can finally measure progress properly.

That experience reinforced two things for me: first, alignment has to happen before execution pressure arrives; second, progress has to be measured in units that actually mean something.

The first practical output of good planning is meaningful progress measurement.

“Percentage complete” does not mean much unless the pieces underneath the calculation are meaningful. A team can be 80% complete for weeks if the remaining 20% contains the hard decisions, unresolved dependencies, or untested assumptions.

Better measures are tied to real units of progress: work packages completed, process steps agreed, phases exited, software modules built, features tested, decisions made, or risks retired. The point is not to create reporting for its own sake. The point is to understand whether the program is actually moving.

Another important part of upfront planning is looking for ways to decouple work and retain optionality.

It is tempting to combine things to reduce retesting, reviews, or governance effort. Sometimes that is the right answer. But every time we couple pieces of work together, we also increase risk. A delay in one area can block another. A missed dependency can suddenly become a program-level issue.

Good planning creates options. Poor planning leaves you trapped by unnecessary dependencies.

Thinking through options early allows us to identify off-ramps. What can move independently? What can be sequenced differently? What can be recombined if a dependency does not come through? What decisions do we need to keep open for longer?

Something will invariably go wrong in a complex program. The goal is not to create a perfect plan that assumes nothing changes. The goal is to create enough shared understanding and enough optionality that the program can adapt when things do change. That is why upfront alignment matters. It isn’t bureaucracy; it’s how complex programs remain executable when reality inevitably refuses to follow the plan.