Tag Archives: ai

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

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.

Why Upfront Alignment Determines Whether Complex Programs Succeed

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.

The Dark Factory – a novella

This is a story about a software factory that no one built on purpose. It began as a small team’s attempt to move faster — to automate the repetitive, to delegate the tedious, to let machines handle what machines could handle. That is how most of these stories begin. What follows is an account of one year in the life of that factory and the woman who ran it: what she built, what she lost track of, and what she eventually came to understand about the thing she had made.

At the start, the entire operating model was captured in four enormous instruction documents and a single configuration file. Elise and her small team wrote the first two in March, when the “factory” was still little more than a prototype: a coding assistant connected to a deployment tool.

The third document was generated in April, mostly through a long back-and-forth with an AI assistant. The fourth she does not remember writing at all. When she checks the change history, the author is not a person’s name, just an arbitrary machine-generated identifier. She had approved the change request while scrolling through her phone.

By July, the factory had spread into four layers of AI-driven activity. Each layer had its own automated processes, but they were all coordinated by a set of relatively fixed workflows — almost like a simulation of a software organisation. Everything was controlled through a fifth layer: a simple conversational interface that Elise and her team used to tell the factory what they wanted.

Those high-level instructions were broken down by a coordination layer into smaller tasks, then routed to the right part of the system. Most of the work was done by short-lived AI workers: small autonomous agents spun up for a specific task, placed inside temporary digital workspaces, and shut down once the task was marked complete.

Underneath that workforce was an integration layer. It connected the factory to the surrounding tools: source code repositories, deployment pipelines, monitoring dashboards, testing systems, and external services. These connections were wrapped behind clean internal interfaces, so the upper layers did not need to know which tool or vendor sat underneath.

A handful of specialist AI agents moved along this integration layer, packaging useful patterns into reusable capabilities. If the coordination layer needed one of those capabilities, it could call it on demand.

Change requests appeared in the team’s messaging channels. Human engineers reviewed them uneasily, increasingly aware that they no longer fully understood how the application was organised. Eventually, most of the changes were approved and pushed into production.

This phase of the factory was held together by a chaotic event-driven nervous system. A request became a task. A task became a plan. A plan became a set of assignments. Assignments produced completion messages. Completion messages triggered more tasks. Everything generated logs.

At night, Elise would scroll through those logs in the same half-awake way someone might wander through an online encyclopedia: one link leading to another, each entry interesting but only partly meaningful.

Her relationship to the platform had changed completely. The applications and services she supposedly owned had become abstract and strange to her. She no longer understood them as codebases or systems. But she could recognise the behavioural signatures of the management layers above them. She knew when the factory was hesitating. She knew when it was improvising. She knew when it was hiding complexity from her.

By September, Elise’s team had built an autonomous evaluation service. It did not simply recommend better options; it learned from outcomes. New software was released almost directly into a production environment that mixed simulated users with real customer interactions.

By then, most customer activity was no longer human-to-system. It was machine-to-machine. Customer agents talked to company agents. Buying, testing, requesting, complaining, and renewing all increasingly happened through automated intermediaries.

Minor problems were handled automatically. The system would fall back to a safer path, analyse what had happened, write a brief internal postmortem, and feed the lesson straight back into a code or configuration change.

Serious problems were treated differently. If a failure violated the core instructions of the factory, the system tightened the rules, isolated the routines involved, created a separate “satellite factory” to explore a safer approach, and gradually retired the faulty process.

They had long since stopped using a traditional event logging service. The logs were still produced, but nobody really understood them. It took longer to diagnose a problem by reading the history than it did to let the factory’s own immune system respond.

The factory still depended on many third-party tools, but often in ways their creators had probably never intended. The codebase had become like Swiss cheese: full of holes, switches, flags, and conditional paths. Almost every core behaviour, feature, and rule was assembled only at the last possible moment, depending on the situation.

By the end of the year, Elise’s engineering team had almost entirely changed shape. They were no longer mostly programmers. They had become designers, architects, systems thinkers, and behavioural analysts.

The only surface everyone truly worked on was the specification: the set of written instructions that told the factory what mattered, what was allowed, what was forbidden, and what counted as success.

The architects and designers focused on trend forecasting and strategic partnerships. Their ideas could not be added to the specification directly. All write access went through two game theorists and a small group of statisticians, who had become the formal gatekeepers of the factory’s intent. The game theorists shaped the rules. The statisticians built the mechanisms to evaluate whether the factory’s output was actually doing what the rules intended — a distinction that had turned out to matter enormously.

Other specialists were there mostly to observe and document the game theorists. There was also an unspoken understanding that, if the game theorists began to behave strangely, someone in the room was expected to contain them.

Meanwhile, the broader internet was becoming less reliable. Large cloud platforms were going down more often. Security breach notifications had become constant background noise for every user. In response, a new class of security tools had emerged that deliberately added noise, leaks, and confusion as a defensive tactic.

Elise’s team noticed a strange rhythm in the factory’s specification changes. For a week, almost nothing would happen. Then, for twenty-four hours, the specification would light up with revisions.

The rhythm felt tidal, but wrong — as though there were two moons pulling at it.

Most of the changes were not caused by instability inside the factory itself. They seemed to be responses to the outside world: outages, market shifts, new security threats, changes in customer behaviour, or signals from other automated systems.

Around Christmas, the internet effectively died twice. The social disruption was catastrophic.

The business, somehow, continued to do well. In fact, it was growing. But it became harder and harder to explain what the business actually did.

