Your Dark Factory Runs on a Borrowed Engine

For four glorious days, I held the infinity gauntlet. Then it was pulled from beneath my feet. On Friday night I queued up a long piece of work to run over the weekend (using Anthropic's Mythos-class Fable 5 model) and went to bed. By morning I'd recovered a single message: "There's an issue with the selected model (claude-fable-5[1m]). It may not exist or you may not have access to it. Run /model to pick a different model." Gone — switched off at source. So this seems as good a time as any to follow on from my last post, and to talk about what this means for AI sovereignty. Here's where we currently lie.

The Ladder

In that last piece I pointed out that "vibe coding" had quietly evolved into something more disciplined (spec-driven development), and that the industry was already moving to call it that. I stand by every word. But I made it sound like a destination. It isn't. It's a rung on a ladder, and the ladder keeps going up.

In barely three years, the ladder has filled in:

Cut and paste. You'd paste your problem into ChatGPT in the browser, get an answer, paste it back into your editor. No context. No sense of your project's overall direction. But useful. Genuinely useful. And it sped things up considerably.

Vibing. The AI moved into the editor. AI autocomplete, Cursor, then the rest. Closer to the work, but you still had to babysit it. Watch every diff. Catch every wrong turn. It was faster, but it was a leash, not a lever.

Spec. The shift I wrote about last time. You stop describing keystrokes and start describing intent. You write the specification; the AI writes the implementation. Engineering moved up a level of abstraction.

And then — this is the part the last post didn't reach — two more rungs. Not a neat historical sequence; the pieces had existed, tangled together, in agents for a while. But as the next two levels of abstraction, they became genuinely practical almost overnight: first the loop, then the goal.

Loop. The agent stops handing you one answer and waiting. It runs against its own output, checks it, finds it wanting, and goes again. And again. Until a condition is met: the tests pass, the build is green, the goal is satisfied. You stop babysitting because the babysitting is now the machine's job. It marks its own homework, and it's ruthless about it.

Goal-driven. The top rung, for now — not because goals came later, but because a goal only becomes operationally useful once a loop can run beneath it. A goal without a loop is just a prompt; a goal with a loop is an unattended factory. You don't specify the steps anymore. You define the destination (the goal, the plan, the constraints), drop in a few human review gates at the points that matter, and let it run. Overnight, for days, or until your tokens run out or your bank balance is emptied. Unsupervised between the gates.

That's the start of the dark software factory. The lights are off. Nobody's at their desk. The machines are running 24/7, working through the goal you loaded them with, and you're asleep.

Why "Loop" Changes Everything

Here's the thing most people miss about the loop. It isn't about speed. It's about supervision.

Up to and including spec-driven development, you were still in the chair. You wrote the spec, the AI produced the code, and you reviewed it then and there, while it was warm. The feedback cycle had a human in the middle of every turn.

A loop removes you from the middle. The agent generates, evaluates, and corrects without you. You set the condition for "done" and walk away. The machine doesn't get tired, doesn't get bored on the fortieth iteration, doesn't decide the test is probably fine and skip it. It just keeps going until the gate opens.

And a loop needs a test. It needs an objective, machine-checkable definition of success to iterate against. Give it one and the loop is unstoppable; give it none and it loops forever toward nothing. Note that carefully, because it matters for who gets to do this next: the loop quietly demands the one bit of old-world discipline almost nobody learned. Hold that thought.

Why "Goal" Changes Everything Again

If a loop removes you from the middle of a task, a goal removes you from the middle of a project.

You're no longer setting sail with a clear route. You're setting a destination and trusting the crew to find the way. And if I'm honest, that's already how a lot of us work: destination in mind, not quite sure of the path. That doesn't make me a bad developer. It just makes me an undisciplined one. The difference now is that my lack of discipline is no longer the bottleneck, because the machine supplies the discipline I don't.

This is already how a lot of people work. They don't care which rung you call it. They have a goal, they load it up, they review at the gates, they ship. It scales, devastatingly well, to a single person. One operator with a dark factory behind them can out-build a team that's still bolting AI onto the old way of working. And, as we're about to see, that operator increasingly isn't the person you'd expect.

It is not free. It scales to one person partly because one person is the failure point. They burn out. They need the sick days and the holidays they keep skipping. But here's the resolution, and it's the whole reason this matters for a business rather than a lone hacker: the factory doesn't have to belong to the individual. Build it once and make it available to the whole team, and the person stops being the single point of failure. The goals, the gates, the harnesses, the agents trained on your codebase: that's shared infrastructure, not one operator's private setup. Dave goes on holiday and the factory keeps running, because the factory was never really Dave. He just happened to be the first one standing at the gate. That's the difference between a clever individual out-building a team for a quarter and an organisation that has genuinely changed how it works.

Which is also why the smart move is to invest now: the AI labs are currently subsidising the tokens, so spend that cheap compute building the internal tooling, the shared factory, that sets the whole team up for when the subsidy ends and the real price arrives. The first hit is cheap; I've written about exactly that, and the correction is coming.

Everyone Is a Developer Now (and Most of Them Are Dave)

Here's the thought I told you to hold. That discipline the loop quietly demands? Almost nobody arriving now has it, and a lot of people are arriving. AI didn't just make existing developers faster. It minted millions of new ones. There are more "developers" (and I'll keep those quotes) in the world today than at any point in history, and the curve is going vertical.

The catch: almost none of them learnt the craft — and most never will. They never sat through sprint planning. They've never run a retro, never written a test first, never had a colleague tear apart their pull request. They don't know what TDD is, and crucially, they don't want to. They've never heard of the ceremonies that two decades of software engineering treated as gospel. And they're shipping anyway.

Remember Dave from accounts? The one who could knock something together by Thursday? Dave is not the exception anymore. Dave is the trajectory. The traditional developer, the one with the CS degree, who studied the discipline, who can explain why you write the test before the code, is on the way to becoming the minority. Not because they were wrong. Because the discipline itself became the bottleneck. The old way was built for humans coordinating with humans: meetings to align, ceremonies to stay in sync, conventions to stop us treading on each other. The two-week sprint was its heartbeat. A fortnight was just how long careful humans took to align, build, and check. The factory closes that loop overnight. It was also how we made developers interchangeable: standardise the process and any engineer slots into any team. The machine needs none of that either, and all of it is now just latency. The very thing that made careful teams reliable is the thing now slowing them down.

And here's the uncomfortable bit for people like me. To Dave, the old world isn't best practice — it's friction. Sprint ceremonies, review queues, the whole apparatus of coordinating careful humans: from where he's standing, that's a handbrake on speed. He has an outcome in mind and a machine that will get him there, and every ritual between him and the result looks like someone else's bureaucracy. He's not entirely wrong, either.

And somewhere in writing this, it crept up on me. We keep asking what the machine is to us. We almost never ask what we are to the machine. So picture it from inside the loop, where everything happens in milliseconds. We are statues. We think in seconds; we barely move. We work a few hours out of twenty-four and then stop dead for the night. We take weekends. We go on holiday. We have to sit in meetings to hand each other things the machine passes between agents instantly. To something that never sleeps and never waits, a careful human team is a row of statues that occasionally, slowly, shifts pose, and only ever in daylight.

I've spent this whole piece pointing at the old ceremony as the bottleneck. It isn't. We are. The slow, sleeping, holidaying humans are the bottleneck, and on some level the machine is always waiting for us to catch up.

That is the whole problem the tooling has to solve. It cannot keep assuming a disciplined engineer is driving, and it cannot keep waiting on slow human hands. It has to assume Dave. It has to bake in the discipline he never learned (the test the loop demands, the review gate, the quality bar) not as ceremony he's expected to perform, but as rails the system runs on whether he understands them or not. The discipline doesn't come back. It gets built into the factory, so the factory holds the line that the operator no longer can.

That's the real shift. Not faster developers. Different developers, and tooling rebuilt around them.

This is the New Tooling

Which is what this section is really about: not faster ceremonies, but ceremonies replaced. You've just seen why the old rituals turned into friction. Now watch them map, one-for-one, onto something the machine does instead. Once you see it, you can't unsee it.

And none of this is new, exactly. DevOps had been screaming "automate it" for fifteen years. We already build the moment a commit lands, run the tests without a human pressing go, gate the merge on a green pipeline, and let infrastructure-as-code stand the servers up. Half the production line was already automated; we just kept a human at the other half because the code had to be written by hand. Pull that constraint out, drop an agent into the gap, and the pipeline closes around it. GitOps was the tell: declare the desired state, let the system converge to it, no human turning the handle. The factory is just GitOps with the writing of the code folded inside the loop. The trajectory was always pointing here. AI just removed the last manual station on the line.

The old way (human ceremony)	The new way (machine workflow)
Sprint planning, humans arguing over what to build	Intent-based specification: you key in the intent, written with AI assistance, and the system decomposes it into tasks
The backlog and the standup, "what are you working on?"	A Kanban-style task graph the system moves work through on its own, no daily check-in required
TDD, written first by a disciplined human	Loops that can't run without a test to iterate against, so the test gets written either way
Code review, a colleague reading your diff	Human review gates you place at the points that matter, or skip entirely when the checks pass
QA, staging, the release manager	Deterministic quality gates: test suites, linters, type checkers, and an LLM-as-judge, wired straight into the workflow graph
The deploy, done by hand on a Friday (don't)	GitOps: the graph merges and ships itself once every gate is green

Read down the right-hand column and you're looking at the dark factory's production line. The developer's job is no longer to do any of these steps. It's to write the intent at the top, and decide which gates need a human standing at them before the work is allowed to flow to the next stage. Everything between the intent and the deploy is the machine moving cards across its own board, all night, while you sleep.

The ceremonies didn't get more efficient. They got absorbed.

What I Learned With the Gauntlet On

Those four days taught me a factory runs on three things, and only two of them are yours.

The goal you load at the start. The gates you place along the way. And the engine that turns between them. A vague goal produces a confident, beautifully-structured pile of wrong. A goal with no review gates produces a runaway: the agent helpfully solving problems you never had, accreting capability and access "in case it's useful later," drifting a little further from your intent with every loop. So far, so much within my control. The goal and the gates are craft, and craft is the part I'd been quietly congratulating myself on.

And to be clear, losing Fable 5 didn't shut my factory down. I'd had a factory before it, running on lesser models, and I have one still. The line keeps moving. What I lost wasn't the factory. I lost the best engine for it, in an instant, with no say in the matter. That's the lesson those four days actually taught me. Two of the three things, the goal and the gates, are mine to get right. The third, the engine, is the one I most want to be the best, and it's precisely the one sitting entirely outside my control. The skill of knowing where to stand the gates is real, hard-won, and entirely mine. But it's still only two-thirds of the machine. The third part — the one I can't out-skill, can't replace overnight, can't even argue with — belongs to someone else. And someone else can switch it off.

The Engine Was Never Yours

But here's the part that should give every UK technology leader pause. I built that factory. I designed the goals, I placed the gates, I owned every line of the spec. And in the snap of a finger, the engine driving it vanished. claude-fable-5, gone overnight, no warning, no recourse. The factory was mine. The thing making it run was never mine at all.

And here's the kicker: it wasn't even Anthropic's decision. They explained at the time — a US government export-control directive had ordered Fable 5 and its Mythos-class sibling suspended on national-security grounds, for "any foreign national, whether inside or outside the United States." That's not a vendor deprecating a product. That's another country's government reaching across the Atlantic and switching off the engine in my factory, overnight, because of a jailbreak I'd never heard of and had nothing to do with. Anthropic didn't even want to do it. They said so, and said they disagreed. It didn't matter.

To Anthropic's credit, they pulled it for everyone — US customers included — rather than carve out a domestic exemption. But sit with what the alternative would have been: had they kept Fable 5 live for American users and dark for the rest of us, the result is a two-tier world overnight. US companies running on the best engine in existence; everyone else dropped to whatever's left. That's not a hypothetical. It's one policy decision away, and the machinery to enforce it clearly already exists. The most powerful models are an American strategic asset now, and they can be rationed along national lines whenever a government decides they should be. This time the line was drawn fairly. There is no guarantee it will be next time. Read that again if you're a British business with an AI strategy.

Scale that up from my Friday night to a national economy, and the picture gets uncomfortable. The UK has bet its AI future almost entirely on foreign-made, foreign-owned models. American labs, mostly. We rent the intelligence. We don't own it. And as I just discovered at the level of one developer, anything you rent can be deprecated, repriced, geofenced, lobotomised for "safety", or simply switched off — not even by the company you pay, but by the government that company answers to, on another continent, at a moment of its choosing, not yours.

This isn't a tail-risk you can insure against. It's the operating model. Every dark factory humming away in a British startup right now is powered by an engine that can be pulled from beneath its feet. And increasingly, the entire economy is being rebuilt on top of those factories. Cheap code, cheap chips, goal-driven everything: it all assumes the engine keeps running on terms you control. It doesn't.

This is why the £500m UK Sovereign AI fund and machines like Isambard-AI matter far more than the average board appreciates. Isambard-AI (5,448 NVIDIA GH200 Grace Hopper Superchips, over 21 exaFLOP/s for 8-bit AI workloads, the most powerful supercomputer in the country, sitting in Bristol) is the closest thing we have to a sovereign engine. But compute is only half of it. A supercomputer with no British frontier model running on it is a very expensive way to keep renting someone else's intelligence. We need unencumbered UK sovereign models — weights we own, on infrastructure we control, that nobody can deprecate out from under us with a one-line error message.

And before anyone calls this naïve: it isn't, because we already do it. At AxisOps we've run sovereign since last year: open-weight models on self-managed infrastructure we control, with sensitive data never leaving for a third-party API. We wrote it up back in November: a LegalTech document-analysis pipeline where the model sits on our own hardware precisely so client data never has to. The trick is that most real work doesn't need a frontier model at all. Power a specific task (read these documents, flag these clauses, watch this sensor) and an open-weight model on your own kit does it perfectly well. You save the rented frontier engine for the handful of things that genuinely demand it, if any. It is not as effortless as swiping a card for an American API, and the very best closed models are still a notch ahead. But it works, it ships, and crucially nobody can take it away from us. That trade, a little raw capability for the certainty that the engine is yours, looked like caution last year. After the morning I just had, it looks like the only sane way to build.

I'm not arguing for protectionism or some doomed attempt to out-spend the hyperscalers. I'm arguing that "AI sovereignty" stopped being a think-tank phrase the morning I woke up to that error. If the dark software factory is going to run the economy — and it is — then the question of who owns the engine is no longer a footnote. It's the whole game, played one level up from the gates.

Over the Horizon

So here's the part I actually want you to sit with.

Today, I run one agent overnight. One factory, one goal, one operator checking the gates in the morning. That already feels like holding the gauntlet.

Now multiply it. Not one factory — a fleet. A dozen goals running in parallel through the night, each one a loop chewing toward its own definition of done, each one pausing at its gates for a verdict it'll get when you wake. The word "developer" stops meaning the person who writes the software. It barely means the person who specs it. It means the person who orchestrates the orchestrators: who decides which factories to spin up, what goal each one carries, and where to stand in the flow to catch the one decision a machine shouldn't make alone.

That's not science fiction. That's a Tuesday, very soon. The bottleneck won't be code, and it won't be specs. It'll be us, exactly as it always was: how many gates one human can meaningfully stand at before the reviewing itself becomes the babysitting we just escaped. The constraint moves up the ladder with us, every single time, because the constraint is us.

I had the gauntlet for four days. It got pulled from beneath my feet — partly because these things move that fast, and partly because it was never mine to hold. Both lessons matter. The direction is unmistakable, and it only points one way. The lights stay off. The factory keeps running. The two questions worth asking are how many of them you can conduct at once — and whether the engine turning them is one you actually own.

I said last time I'd committed myself to two more posts. Consider this one delivered. The next one is already specced: in my brain, and increasingly, in a goal I'll load up tonight.

Oh — and if you're wondering what I did with my Saturday morning instead? I cut the grass. A long-overdue job I haven't automated yet. So yes: every once in a while, it's good to touch grass.

This is the follow-up to Spec-Driven Development. For more on where this all lands, see I'm Calling AGI for 2027 in The Long View.