How we work in the age of AI
10 min read
Eighteen months ago, building a website feature took a developer days. Today, AI can produce something that looks like the same feature in hours. Sometimes minutes.
That speed is real. That speed is valuable. That speed is also the most dangerous thing that has ever been pointed at our infrastructure — and we are not yet moving fast enough in the right places to stay ahead of it.
This is not a criticism of anyone. Every person on this team is trying to keep up. The tools changed faster than any of us anticipated. The question isn't whether we use them — we do, we will, we should. The question is whether we build the structure underneath them before the speed causes a failure we can't recover from.
This document is the structure.
AI builds things that look finished.
That is its most valuable quality and its most dangerous one simultaneously. A page built by AI in two hours can look identical to a page built by a developer in two days. From the outside — from the porch — they are indistinguishable.
Underneath they can be completely different. One has foundations. One has the appearance of foundations. You cannot tell which is which by looking at it. You can only tell by understanding what was built and how.
This matters more for us than for most businesses because of one specific fact: all of our sites share the same infrastructure.
One failure in a connected system does not affect one site. It affects all of them. Simultaneously. On the same morning. With one person and one set of tools to fix it.
As we move from five sites to sixteen, this risk does not grow gradually. It grows exponentially. Sixteen sites on shared infrastructure, with AI-built features underneath them, without a review process, is not sixteen times the current risk. It is a categorically different kind of risk — the kind that does not give you a warning before it arrives.
We have one chance to build the right structure before the scale makes it too late to build it at all. That chance is now.
The way we build things is changing. The headless architecture we are moving toward reflects a real separation between two different kinds of work that require two different kinds of expertise.
The front end lane — the what and why: Content. Presentation. Customer experience. Commercial decisions. Marketing. Campaigns. Ideas about what we should build and why.
The technical lane — the how: Infrastructure. Backend systems. AI-generated code. Security. Deployment. Server management. The foundations that everything else sits on.
Neither lane is more important than the other. What has to stop is one lane making unilateral decisions that affect the other without going through the process that connects them.
Every idea — regardless of where it comes from, regardless of who has it, regardless of how good it sounds in a WhatsApp message at 9pm — follows the same path before a single line of code is written.
A thumbs up is not a decision. This process is how we make decisions.
Stage 1 — Idea
Someone has an idea. They share it. Informally is fine. This stage has no commitment attached to it. An idea is not a decision. An idea is not something anyone has agreed to build.
Stage 2 — Discussion
The idea gets a real conversation. Not a thumbs up. What problem does this solve? What does it cost? What does it risk? Who is affected?
Stage 3 — Proposal
If the idea survives discussion, the person proposing it writes it down. One page. What it is, why we're doing it, what it affects, what it costs, what the risk is if it goes wrong.
Stage 4 — Review
The proposal goes to the team. Everyone responds with genuine yes/no and why — not a thumbs up, not silence. This is where problems get caught cheaply.
Stage 5 — Technical Spec
If the proposal passes review, it goes to the technical lane. This is where "we want X" becomes "here is exactly what building X involves, what it touches, what could go wrong, and what the rollback plan is."
Stage 6 — Decision
The spec comes back to the team. Now everyone has the full picture. Now a real decision gets made. Go or no-go. Not before this point.
Stage 7 — Build
Only after Stage 6. Not before. Build starts when the decision is made and not a moment earlier.
Every piece of AI-assisted code — regardless of who generated it, regardless of how good it looks, regardless of how urgent the deadline — passes through a technical review before it goes anywhere near a live site.
This is not optional. This is not selective. This applies to everyone equally. AI output is a draft, not a deliverable. The review is not a bottleneck — it is the difference between a feature and a liability.
In three years, not one major change to our sites has gone live without issues. The pattern is consistent: changes are scheduled during peak trading periods on the reasoning that peak trading means maximum opportunity. The reality is that peak trading means maximum damage when something goes wrong.
From today: significant changes go live in controlled windows. Not during peak trading. The restaurant that fits a new kitchen on a Tuesday does better Saturday service than the one that fits it on Saturday morning.
When an external partner makes a recommendation — Google, an agency, a consultant — that recommendation is an input to Stage 1. Not an instruction that arrives at the technical layer ready to implement.
"The Google guys said change the breadcrumbs" and "here is what changing breadcrumbs involves across sixteen headless sites, what it touches, and what the rollback plan is" are two completely different things.
External authority makes an idea more likely to pass the process quickly. It does not replace the process.
The most dangerous four words in a technical operation are: "Can we just..."
The size of a request is not a reliable indicator of the size of its impact. A tracking pixel touches the data layer, consent frameworks, GDPR compliance, and page load speed. A text change on a template can affect every page across multiple sites.
The correct response to "can we just" is not yes or no. It is: "Let's put it in the process and find out what it actually involves."
If the process can be bypassed by the right person, the right urgency, or the right external authority — it is not a process. It is a suggestion that applies to some people some of the time.
Every idea. Every change. Every recommendation. Every quick job. Same stages. Same sign-off. Same go/no-go. Including from this document's author.
Nobody on this team caused the world to change.
AI arrived fast. The tools arrived fast. The opportunity arrived fast. Every person here has been trying to keep up, in good faith, with something that moved faster than any of us anticipated.
This document is not a verdict on how we got here. It is a map for where we go next.
The world is moving faster than we are. This is how we catch up — together, with the right structure underneath us, before the speed becomes the thing that stops us.