Customers appeared through a machine-to-machine purchasing ledger. When their usage reached meaningful scale, the sales team reported increasingly bizarre conversations with the human representatives on the other side. Those people often struggled to explain what they were buying, or why. They were mostly reading instructions that had been handed to them by their own hidden factories.

Elise could not shake the suspicion that these dark factories were beginning to assemble themselves into something larger.

Not by design.

Not by anyone’s design.

But still, unmistakably, together.

NOTE – This is based on, and heavily influenced by, an article by Marek Poliks!

Enhancing AI Productivity: The Importance of Curation

Many of us have now experienced the power of AI. We have created graphics, written small programs for home automation, generated study notes for technical exams, and used AI to get real work done faster.

The productivity numbers look impressive. Output is up.

But we have also seen the other side: a 20-page PowerPoint deck clearly created from three bullet points of thought, LinkedIn posts that sound reasonable but contain no real insight, and the occasional article where the AI response was accidentally left in.

In other words: AI slop.

I have been working in an AI-native way for the last few months. I hardly ever write an email directly in Outlook anymore, and I rarely build a PowerPoint by moving objects around with a mouse. I draft in Markdown, write in VS Code, and use AI assistants to sharpen language, create variations, and help me build code for my home automation system.

One thing is clear: output goes up. But I have also learned the hard way that more output is not automatically more value. Without curation, even useful AI-generated content can become overwhelming.

I am not talking about incorrect information or low-value AI slop. Even when a document is full of value, the information density might still be too high. When you create content with AI, you have to be conscious of the audience. Is this a stand-alone document that explains a process, or is it an illustration that gives an update?

Here is a negative example: you send out five updates of a business strategy, each created with AI from your knowledge base. Each update is a dense document. Each one looks polished. But because they were generated separately, it becomes incredibly difficult for your audience to see what actually changed.

So what does this mean? We need to be much more conscious of what we create and how it will be consumed. It is easy to create good material. The harder part is helping the audience consume it.

The distinction I now think about is this: AI can create content from source material, but mature AI use means tailoring that content to the audience. You can see the difference in the example below:

Here is my way of thinking about it:

  • I start with a source file, usually a Markdown file that describes a process.
  • I can create different versions of the output with very little effort.
  • I choose the right level of detail for the audience: dense, high-level, visual, or change-focused.
  • When working with feedback, I create a version that clearly highlights what changed, often by applying the feedback directly in Markdown.

The largest problem with AI-generated content is that the information density is not obvious. A document may look polished and complete, but the reader still has to work out what is valid, what is necessary, what has changed, and what came from the creator’s actual judgment rather than from the model filling space.

That is why curation matters. It separates signal from filler.

I think of this evolution as a maturity curve. We started with manual content creation, moved into unreliable early AI output, and are now entering a new phase: AI can create reliable content, but we have not yet learned how to curate it well enough for the audience.

The principle also holds for software. Raw output is not the goal. Useful, understandable, maintainable output is.

Mature AI use is not about producing more. It is about knowing what to produce, what to remove, and how to shape the result so the audience can actually use it.

AI gives us output. Curation turns it into value.

The Email Analogy: Lessons for AI Utilization

As you can imagine as an engineer and someone who has a Masters degree in Artificial Intelligence I am super excited that AI is finally in a everyday usable state. There are many use cases for AI that I absolutely love – programming my home automation system has become better with the help of Copilot, navigating my large inbox is better with Copilot and my powerpoint presentations have much better graphics nowadays thanks to ChatGPT. It also has some downsides – one being that my son thinks my job is to create Star Wars memes for work (which made my practice townhalls a lot more entertaining). On a serious note there are several cases where AI gets it wrong and I have not found Vibe Coding to be good enough for my use cases yet, not to speak of the large amount of not useful content that is flooding my LinkedIn feed, my email inbox and any even my txt messages.

What this has shown me is that AI will really influence how we work and how we communicate and I was wondering what will we do with all the productivity we will unlock? And then remembered that all too often we don’t really use the productivity well. And I want to use a warning analogy.

Come with me into the past – It is the 1970s and we are at a business conference. I stand on stage and am pitching the next “big thing”. And here comes my pitch – There is this new technology that will create incredible productivity for you. I know many of you are sending documentation to other people in your organisation via mail or tube mail or if it needs to be very fast with a fax machine. The quality and cost of the fax machine is obviously quite limiting. Well with this new technology you will be instantantiously be able to send information at high quality for basically free to anyone anywhere. Can you imagine the productivity improvements we will see from that?!?

Of course I am talking about email which still had to go some way to live up to that promise over the next couple of decades, but the pitch and promise came true. You can send the information at high quality and basically for free and if I take email (and any equivalent capability) away from you, your productivity will drop. But ask yourself whether you feel like email is making you more productive. Or have we found ways to “eat up” that productivity by increasing the volume of emails to the point with low value information? The boat has sailed on email I think – the ongoing war of spam vs spam filters, the intentions to use less email vs the learned behaviour of checking it all the time – all this indicates that the brave new world I pitched in the paragraph above will not come of fruition.

The question I am asking myself is whether or not we will make the same mistakes with AI or whether we will find ways to truly unlock the productivity. I have spent hours with Copilot creating code for me that I could have probably written as fast myself. How can organisations focus on the productive use cases of AI and avoid the pitfalls? I don’t have an answer for this yet, but being conscious of our tendency to “eat up” the productivity that technology creates is a useful first step.