From first boat to fleet.
Adopting AI with control.
Seven chapters on taking AI from demo to production without losing your quality, your compliance position or your nerve. Nothing here is from a course. It comes from running the transition on myself: five months operating a one-man AI factory — 4,751 commits, 14 solutions — on top of 18 years leading regulated IT programmes. The scars are included; they’re the useful part.
The water — what AI actually is, in operation.
Everything written about AI falls into two piles: what it does in a demo, and what it does in operation. The first pile is enormous and mostly useless. This playbook is about the second.
In operation, AI behaves like a gas: it fills any room you give it, regardless of the room’s size — but it cannot hide how thinly it’s spread. Ask for more than it can carry and it doesn’t refuse; it produces something that resembles the work, at full confidence, in perfect prose. That single property — fluent output at constant confidence — is the root of nearly every AI failure you will meet.
Which leads to the discipline underneath everything else in this playbook — the refusal of false speed:
False speed is producing output before you understand the direction.
False speed is building because you can.
False speed is an AI trying to help by doing more than it was asked.
Real speed appears when the work is narrow, the direction is clear, and the quality can be verified.
“Make haste slowly” is not a plea for caution. It’s a performance principle: every hour spent on unverified output is slower than any hour spent on gates. The organisations that will win with AI aren’t the fastest producers of output. They’re the fastest producers of verified output. That’s a different race, and most of your competitors haven’t noticed it’s the one being run.
The first boat — how to actually start.
Here’s how my factory started, because the pattern transfers. First I built for myself — my own website, one week after touching the tools for the first time. Then for one person I knew, with a real need. Then three more. Small, real, shipped. Somewhere in those first builds came the discovery that shapes everything after:
The first paying delivery followed the same shape: a named person, a real need, a minimal build. Not a platform. Not a strategy. A working thing, in the hands of someone who needed it, fast enough to learn from. That triple — named person, real need, minimal build — is the most reliable filter I know for a first AI project, and it works at organisational scale too.
So, the practical start — three rules and one warning:
- Pick a use-case with a face. A named user who feels the pain weekly beats an abstract “efficiency opportunity” every time. If nobody specific wants it, nobody specific will defend it.
- Build the smallest thing that survives contact with reality. Pilot with improvised speed — that’s what it’s for — but decide in advance what evidence will justify the rails that production demands.
- Install the quality reflex on day one, not day ninety. One rule is enough to start: no output is trusted because it sounds right. Everything else in chapter 3 grows from that seed.
- The warning: the moment your pilot impresses management, it will be pulled toward production by enthusiasm alone. That is precisely the moment to stop and put rails on — the pull is strongest exactly when the structure is weakest.
The rails — enforcement, not encouragement.
Everything I’ve learned about AI quality compresses into one sentence: a rule that only lives in a document is not a rule — it’s a pious hope. Guidelines describe what agents should do. Gates determine what they can do. Only the second category survives contact with production pressure.
The factory runs on four mechanical controls: proof of source access (an agent gets no credit for “analysing” what it can’t show it opened), artifact-based doneness (the explanation is not the deliverable), adversarial review (a reviewer mandated to refute, not applaud) and unknown = blocked (uncertainty is a state, never a gap to fill with text).
And one line from the factory’s spirit document that belongs on your architecture wall:
Every control must be able to actually stop something — block a merge, refuse a status, halt a deploy. A control that can only recommend will be politely ignored by humans and completely ignored by machines.
Full depth: the four controls and ten real failure patterns are published in detail in The Hallucination Defence, and the chain of command — dispatch contracts, evidence packs, human GO/HOLD — in The Workshop.
The crew — your AI needs an org chart.
The best mental model I’ve found for a well-run AI is not a servant, and not an oracle. It’s a sous-chef. A servant waits for orders. A sous-chef sees what the kitchen is missing before the dish tips over — understands the principal’s taste, says no when the tempo turns stupid, watches risk without panicking, presses for quality without taking over the stage.
And one sous-chef is not a crew. The factory’s hardest-won organisational lesson: roles must be written as authority, not personality. An architecture role that sets boundaries. An implementation role that builds inside them. A verification role that checks claims against artifacts. An adversarial role paid to break things. No role — ever — ratifies its own work. It’s segregation of duties, the same principle that separates your auditor from your bookkeeper, applied to machines. I learned it by violating it: the worst failure in my factory came from asking one agent to wear seven hats and then asking it to hurry.
The full story: One agent, seven hats — why your AI needs an org chart. And the model in operation: The Workshop.
The storms — what you will meet, catalogued.
Your AI initiative will not fail in a novel way. It will fail in one of about ten known ways — I’ve met them all in live operation, and published the catalogue: plausible analysis without source access, done-inflation, drift under pressure, too many hats, plausible synthesis, stale-state reporting, the visually false green, authority smuggling, hidden deviations, and internal leakage into public output.
The point of a failure catalogue isn’t pessimism — it’s preparedness at a discount. Each pattern has a known symptom, a known root cause and a known mechanical countermeasure. Meeting them with the defence already standing costs a fraction of discovering them one production incident at a time.
And a hiring hint hidden inside it: ask any AI vendor or advisor to show you their failure catalogue. If they can’t, they haven’t run long enough to have one — whatever their deck says.
The full catalogue — ten patterns, each with symptom, root cause and countermeasure: The Hallucination Defence.
The economics — what actually changes.
The honest headline: build-cost collapses; everything around the build doesn’t. From the factory’s own ledger: a webshop problem that had consumed 45,000 kroner of external consulting was resolved in one evening. A product suite that would classically be quoted at 75,000+ kroner reached a production MVP in a fraction of the classical timeline. This site — interactive tools, CI pipeline, the lot — was rebuilt in days, not months. The factory itself was self-funded from consulting income; no venture capital, no forcing function, no burn-rate drama.
But — and this is the part the AI vendors’ decks omit — the cost didn’t disappear. It moved. It moved from writing code to verifying it. From building to specifying. From production to judgment. The scarce resource in an AI-era organisation is not build capacity; it’s the person who can define what “good” means, detect when confident output is hollow, and say no. Budget for that person, that time and those gates — they are the actual cost of AI, and they’re a bargain at the price.
Plan with this asymmetry: pilots are nearly free now. Production still costs. The trap is treating the pilot’s price tag as a forecast — it’s the rails, the verification and the operating model that carry the real budget, exactly as they should.
The chart for 2027 — what to do now.
My working thesis, stated plainly: the 2024 labour market logic is dissolving. What one person with a governed fleet of agents can deliver already overlaps most of what small teams delivered two years ago — I’m typing this from inside the proof. By 2027 there will be a market for one-person factories and AI-native operators that barely exists today, and every organisation will be buying from it, competing with it, or becoming it.
You don’t need to bet on my timeline. You need to be positioned either way — and the positioning happens to be identical to plain good practice:
- Build the reflex before the fleet. An organisation that can verify AI output can safely adopt anything that ships in 2026, 2027 or 2028. One that can’t is unsafe with today’s tools, never mind tomorrow’s.
- Run one honest pilot to production this year. Not for the ROI — for the organisational learning. The first delivery teaches you your own failure patterns while the stakes are small.
- Treat governance as the durable asset. Models will be replaced every year; your rails, your evidence discipline and your people’s judgment compound. Invest accordingly.
- Keep the ambition honest — and high. The factory’s own bar, in its founder’s words: we’re not building a soapbox car. Quiet competence, not hype — but aimed at something that matters.
And the last word — the advice I’d give the unemployed consultant who opened an AI tool for the first time in January, which is also the advice for any organisation standing at the edge of this water: start smaller than feels impressive, verify more than feels necessary, and begin now. I threw paint at a canvas because I didn’t know better. A picture emerged. I’ve painted over it a hundred times since — but I know what I’m painting now. So will you. The only approach that reliably fails is waiting for the water to calm down. It won’t.
Seven chapters is a map. You still need a pilot on board.
I help organisations run exactly this playbook — from the first honest pilot to the rails, the crew and the operating model. Interim or freelance, via broker or direct.