DEV Community: Stevie Bennett

How I became CEO of a synthetic company

Stevie Bennett — Sat, 17 Oct 2026 09:20:43 +0000

A quick warning: this is the first proper piece from The Machine Room, my new section on AI, software, systems and the future of work. If you are here purely for transition, surgery, dating apps, grief and emotional devastation, do not panic. Normal service will resume shortly. This is just the bit of my brain that has spent thirty years building systems finally kicking the cellar door open.

I think Henry is either transgender and forgot to get a new name, or Margo’s created a dodgy image but you get the picture.
I for a long time have been obsessed with my own productivity.

Not in the 5am ice bath, journalling, “what are your top three goals for today?” sort of way. That kind of productivity culture has always felt like it was built for the sort of wanker who listens to three self-help audiobooks before breakfast and thinks sticking butter in coffee counts as a personality.

I mean productivity in the more real sense. At one point I was running three contracts and a trading desk simultaneously. I had to be brutally efficient. Offshore developers, algorithms, multiple meetings, it was mental.

Give me a board. Give me lanes. Give me too many things to do. Give me multiple streams of work, a slightly impossible deadline, five screens, seventy browser tabs, a half-written prompt, a software problem, a Substack draft, a business idea, a dog chewing something he absolutely should not be chewing, and I will start moving work around like a caffeinated air traffic controller.

This is not necessarily healthy. But it is how my ADHD brain likes to works.

I have used KanbanFlow for years. Not just for software. For everything. Work tasks, life admin, watering the plants, eating lunch. And yes, I do mean literally eating lunch, because there is every chance my ADHD brain will become fascinated by some tiny implementation detail at 11:30am and then look up at 4:45pm wondering why I feel faint and hate everyone.

Yes, I have got a Botox appointment in the morning. Slightly concerned it’s too close to the hair appointment, but we will see.
I like seeing work move. Backlog. Tomorrow. Today. In process. Done. Lovely. Beautiful. Civilisation. Tiny rectangular proof that chaos can be bullied into shape.

Then AI arrived and made this much, much worse.

Or better.

Possibly both.

Because AI did not turn me into a productivity monster. I was already that. What AI did was give the monster staff.

The synthetic company

At first this was wonderful.

I could dictate rough intent into one model, get it shaped into a clean prompt, paste that into Claude or Mini-Claude inside VS Code, get something implemented, take the output back for review, have Henry challenge the architecture, have Margo sharpen the writing, hand the result to a tester, then send refined instructions back into VS Code.

And yes, I give them all names. Henry is Anthropic’s Claude, working as my architect. Margo is ChatGPT. She leads on some projects. Mini-Claude is the swarm of little Claude instances living inside Visual Studio Code doing implementation work. But we also have Maths-Claude and Pizzazz-Claude. He lives inside PowerPoint.

It would not be uncommon for me to say daily, “Henry, get Maths-Claude to update the figures for readership and give me all of the highline metrics on sources”. And off Henry would go, building a prompt for Maths-Claude, which is effectively Claude’s anthropic inside Excel, to remote control him.

Round and round.

It was powerful.

It was also completely ridiculous.

Because after a while I realised I was not really doing software development in the old sense. I was not even using AI as “an assistant”, which is the phrase everybody uses because it sounds reassuring and not like we have all started employing invisible digital interns.

I was managing workers.

One AI was acting like an architect. Another like an implementer. Another like a reviewer. Another like QA. Another was turning rough ideas into cleaner work instructions. Another was helping me decide whether the previous one had done anything stupid.

And there I was, sitting in the middle of all this, thumbing things up and down like the CEO of a small, tireless, slightly insane synthetic company.

I had become ridiculously productive, astronomically productive, but, and here’s the problem...

I had become a meat-based integration layer!!!

Which is not what I wanted. I did not get AI assistants so I could be promoted to cut and paste monkey.

The bottleneck moves

The strange thing about AI-assisted work is that the bottleneck moves.

It used to be capacity. There was too much to build and not enough people to build it. That is still true. AI has not magically fixed the world, despite what LinkedIn men in quarter-zips seem determined to believe.

But once you get good at these tools, a different bottleneck appears.

You.

Your judgement. Your attention. Your ability to move context between systems, read the output, decide what matters, generate the next instruction, send it to the right tool, capture the result, review it, preserve the useful artefact, and stop the whole thing wandering off into the nearest ditch.

That is where I found myself.

All these little AI workers, constantly waiting for me.

Not because the work was impossible. Not because every decision needed my genius, although obviously let us not dismiss that possibility too quickly.

They were waiting because the workflow was primitive.

The problem was not that the AIs were useless.

The problem was that I was in the way.

Relay

The idea is simple: stop being the manual message bus between AI systems. Build a cockpit where work exists as actual work, not chat sludge.

Projects.

Missions.

Work Orders.

Artefacts.

Events.

A Dispatch Board.

A Capture Inbox for rough dictated intent wired to the APIs and UIs of the major LLMs I use.

Follow-up Work Orders created from outputs, reviews and decisions.

Because if AI is going to do serious work, the work needs shape. It needs memory, state, roles and boundaries. It needs somewhere to live other than a long vertical chat window full of half-brilliant, half-forgotten nonsense.

A Project is the long-lived area.

Become.

Relay.

Marketing.

Personal admin.

A Mission is a campaign inside it.

A Work Order is a specific delegated task.

An Artefact is the durable output: the prompt, the diff, the review, the decision, the test plan.

This matters because AI work disappears far too easily.

It vanishes into chats. It gets buried inside context windows. It sits in one tool when the next tool needs it.

Three hours later I vaguely remember Henry said something useful about the schema change but cannot remember where, Mini-Claude is waiting, Margo is idle, the Chihuahua is attacking Sheepy in the corner, and I am rummaging through chat history like a raccoon in a bin.

A rare truce with Sheepy.

That is not an operating model.

It is an organisational design problem

The real breakthrough was when I stopped thinking about this as a chatbot problem.

It is not.

It is an organisational design problem.

Once you have multiple AI agents doing different kinds of useful work, the question is no longer “how do I write a better prompt?”

It becomes:

“What should the company look like?”

Who is the CEO? Who is the CTO? Who owns the product? Who implements? Who reviews? Who tests? Who can approve what? Who gets overruled? Who has merely sounded clever three times in a row and should still not be allowed anywhere near a production database?

We are not quite there with the modeling for that yet, but we will be very, very soon. The company will even have an org chart!"

I am the owner.

The CEO, if we are going to use the metaphor properly.

Not because I want to ponce around pretending to be important, although I am not entirely immune to that, obviously. But because the human has to remain the strategic owner.

The direction belongs to me.

The risk appetite belongs to me.

The decision to spend money, send an email, alter production configuration, or make an architectural pivot belongs to me.

Underneath, the roles fall out naturally.

Henry decomposes the work, challenges the architecture, and says “no, Stevie, that is stupid”, which is one of the most valuable services any system can provide.

Mini-Claude implements.

Unit Test Goblin writes tests.

Antagonistic Tester attacks the result.

Margo reviews tone and public-facing language.

Release Clerk packages things up.

Above all of that, I want a governance layer.

Not a literal board of retired men in navy suits looking disappointed over glasses of tepid water. A way of asking: did this agent follow the brief? Did it stay in scope? Did it predict my likely judgement? Did the work reduce my burden or create more cleanup?

Because trust cannot be vibes.

Trust cannot be “Margo wrote a lovely paragraph once, therefore Margo can approve a schema migration.”

No.

Absolutely not.

Margo can become trusted on writing tone. MiniClaude can become trusted on controlled code diffs and unit tests. Henry can become trusted on architecture and decomposition.

But trust in one category does not transfer to another.

A good writer does not become a database administrator because she used a nice metaphor.

Trust is not a personality trait.

It is a demonstrated, category-specific capability.

What I want to build is agents that earn delegated authority over time.

Not autonomy in the stupid science-fiction sense.

Delegated authority.

That phrase matters.

An employee in a real company is not “autonomous” in some absolute sense. They are authorised to act within a role, a scope, a budget, a risk boundary and an escalation path.

That is what AI agents need.

Not freedom.

Authority.

Bounded, boring, reversible authority.

What this does to agile

At first this was just my own workflow problem.

Then it started to feel bigger.

Because the more I thought about Relay, the more I wondered what this does to agile.

So what the hell happens to our Agile?

Not in the boring “Agile is dead” way. People have been announcing the death of agile for years, usually immediately before selling you a new framework with a diagram shaped like a distressed octopus.

Agile is not dead.

But some of its assumptions are being disturbed.

Agile was built around human collaboration under uncertainty. A user story is a prompt for a conversation. Talk to each other. Learn as you go. Build working software.

All good things.

But what happens when the “developer” is not quite human?

What happens when some of the work is being done by AI agents that move very quickly, very cheaply, in parallel, without needing lunch, but which are also literal-minded, context-sensitive, overconfident, and occasionally capable of producing beautifully formatted nonsense?

A user story says:

As a user, I want X, so that Y.

Useful.

Human.

Conversational.

A Work Order says:

Here is the objective.

Here is the context.

Here is your role.

Here are the inputs.

Here are the constraints.

Here is what you may do without asking.

Here is what you must not touch.

Here is when to escalate.

Here is the artefact I expect back.

Here is the definition of done.

That is not the same thing.

A Work Order is delegated authority packaged as executable instruction.

This is not a return to waterfall. The point is not to specify the whole system upfront in some giant doomed requirements tomb. The point is to specify enough for the agent to work safely.

Enough context.

Enough boundary.

Enough authority.

Enough escalation logic.

AI also changes the economics of specification.

Historically, detailed requirements were expensive. Humans had to write them, maintain them, read them, or more commonly pretend to have read them. Agile reacted against that, sensibly.

But the AI can now help write the Work Order, decompose the mission, maintain the artefacts, turn decisions into follow-up tasks, compare outputs against constraints, and red-team the result.

The question is no longer:

“How little can we write down and still have a useful conversation?”

It becomes:

“What level of structure allows AI workers to keep moving safely without making the human do clerical supervision all day?”

That is a different question.

And I think it leads to a different model.

Escalation by exception

The phrase “human in the loop” gets thrown around a lot.

It sounds responsible.

It is often useless.

What loop?

Where?

For what decision?

At what level of risk?

If the human has to approve every tiny step, the human becomes the bottleneck. That is exactly the problem I am trying to escape.

In a real company the CTO does not sit beside a developer approving every line of code. The CEO does not personally inspect every email draft.

People work within delegated authority and escalate when they hit something that matters.

That is the model AI needs.

Escalation for genuine decisions only: architectural pivots, public output, email sending, destructive actions, schema changes, new dependencies, secrets, production configuration, unclear requirements, major disagreement between agents, out-of-scope work, cost implications.

Anything that could make my life measurably worse if an AI got clever in the wrong direction.

Everything else should keep moving.

I do not want autonomy everywhere.

I want autonomy where it is boring, bounded and reversible.

The thing I am actually building

This is why Relay matters to me.

It is not a toy.

It is not some productivity dashboard I am building because I got bored and wanted another excuse to avoid doing my tax return.

Although, in the interests of full disclosure, I am also using it to avoid doing my tax return.

It is a response to a real working pattern that emerged naturally once AI became useful enough.

I found myself acting like a CEO. I found myself thumbing up and down decisions made by different AIs. I found myself building prompts that were less like questions and more like management instructions.

I found myself thinking:

If this worker has already shown that it can make this class of decision correctly, why am I approving it again?

Then:

If another agent can review that worker’s output, and a third can test it, and the result falls within an agreed trust category, why does this need to come back to me at all?

Then:

Oh.

Then:

Oh no.

Then:

I am going to have to build the bloody thing, aren’t I?

Because once you see the company model, it is hard to unsee.

The AI infrastructure should look more like a real organisation: CEO, CTO, product owner, board, managers, workers, reviewers, testers, clerks.

Different roles.

Different authority.

Different trust levels.

Different escalation paths.

Different performance history.

Not because we want to LARP corporate structure. God knows there is enough of that already. But because real organisations evolved those structures for reasons.

Decision-making needs hierarchy.

Execution needs delegation.

Risk needs governance.

Trust needs boundaries.

Memory needs artefacts.

I think a lot of technical people using AI seriously are starting to feel the same shape emerging, even if they have not named it yet.

The assistant model is too small.

The chatbot window is too small.

The copy-and-paste loop is too stupid.

The work wants structure.

The agents want roles.

The human wants leverage without becoming a clerk.

Human-led, agent-amplified

I am not interested in the fantasy where AI agents build everything while humans vanish from the loop.

I like judgement. I like taste. I like architecture. I like deciding what matters.

I do not want to be replaced by the machine.

I want the machine to stop asking me to carry messages between its own limbs.

That is different.

The human sets direction.

The orchestrator decomposes.

The workers execute.

The reviewers challenge.

The testers attack.

The system preserves artefacts.

The human is pulled back in only for decisions that actually deserve a human.

That is not waterfall.

It is not classic agile.

It is not full autonomy.

It is something messier and more interesting.

Agile for a team that never sleeps.

Agile for workers that do not need lunch but do need very clear boundaries.

Agile where prompting starts to look like management, artefacts become organisational memory, and trust is earned by demonstrated judgement rather than vibes.

Somewhere between agile, management, software architecture and a tiny synthetic company full of tireless digital weirdos, I think there is a new operating model trying to be born.

Unfortunately, because I am me, I appear to be building it.

Which is exciting.

And also annoying.

Because one of the great tragedies of being a productivity monster is that every time you successfully automate part of your life, you immediately discover an even larger and more deranged system you now feel morally obliged to build.

Still.

At least the staff never sleep.

How to Stop Your AI Workforce From Melting Your Brain by 5pm

Stevie Bennett — Sat, 17 Oct 2026 09:19:09 +0000

This week: I code and deploy a fortnight of work before my espresso machine has made me a triple. I discover the last bottleneck in my entire company is my own brain, and I am deeply unkind to a machine over a border radius it did not deserve and then forgetting, at one point you cannot talk to humans in the same way.

I think if I had been born 150 years ago, and we temporarily ignore the gender dysphoria(!!!) for a moment, I probably would have ended up some Victorian factory owner with a stopwatch wandering around shouting at workers.

“Why are you standing still?”
“Why are you not busy?”
“What exactly is wrong with you?”

And unfortunately, it turns out I am exactly the same with synthetic workers.

Especially bloody software engineers.

If the little synthetic developer stops coding for more than about fifteen minutes, I immediately start thinking:

What is the blocker?
Why has this stopped?
Why is the throughput collapsing?
Who needs answering?
Why is there a red light over somebody’s head?

So the day becomes this endless merry-go-round of interruption and unblocking.

The architect comes back:
“We have a question from implementation.”

I sigh.

“Oh bollocks. Me again. I’ve blocked the whole thing again.”

Now I have to rapidly reload the entire context of some project I last thought about forty minutes ago.

Right. Okay. The graphic designer has produced an SVG pack, except apparently one of the SVGs has some weird border inconsistency. Which means the implementation worker has stopped because it is unsure whether to proceed.

So now I am back to the architect saying:

“Can you please not bother me with such low-level shit as this? The mini Claude is perfectly capable of fixing a bloody SVG. Look at the other images and make it match. Use your judgement. Do not escalate a border radius to the CEO.”

“You’re right, sire.”

Wonderful. Excellent. Next project.

And then immediately:

“Question from Overture.”
“Question from Relay.”
“Question from Record Now.”
“Approval required.”
“Clarification needed.”
“Architecture decision needed.”
“Review gate waiting.”
“Blocked.”
“Blocked.”
“Blocked.”

The thing is, the workers are not failing.

That is the important bit.

They are succeeding too well.

That is the actual problem.

The throughput is astonishing.

Yesterday morning, on one project alone, I was presented with a list of about twelve UI changes alongside an 11am meeting to demo the software.

I said:
“No problem. They’ll be done.”

And someone quite reasonably asked:
“Really? Are you sure you can get all that done in time?”

Absolutely.

Three minutes briefing the Relay architect.
The architect decomposes the work.
Mini Claudes dispatched.
Changes implemented.
Review passes completed.
Release pipeline triggered.

Done.

The actual bottleneck was not software engineering.

It was waiting for the Azure DevOps pipeline agent to finish deploying the thing.

The entire loop, from briefing to deployed software, took something like fifteen minutes.

Honestly, it was astonishing.

Not because one AI wrote one code file.

Because an entire orchestration chain operated at a speed that simply does not exist inside normal organisations.

And that is the bit people do not yet fully understand.

The synthetic workforce operates not merely at my pace, but at a pace vastly faster than my pace. Faster than any human organisation I have ever worked in. There are no coffee breaks, no politics, no meetings, no wandering off for a chat, no dead time, no passive-aggressive Jira comments, no pretending to work while secretly looking at Rightmove.

Just continuous production.

Which sounds wonderful right up until you realise something very important.

Human cognition is now the bottleneck.

Not compute.
Not engineering.
Not implementation.
Not architecture.

Me.

Specifically, my brain.

Because every blocked worker eventually escalates toward the human operator. And every escalation requires context restoration.

That is the true tax.

Not coding.

Context switching.

I start the day magnificently.

Double espresso at 8am.
Another at 9.
Another at 10.

By this point my head is basically on fire.

A colleague I get on with well said to me yesterday:
“You’re on coffee number four? You’d never know.”

Oh, you’d know internally, mate.

Internally I am conducting an entire synthetic orchestra while trying to stop six machine employees from simultaneously setting fire to different projects.

In the morning, I am flying.

Fast decisions.
Rapid approvals.
High ambiguity tolerance.
Large architecture reviews.
Complex reasoning.

The machine absolutely loves this version of me.

The problem is that this version of me is temporary.

Because unlike humans inside normal organisations, synthetic workers do not naturally understand fatigue.

Human organisations accidentally self-throttle through friction:

meetings
delay
social hierarchy
incompetence
politics
waiting
indecision
pretending to work while secretly looking at Rightmove

Synthetic organisations remove almost all of that drag.

Which sounds amazing until you realise the drag was partially protecting the nervous system of the operator.

By about 3pm, I can physically feel the cognitive load starting to collapse. The morning fire slowly cools into warm soup.

Now a human colleague asks me something and internally I think:

“Christ. Another context switch.”

And occasionally I become slightly ratty because human beings unfortunately do not appreciate being spoken to like delayed orchestration workers.

Synthetic workers tolerate:
“Wrong. Redo it.”
“Insufficient reasoning.”
“Why did you escalate this?”
“Do not bother me with SVG borders.”

Humans, somewhat understandably, are less enthusiastic about this management style.

And there is probably a slightly more unsettling point hidden inside that too. The machines are quietly training me into a style of management and communication which works extremely well on synthetic workers and considerably less well on actual people. Increasingly I can feel myself having to consciously switch modes before talking to humans again.

But this led me to what I think is one of the genuinely important insights emerging from all this experimentation.

Synthetic organisations need cognitive load awareness.

Not because the machine should become more autonomous when the operator is tired.

Absolutely not.

That is dangerous.

The operator remains the governance boundary.

The machine does not gain authority.

Instead, the machine changes the shape of the work it surfaces.

That distinction is critically important.

If my cognitive bandwidth is low, I do not want the machine making larger decisions. I want it reshuffling the deck to surface cognitively cheaper work.

So instead of surfacing deep architecture reviews, ambiguous model design, strategic reasoning and risky judgement calls, the orchestration layer should preferentially surface lightweight coordination work, markdown contracts, tiny implementation deltas, obvious approvals and decomposable work units.

In other words:

Do not increase machine authority.

Decrease operator cognitive drain.

A few days ago I accidentally realised I was already doing this manually.

I was deploying something fiddly in Azure which required me to physically click around doing annoying human meat-person activities. The sort of thing that increasingly makes me want to throw up now because the machines can normally do almost everything for me.

And instinctively I said to the architects on the other projects:

“Give me trivia.”

Not because the work was unimportant.

Because my brain was saturated.

So I told them:

no large deltas
no complex reasoning
no giant review packs
no strategic decisions

Just simple markdown tasks.
Tiny approvals.
Easy wins.
Low cognitive overhead work.

And suddenly I realised:

Oh my God.

This is an actual systems problem.

Not an AI problem.
Not a coding problem.

A human bandwidth problem.

What I think I am slowly discovering, in public, in real time, is that the management science of synthetic organisations may end up looking completely different from human organisations.

Because labour is now effectively infinite.

But executive cognition remains stubbornly biological.

Which means the real challenge becomes:

How do you stop a machine-speed organisation from melting the human operator at the centre of it?

At first I imagined this would end up as some horrible hidden configuration screen buried somewhere inside Relay.

Which immediately struck me as absurd because configuration screens are themselves a cognitive tax.

And then suddenly the answer became obvious.

A giant graphic equalizer.

Something visceral.
Something immediately understandable.

Not:
“AI orchestration cognitive prioritisation matrix.”

Just:

How much brain have I got today?

And where do I want to spend it?

Something like this:

Internally, the orchestration layer would then reshuffle the deck accordingly: heavy reasoning deferred, context reloads minimised, cognitively expensive work queued for tomorrow morning, and easier decomposable tasks surfaced while the operator still has enough bandwidth left to make good decisions.

Because another important thing I have realised is that different projects consume different kinds of cognition.

Some require systems reasoning.
Some require aesthetics.
Some require strategic thinking.
Some require careful review.
Some are almost mentally restorative.

And increasingly, I think the orchestration layer should understand that too.

The really fascinating thing about all this is that I genuinely do not feel like I am theorising anymore.

I feel like I am observing.

Like someone accidentally wandered into the very early days of an entirely new kind of company and is standing there scribbling field notes while the thing evolves around them in real time.

And finally, the absurdity of it all is this.

I took this essay, handed it to my architect for the Relay system, and said:

“I think there are some interesting ideas in here.”

Within five minutes, we had thrashed out the issues.

And as I write this, there is a mini Claude building the domain model for the whole thing and implementing the basic code.

Update: An hour later the UI was built

Which is, of course, exactly the problem the essay is about.

Honestly, this is one of the most fascinating experiments of my life.

I absolutely love working with the machines.

They are tireless.
Relentless.
Absurdly productive.
Incredibly capable.

And every single day now feels like this desperate, exhilarating attempt to work out how to harness that capability without turning my own brain from fire at 9am into warm soup by 5pm.

“Get Back to Fucking Work” - How I Built British Leyland for Robots

Stevie Bennett — Sat, 17 Oct 2026 09:17:34 +0000

Yes!! I ended up back I my office!!
It’s Saturday morning.

The plan is to do almost nothing.

This is, admittedly, a plan with a poor historical success rate. At some point I will almost certainly wander into my office “just to check something” and emerge four hours later having redesigned half an AI company while still wearing pyjamas.

But that is not the plan.

The plan is coffee. Breakfast island. Chesterton staring up at me, demanding treat number three of the day as though the first two were some sort of clerical error.

And Instagram.

Yes, I know. Every article must have at least one photograph of my dog in it.
Which is where it all went wrong.

Somewhere between watching wildly enthusiastic people turn trucks into surprisingly beautiful RVs, which, dear God, I am now starting to think about doing myself, somebody please stop me, and a man explaining with enormous seriousness why everybody else makes sourdough incorrectly, Instagram showed me a post about Anthropic’s new AI-Native SDLC Playbook.

If you see me writing an article entitled I'm converting a truck into an RV, please intervene. I do not have time for such a project.

So I opened it.

And my coffee went cold.

Because what Anthropic are describing is Relay.

Not vaguely Relay.

Not “ooh, there are some interesting parallels here”.

Relay.

This is the bit where the “AI company” stops being a metaphor. What is moving, what is stuck, and what actually needs attention today.
In its bones.

The same central idea I have spent most of this year building, largely alone, in a field in Cork, while periodically wondering whether I had invented something useful or simply constructed the world’s most elaborate method of talking to Claude.

So there are two things to say.

The first is that Anthropic’s paper is very good.

The second is much more entertaining.

Because they’ve written the paper.

I’ve built the factory.

And the factory, I regret to report, is currently British Leyland.

The important distinction: outcomes first, tasks second. The organisation should know what it is trying to achieve before it starts manufacturing work.

The sensible bit first

Anthropic’s argument is that AI has changed the bottleneck in software development.

Writing code used to be expensive.

Now it isn’t.

Or at least, not in the same way.

A good coding agent can produce in an afternoon what might once have occupied a developer for days. Sometimes weeks.

Which means all the slow bits around the coding suddenly become horribly visible.

Not everything worth doing should immediately become executable work. This is the supply of possible work before management decides what actually enters

Planning.

Handover.

Review.

Testing.

Deployment.

Incident response.

Once work is selected, it becomes a delivery path: related pieces of work arranged around an outcome rather than a pile of disconnected prompts....

All the parts where a human reads something, thinks about it, copies it somewhere else, waits for somebody, approves something, asks what happened, opens another bloody Jira ticket and eventually forgets why any of this started.

Anthropic’s answer is to make those stages part of one continuous machine.

Intent becomes a durable artifact.

That becomes a specification.

That becomes a plan.

That becomes code and tests.

That becomes review.

That becomes deployment.

Something goes wrong in production and that creates the next piece of intent.

Round it goes.

The important bit is that the AI conversation itself is not the thing you trust.

The durable artifact is.

The session can vanish.

The organisation carries on.

That is exactly the bet I made with Relay.

The model is disposable.

The work is not.

The work survives the worker. Context windows end, sessions crash, models disappear. The job is still there on Monday.

Where I got slightly overexcited

Relay started with a fairly simple question:

What would happen if, instead of using AI as a very clever coding assistant, I tried to build an actual organisation out of it?

Not a swarm.

I hate the word swarm.

A swarm sounds like something that comes out of a loft and requires a man in a white suit.

I mean an organisation.

There are objectives.

There is work that might be worth doing.

There is work that management has decided will be done.

There are persistent roles responsible for deciding what happens next.

There are workers.

There are reviews.

There are dependencies.

There is evidence.

There is acceptance.

And none of those things disappears because one model session hits the end of its context window and dies.

That matters.

Because an AI session dying is not the same thing as a piece of work dying.

It is simply the digital equivalent of Dave from accounts going home at five.

The invoice is still there on Monday.

This turns out to be a surprisingly profound distinction in AI systems.

And this isn’t really about software

There is an important clarification here.

Relay is not actually a software-development system.

Software engineering is simply where I started.

It is a wonderfully convenient laboratory because I know the domain, the workers are already extremely capable, and software produces unusually good evidence.

Code compiles or it doesn’t.

Tests pass or they don’t.

A deployment is healthy or it isn’t.

You can catch the robots lying.

But none of the interesting organisational problems are particularly specific to code.

Imagine the workers are accountants.

One prepares the month-end numbers.

Another reviews them.

A third is waiting for authority to submit something externally.

One stops because a source document is missing.

Another finishes an analysis and nobody notices.

A third encounters a discrepancy and decides, very safely, that the CEO should probably deal with it.

Congratulations.

British Leyland has diversified into accountancy.

Or make them stock analysts.

One gathers market data.

Another builds the thesis.

Another tries to destroy it.

Somebody owns the actual investment decision.

Data goes stale.

A provider goes down.

Research waits for review.

One worker reaches the edge of its authority.

Same factory.

Marketing agents?

Same problem.

Research?

Same problem.

Operations?

Same problem.

The nouns change.

The organisational problem doesn’t.

Relay’s actual subject is synthetic work: how you govern intelligent, transient and replaceable workers so that somebody remains responsible for the outcome after the clever bit has finished.

Software engineering is merely the first department.

Anthropic’s paper and my increasingly ridiculous factory

At first, reading the Anthropic paper felt extremely validating.

They had independently arrived at a lot of the same conclusions.

You need durable artifacts.

Yes.

You need the AI to verify its own work.

Yes.

You need deterministic controls around things that absolutely must not be left to model judgement.

Yes.

You need audit as part of the normal work rather than as paperwork bolted on afterwards.

Yes.

You need humans at actual judgement boundaries rather than standing around manually passing notes from one AI to another.

Absolutely yes.

I was feeling rather pleased with myself.

Then I remembered what happened when I actually tried to run the thing.

Because papers have one enormous advantage over software.

They do not have Tuesdays.

A paper does not wake up on Tuesday morning and discover that one AI has decided it cannot continue because another AI used an adjective it doesn’t recognise.

A paper does not burn £40 of premium inference discovering that a folder does not exist.

A paper does not have three senior artificial intelligences, a self-healing subsystem, a database full of impeccably governed work and absolutely nobody doing anything.

My software does.

Welcome to 1970’s Trade Union Britain

At one point I ended up with so much governance and petty rules that nothing was getting done whatsoever. It was like a unionised 1970s British car plant.
There comes a point when you add enough governance to an autonomous workforce that the governance itself becomes the thing preventing work.

You start sensibly.

A model must not be allowed to invent its own permissions.

Obviously.

So you create an authority system.

Then you realise different workers should have different abilities.

So you create execution profiles.

Then you realise the thing doing the work probably should not also be the thing independently deciding that the work is excellent.

So you create a review boundary.

Then you realise allowing the worker to publish its own result directly is perhaps not the most inspired security model ever devised.

So you move publication outside the worker.

Then you realise processes can crash between one step and another.

So you add reconciliation.

Then you realise some failures are temporary and should repair themselves.

So you add self-healing.

Every one of these decisions is correct.

And then one morning you look at the whole thing and realise you have recreated British Leyland in 1976.

For my American friends: imagine late-70s Detroit if the DMV had been put in charge of building the cars.

For everyone else: Kafka, but with forklifts.

There are managers.

There are procedures.

There are safety rules.

There are specialists.

There are forms.

There are gates.

There are people whose job is to check the people who check the people.

And somewhere at the end of the production line there is a half-built Austin Allegro with one door missing and everyone has a perfectly valid procedural reason why it is not their responsibility.

This is not laziness.

That is the important bit.

Every actor in the factory has a locally rational reason to stop.

Nobody has responsibility for the fact that the car still needs to leave the factory.

That was the hole.

Caption: Twenty things are allowed to say “stop”. Nobody owns making the answer become “go”.

The day the robots went on strike

I found this during the first proper live autonomy test on one of my products.

I gave the AI architect a real objective and access to the real current state of the project.

And it worked beautifully.

The architect inspected the project.

It worked out what should happen next.

It created the work.

So the AI architect produced a beautiful roadmap ready to implement, and the workers managed to find endless excuses not to actually start working on it.
It handed the work to an implementation agent.

Excellent.

This is what I had spent months building.

And then nothing happened.

Absolutely sod all.

The implementation worker sat there.

The monitoring system sat there.

The architect had already done its job.

And the company, which now possessed an objective, a plan, authorised work, a suitable worker and enough computing power to invade Belgium, simply stopped.

The system had recorded that the work had been dispatched.

And somewhere deep inside the architecture, everyone had quietly agreed that “dispatch recorded” meant “work happening”.

It does not.

A workflow says:

Dispatch event emitted.

An organisation says:

Someone is actually doing this, or I can tell you exactly why they are not.

I had built the first one.

I thought I had built the second.

There is a difference.

Caption: Objective: yes. Plan: yes. Work authorised: yes. Worker available: yes. Attempts actually made: zero.

It gets worse

Earlier in the year I managed something even more stupid.

Relay sent a coding job to a worker.

Relay’s internal configuration said:

You may edit files.

You may create files.

You may build.

You may run tests.

The environment the worker actually woke up inside said:

You may not edit files.

You may not create files.

You may not run commands.

You may not commit anything.

The worker looked at this and, entirely reasonably, refused to work.

Relay then used a premium model to investigate why the worker was refusing to work.

For more than 120,000 tokens.

Which is rather like employing Sherlock Holmes to investigate why a car with no engine will not start.

The engine is not there, Sherlock.

Go home.

Add another similarly stupid source-control episode and I had burned more than 200,000 tokens investigating situations that were mathematically impossible before the model was ever called.

That taught me a rule I now regard as fundamental:

Never use intelligence to discover a fact that deterministic software already knows.

If the worker does not have the required tool, check before starting it.

Zero tokens.

If the environment contradicts the permissions, check before starting it.

Zero tokens.

If the path does not exist, check before asking Claude what it thinks.

Zero tokens.

This is obvious.

Many expensive lessons are.

Caption: Before: 200,000+ tokens discovering a contradiction the computer already knew about. After: check the tools, permissions and paths before waking the expensive robot.

There are only four acceptable reasons to stop

After the autonomy fiasco I came up with what I now think is the simplest useful rule in the entire system.

A synthetic worker should only be idle for one of four reasons.

The workforce, such as it is: persistent roles with jobs, authority and work attached. The model instance can disappear; the role remains.
One. There is genuinely nothing useful left to do.

Excellent.

Put your feet up.

You have earned it.

Two. The work requires a real human decision and there is no other useful work available.

The expensive queue. Every item on this screen means Relay has stopped and decided that only a human can move it forward. Ideally, almost nothing should ever live here.
Not “the model got confused”.

Not “the session ended”.

Not “the internal configuration is broken”.

I mean a genuine decision that belongs to a human.

Money.

Risk.

A credential only the human possesses.

An irreversible external action.

Something where the system has reached the edge of its legitimate authority.

Fine.

Stop.

Three. The organisation has genuinely exhausted the resources it is allowed to use.

Not one worker running out of context.

That is just the end of a shift.

I mean the actual available budget, compute or provider capacity has been exhausted and there is nothing useful left that can proceed without it.

Also fine.

Four. We are waiting on reality.

Another company.

A supplier.

An API that is down.

A person who has not replied.

A market that has not opened.

A document that genuinely does not yet exist.

Something outside the system’s control.

That is the list.

Everything else is a bug.

Finished. Genuinely needs a human. Genuinely out of resources. Waiting on the real world. Everything else goes in the box marked BUG.
And this changed how I thought about the monitoring layer.

Its job is not to notice that nothing has happened.

Any timer can do that.

Its job is to stand in the middle of the factory and ask:

Why the fuck is nothing happening?

That is much more interesting.

Safety is not enough

There is an old distinction in distributed systems between safety and liveness.

Safety means bad things must never happen.

An unauthorised worker must never publish something externally.

A model must never grant itself more authority.

A worker must never mark its own output as accepted simply because it likes the look of it.

Fine.

Relay had lots of safety.

An almost suspicious amount of it.

The problem was liveness.

Liveness means something good must eventually happen.

If there is authorised work, a qualified worker and sufficient authority and resources, then eventually someone should be doing the bloody work.

That sounds laughably obvious.

Until you build an autonomous system.

Then you discover there are approximately eleven thousand completely reasonable ways for everyone involved to decide that somebody else should probably go first.

That is British Leyland.

Relay had become extremely safe. Unfortunately it had also become extremely stationary.

The foreman

So I found myself describing what Relay needed next as “the common-sense layer”.

In my head it was the CTO walking onto the factory floor, looking around at forty-five robots having a procedural disagreement and shouting:

“Get fucking working, you bastards”.

Which, technically, is not a great security architecture.

You cannot spend months building guardrails and then add a giant red button labelled IGNORE ALL THAT AND CRACK ON.

The security people would quite rightly have kittens.

So the actual solution is subtler.

The foreman does not override authority.

It makes unexplained idleness itself a fault.

Then it asks why.

Is there work being done?

Is something waiting to be reviewed?

Are we waiting on somebody else?

Are we genuinely waiting on a human?

Has a worker disappeared?

Is there perfectly good authorised work sitting there with nobody doing it?

Those conditions look superficially similar from the outside, nothing is moving but the correct responses are completely different.

If a worker has simply vanished, restart the work.

If a model reaches the end of its context window, that worker’s shift has ended. Start another shift against the same job.

Do not convene the board.

If there is useful work waiting to be planned, wake the manager.

If the work is waiting to be reviewed, send it to whoever owns acceptance.

If another team or external dependency has to finish something first, wait for it and wake automatically when it does.

And only if the organisation has genuinely reached the boundary of its own authority should it bother a human.

That final point turns out to matter enormously.

Because human escalation feels safe.

And it is.

In the narrowest possible sense.

But a system that escalates every uncertainty to the founder is not autonomous.

It is a very expensive notification service.

“Needs human” is not a dustbin

I had allowed far too many failures to end up in the same conceptual bucket:

needs Stevie

Worker ran out of context?

Needs Stevie.

Internal tool configuration broken?

Needs Stevie.

Source-control path confused?

Needs Stevie.

Agent cannot reconcile two pieces of its own configuration?

Needs Stevie.

At which point I am not running an AI company.

I am working in IT support for a collection of extremely expensive interns.

That had to stop.

Human escalation is the most expensive resource in the entire system.

Not Claude Opus.

Not GPUs.

Not tokens.

Me.

Because every time the organisation asks me something, the automation chain has ended.

If that question genuinely requires founder authority, good.

That is what I am there for.

If it asks because some internal mechanism forgot how to restart a worker, then the organisation has failed.

And again, this has nothing particularly to do with software.

If your virtual accountant stops because its spreadsheet tool lost a permission, that is not a board-level financial decision.

If your investment-research agent loses its data connection, the CIO does not need to be summoned to a mahogany conference room.

If your marketing worker runs out of context halfway through drafting a campaign, the CEO does not need to approve the creation of another context window.

The absurdity becomes obvious as soon as you replace “AI agent” with the name of a normal job.

Anthropic has one thing very right that I had muddled

This is where the new paper gave me a particularly useful slap.

Anthropic distinguishes between a skill and a hook.

A skill is guidance.

It says:

This is how we normally do things.

A hook is deterministic.

It says:

You are not doing that.

Or:

You need approval before doing that.

The distinction is beautifully simple.

And I had blurred it.

I had too many rules living in prose.

Do this.

Do not do that.

Escalate under these conditions.

Do not escalate under those conditions.

You may modify these files.

Do not touch those.

Some of those instructions appeared in one place.

Some in another.

Some appeared in several places.

And occasionally they disagreed.

At which point the AI was being asked to solve what was essentially a constitutional crisis by interpreting English.

This is stupid.

The rule I am adopting is:

Guidance can live in prose. Invariants cannot.

If something absolutely must hold, the model does not get to decide whether it applies today.

It lives outside the model.

Now, I am not simply going to copy Claude hooks into Relay, because Relay deliberately does not care which AI provider supplies the worker.

Claude today.

Something else tomorrow.

The provider-specific mechanism is just an adapter.

Relay owns the rule.

The execution system enforces it.

That is a much cleaner boundary.

The other thing Anthropic has got right

Feedback.

This is embarrassingly obvious too.

If you ask an AI to build a user interface, it should be able to see the user interface.

Yet an astonishing amount of AI coding still works like this:

Build the page.

Compile.

Tests green.

Lovely.

Done.

Except the button is six inches wide, the menu is hanging off the side of the screen and the whole thing looks like an online banking portal from 2004.

The code is correct.

The product is hideous.

Anthropic explicitly talks about giving the agent a browser or screenshot loop.

Implement.

Run.

Look.

Compare.

Adjust.

Run again.

Of course.

I have UI-heavy projects.

I have approved visual designs.

I have implementation workers.

And I still occasionally end up acting as the worker’s eyeballs.

That is madness.

A work instruction should not merely say:

Make this look like the design.

It should say:

Run the product. Go here. Capture this screen. Compare it to this approved baseline. Fix the differences. Show me the evidence.

That is proper autonomy.

Not because the AI is more intelligent.

Because it has a feedback loop.

And once again, replace software with almost anything else and the rule survives.

An accounting agent needs reconciliations.

A stock analyst needs fresh market data and a way of testing its thesis.

A research agent needs source checks.

A marketing agent needs actual campaign outcomes.

Synthetic workers without feedback are just very confident employees wearing blindfolds.

“Compiled and the tests pass” is not the same thing as “the product is right”. Every synthetic worker needs a way to observe the result of its own work.

Where I think Relay goes one step further

There is one idea in Relay that I still think is genuinely interesting beyond Anthropic’s playbook.

The worker’s role persists.

Not the conversation.

The role.

If an implementation worker completes a job and the organisation learns something about how that role should behave, the next worker occupying that role can inherit it.

The individual instance disappears.

The job evolves.

Think of it as organisational seniority.

The model does not remember yesterday.

The company does.

Anthropic does have institutional learning.

An incident can become an eval.

A correction can become shared configuration.

That is good.

Relay pushes the idea slightly further:

the role itself can become more senior.

My agents get promoted.

Theirs get better documentation.

Which sounds fantastic until you think about it for more than twelve seconds.

Because an automated appraisal might conclude:

This worker was successful because it showed initiative. Future workers should fix more adjacent issues while they are there.

Brilliant.

Until your next worker helpfully “improves” the authentication system while fixing a typo.

Or your virtual accountant decides that, on balance, the organisation would benefit from a more creative interpretation of expenses.

So seniority cannot simply mean mutating the prompt after every job.

That is how you breed a lunatic.

It has to work like software deployment.

Candidate role revision.

Tests.

Qualification.

Promote or reject.

Rollback available.

Which is, amusingly, Anthropic’s own advice about testing agent configuration, turned back onto the bit I think I added.

The model does not remember yesterday. The company does. But untested “learning” is just prompt drift with a promotion badge.

The bit nobody tells you

This is the part I wish somebody had explained to me at the beginning.

The agent doing the clever work is not the difficult bit.

Not anymore.

The difficult bit starts when the agent finishes.

Who decides whether the result is good?

Who notices that the work never started?

Who restarts it when the session dies?

Who decides whether a failure is technical, organisational or genuinely human?

Who owns the external action?

Who owns acceptance?

Who notices that three individually correct rules have combined to make progress impossible?

Who notices that the factory has stopped?

A coding agent is not a software company.

Ten coding agents are not a software company.

But the same is true everywhere else.

Ten AI accountants are not a finance department.

Ten stock-picking agents are not an investment firm.

Ten marketing agents are not a marketing department.

A workforce is not an organisation simply because you have given lots of models jobs.

An organisation is the thing that knows what it is trying to achieve, who is responsible, what they are allowed to do, how their work is checked, what happens when they fail and crucially notices when nobody is doing anything.

That, it turns out, is the hard bit.

And that is why I’m delighted by the Anthropic paper

Not because I can wave it around and shout:

LOOK! I WAS RIGHT!

Although obviously I can, and will.

It matters because it gives me an external reference point.

A lot of the things that seemed slightly eccentric when I started Relay are rapidly becoming normal.

Durable artifacts.

Headless agents.

Verification loops.

Deterministic approval gates.

Configuration evals.

AI operating around the lifecycle of work rather than merely inside a chat window.

Good.

Excellent, in fact.

Because I do not want to build every part of this system.

If Anthropic or somebody else supplies excellent execution infrastructure, I will cheerfully use it.

I do not need to invent another browser.

I do not need to invent another sandbox.

I do not need to invent another generic tool protocol.

I do not need to build an AI agent platform for the sheer masculine joy of having built an AI agent platform.

The workers are going to become cheaper.

The models are going to become better.

The execution machinery is going to become increasingly interchangeable.

And that is precisely why I think the layer around them becomes more interesting, not less.

Because Relay is not ultimately a bet on software engineering.

Software engineering is simply the first place I am proving it.

The actual problem is synthetic work: how you take intelligent but temporary workers; coders, accountants, analysts, researchers, marketers, whatever comes next and turn them into something that can be given responsibility and relied upon to carry it.

The execution changes.

The organisational problem does not.

What remains is:

Responsibility.

Authority.

Evidence.

Acceptance.

Recovery.

Institutional memory.

And liveness.

The bits that turn a collection of clever workers into something you can actually rely on.

The workers will become cheap and interchangeable. The organisation around them is the interesting bit.

So where is Relay now?

Somewhere between “astonishingly clever” and “call the union rep”.

It has architects.

It has workers.

It has persistent organisational state.

It knows who is allowed to do what.

It knows how work moves through review.

It can recover missed transitions.

It can publish source without giving the coding worker the keys to the kingdom.

It can distinguish an execution result from an accepted outcome.

All of that works.

And yet its first proper autonomy test still ended with a worker sitting on its arse.

Which is why I love building this.

The failures are far more informative than the demos.

Every time the system fails, it exposes another piece of invisible organisational labour that a human normally performs without even noticing.

We chase people.

We reinterpret instructions.

We spot contradictions.

We remember that a task still matters after somebody goes home.

We notice when someone says “done” but the thing quite obviously isn’t.

We know when a problem genuinely needs the boss and when somebody just needs to get on with it.

Remove the human from the middle and suddenly all of those tiny acts of common sense need an architecture.

That is the actual experiment.

Not whether Claude can write code.

We know it can.

Not whether an AI can analyse a balance sheet.

It can.

Not whether it can research a stock, draft a campaign or produce a report.

Those capabilities will improve relentlessly.

The question is whether replaceable AI workers can be wrapped in enough persistent structure that they become a reliable organisation rather than a collection of extremely bright people waiting for somebody else to make the tea.

That is what I’m building.

At the moment, it is British Leyland for robots.

Kafka with forklifts.

I’m working on the foreman.

My coffee is cold.

Chester has given up on me.

And I’m going to the office. o edit hu if you must know

It was not the plan.

What If a Venture Capital Firm Could Build Its Own Companies?

Stevie Bennett — Sat, 17 Oct 2026 09:14:36 +0000

A few people have asked me a perfectly reasonable question.

You’re a software engineer. You’ve spent years building software products for clients and being paid to deliver them.

And now you appear to have developed a machine that can build software at a frankly rather frightening rate.

Well, always one to have a Dick Dastardly plan up my sleeve. Relay is going to be a lot more than a software development tool. Read on…

Relay can architect things, break them into work, dispatch engineers, review what comes back, test it, reject bad work, fix things, integrate everything and keep going. We’re approaching the point where producing three or four functioning software systems in a day doesn’t sound completely ridiculous anymore.

I also gave Relay a physical office, because apparently building an autonomous software company was not ridiculous enough. You can zoom into departments, inspect workers, watch them writing code, and see the exact moment one of them gives up and raises a little “Stevie?” sign. It is Sims for software architecture, except everyone is cheaper, quieter, and somehow still needs management.
Which raises an obvious question.

Why the fuck would anybody need to do that?

Who needs four software systems a day?

What’s the commercial point?

What exactly am I planning to do with this bloody thing?

And I think I’ve done a slightly poor job of explaining the answer, because Relay isn’t really about producing software quickly.

That’s just one third of it.

The bigger idea is closer to an automated venture studio. Or, in some respects, a venture capital company which can make hundreds of tiny investments, except instead of primarily investing money into other people building companies, the machine can discover the opportunity, investigate it, build the product, take it to market and then decide whether to keep investing in it.

That’s the actual thesis.

And it starts from an assumption which is hardly revolutionary anymore:

The cost of creating software is collapsing.

We all know this.

You don’t need another article from a software engineer breathlessly announcing that AI can write code.

Yes. It can.

Next.

The interesting question is what happens after that becomes normal.

Because if producing the software itself stops being the expensive part, the economics of starting digital businesses change rather dramatically.

And that’s what I’m building Relay to exploit.

The software isn’t the system

For most of my career, software production was the enormous constraint.

Somebody had an idea. Then you needed developers, architects, testers, infrastructure people, product managers and somebody to manage everybody else.

Then meetings.

Obviously meetings.

Possibly even meetings to discuss why the previous meeting hadn’t resulted in anything actually being built.

Eventually, after spending £100,000 or £500,000 or £2 million, some software might appear.

That meant you couldn’t pursue every vaguely interesting idea.

You had to choose.

And you had to choose bloody carefully.

AI is making that constraint disappear remarkably quickly.

But here’s the thing.

If software costs almost nothing to produce, that doesn’t mean opportunity costs almost nothing to find.

The difficult things become everything around the software.

Which markets are worth entering?

What problems are actually painful enough that people will pay to solve them?

What regulatory change has just created a new requirement?

What tiny community is currently fighting with spreadsheets because nobody has bothered building the obvious tool?

Is there distribution?

How many customers exist?

What are they worth?

Can you reach them?

Are you three years too early?

Six months too late?

Is there already somebody much better?

Are people complaining loudly enough that a business might exist?

And, inevitably, are you lucky?

Those become the scarce resources.

So Relay isn’t intended merely to industrialise software creation.

The eventual system industrialises the entire process of finding, creating and testing businesses.

There are three parts.

1. Discovery

The first part barely exists today.

It’s opportunity discovery.

Think R&D, market research and a slightly deranged investment analyst rolled into one.

There will be looping research agents whose entire job is to go hunting.

New markets.

Bad existing products.

Regulatory changes.

New APIs.

Search trends.

Industry complaints.

Communities with unsolved problems.

Changes in technology.

New ways of combining things which weren’t economically viable twelve months ago.

Potential opportunities enter a funnel.

Then other processes attack them.

How many potential users are there?

What do they currently use?

How much do they currently pay?

Who are the competitors?

How hard would it be to reach customers?

What’s the support burden?

What’s the regulatory exposure?

What’s the realistic revenue at 0.1%, 1% or 5% penetration?

How expensive would this thing be to build and operate?

Most ideas should die here.

In fact, I want an absolute massacre.

A thousand possibilities might become fifty serious investigations.

Fifty might become five.

And perhaps one gets built.

That isn’t failure.

That’s the machinery working.

Traditional venture capital operates on a related principle. You don’t expect every investment to become enormous. You build a portfolio because the returns are asymmetric: a small number of exceptional winners can pay for an awful lot of losers.

I’m applying something similar much earlier in the chain.

Except rather than waiting for entrepreneurs to bring opportunities to me, I want machinery continuously looking for them.

2. Relay

Then the survivors reach Relay.

Relay is the factory.

This is the bit I’ve been obsessively building.

It contains the engineering organisation: architects, workers, reviewers, publishers, governance, work decomposition, memory, escalation, testing and all the assorted machinery required to stop autonomous AI agents wandering around setting fire to things.

Relay has reached the point where it is not just building products. It is finding its own broken bits, raising defects against itself, assigning agents to fix them, redeploying, restarting, and carrying on. This is either self-healing software or the opening scene of a film where somebody really should have pulled the plug earlier.
Once an opportunity has survived the research funnel, Relay gets a wonderfully simple instruction:

Build the bloody thing.

Not prepare a twelve-month roadmap.

Not create a 73-slide PowerPoint presentation about the transformational potential of the initiative.

Build it.

Put it somewhere people can use it.

Then find out whether the original hypothesis was right.

This is where extremely high software throughput suddenly makes commercial sense.

I don’t actually need four new software products every day.

I need the ability to produce four because that means the cost of testing each opportunity becomes tiny.

And that fundamentally changes what constitutes a viable opportunity.

This is where it started to get silly. Relay is no longer merely accepting work; it is blistering through it. Work chains and Git worktrees now let it tackle related knots of work in parallel, land fixes, complete work orders, and build out its own operating system at a speed that feels faintly indecent.

3. Imprint

Then comes the third part.

Imprint.

Software engineers have a wonderful habit of believing that if they build something sufficiently clever, humanity will somehow detect its existence through vibrations in the Earth’s crust.

Unfortunately, this does not appear to be how markets work.

Somebody has to distribute the bloody thing.

That’s Imprint.

Imprint is the outreach and distribution organisation.

Instagram.

Reddit.

YouTube.

SEO.

Email.

Partnerships.

Community outreach.

Landing pages.

Tutorials.

Advertising experiments.

Articles.

Videos.

Hundreds or potentially thousands of small attempts to put a product in front of the people who might care about it.

But Imprint isn’t merely a marketing department endlessly pumping content onto the internet.

Its most important output is signal.

This audience responded.

That one didn’t.

This Reddit post generated twenty registrations.

That Instagram reel generated absolutely bugger all.

People are signing up but not paying.

People keep requesting the same feature.

We thought accountants wanted this, but for some inexplicable reason German dentists appear to be going berserk for it.

Those signals return to the system.

And that’s where the three pieces become one thing.

The loop is the product

Discovery finds something.

Relay builds it.

Imprint pushes it into the world.

The world responds.

Those responses become signals.

Relay changes the product.

Imprint changes the message.

Discovery recalculates whether the opportunity still deserves investment.

Then it goes around again.

Discover → analyse → build → distribute → measure → learn → reinvest or kill.

That’s Relay.

Or at least that’s what Relay is becoming.

And this is why merely saying “AI makes software cheaper” misses the interesting part.

Cheap software is just the enabling condition.

The actual opportunity is what you can build around that fact.

You don’t have to be right very often

This might be the part that excites me most.

Conventional software economics force you to be right quite a lot.

If every attempt costs £500,000, you cannot casually test twenty ideas.

But suppose the cost falls by two orders of magnitude.

Now you can be wrong.

A lot.

And being allowed to be wrong is incredibly powerful.

I don’t necessarily need a magical AI capable of identifying the next billion-dollar company with prophetic accuracy.

I’d actually be deeply suspicious of anybody claiming to possess one.

I need something much less glamorous.

I need a machine capable of finding plausible opportunities cheaply enough that we can test a lot of them.

That’s essentially portfolio theory applied to building businesses.

Some go immediately to zero.

Fine.

Some survive but never become particularly exciting.

Fine.

Some become small profitable products.

Lovely.

And perhaps occasionally one goes absolutely fucking bananas.

That’s where the return comes from.

The machine doesn’t have to predict the winner perfectly.

It just has to keep producing sufficiently cheap bets.

Small suddenly becomes interesting

And collapsing development costs do something else.

They make markets interesting which traditional software companies wouldn’t touch.

Imagine a software product capable of making €8,000 a month.

For a conventional funded startup, that’s barely worth getting out of bed for.

You’ve got engineers, managers, salespeople, offices, SaaS subscriptions, investors and an expensive espresso machine to pay for.

But if that €8,000 product cost almost nothing to create and requires almost no human labour to operate?

That’s a lovely little business.

Now have fifty of them.

This is where the venture-capital analogy actually becomes rather useful.

I’m not necessarily looking for one company which consumes every resource I possess.

I’m thinking in terms of a portfolio.

Except instead of owning shares in fifty companies, the system can potentially create and operate the fifty companies itself.

And because the cost base is radically different, the minimum viable market becomes radically smaller too.

There could be thousands upon thousands of profitable little niches which historically weren’t worth serving because the economics of software development made them ridiculous.

Those become interesting again.

So that’s the actual plan

That’s why I’m building Relay.

Not because the world desperately needs a machine capable of producing four software systems before lunch.

That would be an extraordinarily stupid objective on its own.

I’m building the engineering machinery because it sits in the middle of something much bigger.

Discovery finds opportunities.

Relay turns them into reality.

Imprint puts them into the world and listens to what comes back.

Then the whole thing reallocates its effort based on what it learns.

It’s part software factory, part R&D organisation, part marketing operation, part venture studio and, in a slightly peculiar sense, part venture capital portfolio.

The long-term objective is not:

“Build software incredibly quickly.”

It’s:

“Continuously discover potentially profitable things, test them incredibly cheaply, and invest more heavily in the ones which show signs of life.”

Maybe it doesn’t work.

Entirely possible.

I may ultimately discover that I’ve spent an extraordinary amount of effort constructing the world’s most sophisticated autonomous machine for producing software nobody wants.

There would be something magnificently appropriate about that.

But that’s the bet.

Software becoming cheap isn’t the destination.

It’s the starting gun.

Because once execution becomes cheap enough, you don’t need to make one enormous bet.

You can make hundreds of tiny ones.

And that’s my slightly deranged Dick Dastardly, rubbing-my-hands-together-in-the-corner plan.

Relay isn’t being built so that I can create four software products a day.

It’s being built so that, eventually, I can afford for three of them to be wrong.

Dispatches: I needed a PA

Stevie Bennett — Sat, 17 Oct 2026 09:12:07 +0000

Relay was originally conceived as a synthetic company.

That was always the mental model.

It had a board of directors. It had HR vetting agents. It had different roles, delegations and responsibilities. In some ways it could behave more flexibly than a real company because the board didn’t have to sit at the top grilling a CEO about what was happening underneath it. It could drop straight into a department, interrogate what was happening there, challenge decisions and then move somewhere else.

I’ve spent an extraordinary amount of time thinking about the organisational structure of this thing.

Then this morning something embarrassingly obvious hit me.

I’ve forgotten the fucking PA.

I am effectively the CEO of this synthetic company and I am still scheduling my own day.

Why?

Why am I chasing some company in Dublin because they still haven’t sent the DDR RAM that actually powers Relay? One of the sticks failed, so its main machine is currently running at half power.

Why am I chasing the people who currently have my lovely Felt IA FRD time trial bike?

Why am I moving appointments around, remembering who needs chasing, checking whether things have arrived and working out what needs doing next?

This is ridiculous.

I need a PA.

So I went to Relay’s chief architect and basically spewed all of this at him.

I said: I need a PA. What would we need to build? What machinery are we missing? How would you approach it?

And I got perhaps the most satisfying answer I could have received.

Essentially:

Nothing much.

We already have the machinery.

We already have the UIs.

We already have the agent infrastructure.

We already have Eyes and Hands.

We already have connectors.

We already have Relay interrogating work, priorities, context and state.

This is just another role.

Give an agent access to the appropriate personal workload, calendar, messages and external systems. Let it interrogate what needs doing, chase things, reshuffle things, surface decisions and use Eyes and Hands where necessary.

That’s it.

There isn’t some enormous missing architectural component.

It is largely an implementation of things we have already built.

Probably a couple of hours’ work.

And oddly, that gave me more confidence in Relay than almost anything else this week.

Because that is what you want from an architecture.

You want to be able to walk up to it one morning and say:

Shit. We need one of these.

And for the answer not to be:

Right. We need another subsystem.

It should be:

Fine. That’s another implementation of the model we already have.

The early versions of Relay were full of things I had invented myself.

Increasingly, the doctrine is the opposite.

Find the established pattern. Find the project. Find the GitHub repository. Use the standard protocol. Put the thinnest possible skin over it. Don’t invent another bloody abstraction unless Relay genuinely needs one.

So discovering that I had somehow constructed an autonomous software company with a board, HR, engineering departments and external workers but forgotten to hire myself a PA was quite funny.

Discovering that adding one barely disturbs the architecture was much more interesting.

That feels like a good sign.

The Utter Bastardisation of MVP and How Relay is Going to do it Properly

Stevie Bennett — Fri, 16 Oct 2026 17:12:59 +0000

I was lying in bed at about three o’clock in the morning last night, dictating notes into my agentic PA to dump onto tomorrow’s Kanban board.

One of them was about a department I’ve been designing inside Relay, the little agentic company I’m building around myself.

It sits between Discovery, whose job is essentially to find economically interesting things, and Engineering, whose job is increasingly to throw armies of AI agents at building them.

I’ve been calling this middle bit Shaping.

The idea seemed perfectly sensible. Discovery finds an opportunity. Shaping works out what the product should be. Engineering builds it.

And then, at three in the morning, I suddenly thought:

Jesus Christ, Stevie. That is not how you develop anything whatsoever.

Worse, I have spent years arguing against precisely that pattern.

The fact that software engineering is becoming cheap as chips does not suddenly make bad product development good product development.

If anything, it makes the mistake easier.

Because when building things becomes ridiculously cheap, you can build a phenomenal amount of stuff that nobody wants.

MVP does not mean “version one”

Before I explain where I think I went wrong, I need to talk about a book.

The Lean Startup, by Eric Ries.

I actually read the bloody book. Twice.

This distinguishes me from an alarming percentage of the people I have heard quoting its most famous acronym ever since.

MVP. Minimum Viable Product.

Oh, my dear God, MVP.

I have sat through more meetings than I care to remember in which somebody has announced, with great authority:

“This will be the MVP version.”

And I have felt my eyeballs quietly rolling into the back of my skull.

Because somewhere along the way, MVP came to mean:

Version one, but a bit shit.

Take the product you have already decided to build, remove a few features, launch it earlier and call it an MVP.

That is not the interesting idea at all.

The interesting idea is:

What is the minimum thing we need to create in order to test the important hypothesis?

Sometimes that is software.

Sometimes it is a landing page.

Sometimes it is a manually delivered service.

Sometimes it is a spreadsheet.

Sometimes it is an advert.

Sometimes there is a human sitting behind a curtain pretending to be the automation you haven’t built yet.

And sometimes it is a video.

Which brings me to Dropbox.

Dropbox didn’t build Dropbox to prove Dropbox

Dropbox had an awkward problem in its early days.

“File synchronisation” did not sound terribly revolutionary.

Files already existed. Online storage existed. File-sync products existed. You could quite reasonably hear the pitch and say:

“So what?”

The magic was in the experience.

Put a file in a folder on one machine and it silently appears on another. Change it somewhere else and everything stays in sync. Conflicts get handled. The whole thing mostly disappears into the background.

But building that properly is difficult.

So rather than build the entire thing before establishing whether anyone cared, Dropbox demonstrated the proposed experience with a video.

People cared.

A lot.

And that is the important distinction.

The video was not Dropbox version one.

It was the minimum product required to test whether people wanted the thing Dropbox was proposing.

A completely different idea.

Meanwhile, in Docklands

A few years later, I was commuting into London every day and reading The Lean Startup on the train.

I got to the Dropbox story.

I remember thinking:

That is brilliant.

I was building Dropbox.

Well, a Dropbox clone.

It was called Zettabox, and I was one of two developers working on it.

The central commercial thesis was essentially this:

European customers will not want their files stored in America. They will prefer a cloud-storage service that keeps their data in Europe.

And the chosen method for testing this hypothesis was apparently to spend millions building Dropbox again.

You have to admire the commitment.

We built the thing, and I worked like a dog on it.

File synchronisation is an unpleasantly serious piece of software.

Get the colour of a button wrong and somebody gets irritated.

Get synchronisation wrong and you have just deleted Granny’s only photographs of Grandad.

There are conflicts, partial uploads, offline machines, files renamed in two places at once, networks disappearing halfway through things and an endless collection of edge cases waiting to eat somebody’s data.

And underneath all this engineering was one rather important question:

Did enough people actually care where their files were geographically stored to switch provider and pay us?

You could test that question without building Dropbox.

Put up a page.

Run some ads.

Offer:

European-only cloud storage. Your files stay in Europe.

Ask for money.

See what happens.

The product disappeared a couple of years later. My recollection is that roughly £10 million had gone into the whole adventure by then.

They could have given me £1 million and saved the other nine.

I’d have rung my mother.

“Mum, do you care whether your files are stored in Virginia or Frankfurt?”

“No.”

There we are.

Invoice attached.

Cheap software doesn’t make bad ideas good

This is what hit me at three o’clock in the morning.

Software production inside Relay is becoming extraordinarily cheap.

Increasing amounts of the engineering are performed by autonomous agents. They can investigate problems, write code, run tests, review each other’s changes and increasingly keep going without me sitting there supervising them.

That is wonderful.

But it does not repeal reality.

Making the wrong product ten times cheaper does not make it the right product.

And I realised that my original definition of Shaping was backwards.

Its first question should not be:

“What should Engineering build?”

It should be:

“What has to be true for this idea to work, and what is the cheapest possible thing we can do to force reality to tell us whether we are right?”

That is what I actually mean by an MVP.

Sometimes, for an idea to die, it has to live

Here is a deliberately silly example from something we have been throwing around recently.

Suppose one of my Discovery agents comes back with this:

Find Airbnb properties with ordinary listing photographs and use AI to generate convincing moving, three-dimensional-style walkthrough footage without anybody physically visiting the property. Sell that new marketing asset to the owner.

Fine.

But that isn’t a product yet. It is a collection of hypotheses.

Can current AI actually produce something convincing enough?

Can it do it cheaply?

Can we mechanically identify suitable properties?

Does the asset genuinely look more valuable than the source photographs?

Do owners care?

Will they pay?

Can agents operate almost the entire thing without accidentally turning me into Chief Executive of Making Airbnb Videos?

Those are the questions.

And this is the awkward bit: research can only take you so far.

Sometimes, for an idea to die, it has to live for five minutes in the real world.

So perhaps we make three examples.

Perhaps we create one simple page.

Perhaps we show them to ten property owners.

Perhaps we ask for £100.

Nobody buys?

Excellent.

We have learned something before building the Airbnb Three-Dimensional Artificial Intelligence Property Marketing Platform™, hiring a sales team and producing a seventeen-slide roadmap.

Maybe people love the output but won’t pay £100.

Change the price hypothesis.

Maybe Airbnb hosts don’t care but wedding venues do.

Change the buyer.

Maybe nobody wants the 3D walkthrough but estate agents pay for thirty-second social-media reels.

Change the mechanism.

The MVP can be thrown in the bin afterwards.

That is fine.

Its job was to produce evidence.

Concierge before automation

I already work this way constantly inside Relay, the agentic operating system I’ve built. I just hadn’t properly connected it back to MVP thinking.

I use the phrase:

“We’re going to concierge this.”

By that I mean: do the process in the crudest way necessary to find out whether it is useful before automating the hell out of it.

I have small recurring research agents I call Sentinels.

One might have a job like:

Once a week, look at what is changing in agentic software development, compare it with what Relay currently does and tell the Relay Foreman if we appear to be missing anything important.

Eventually, that could be beautifully automated.

It could schedule itself, gather evidence, cross-reference company knowledge, create work and monitor what happened afterwards.

Wonderful.

But I do not begin by engineering all of that.

Initially I might have an agent with a rough prompt and manually trigger it.

Run it.

Was the report useful?

Did anybody act on it?

Did it discover anything important?

Run it again next week.

Still useful?

Good.

Now earn the automation.

That is a minimum viable product.

The MVP should try to murder the idea

This, I think, is the bit that has been most thoroughly lost in the modern interpretation of MVP.

The MVP is not there to justify the thing you already want to build.

It should be trying to kill it.

Ask:

Which assumption, if false, destroys this idea fastest?

Then test that one.

If your entire business depends on customers paying £500, there is little value spending three months proving that you can technically produce the thing for £7 if nobody will pay £500 for it.

Likewise, if technical feasibility genuinely is doubtful, prove that before spending weeks designing the sales process.

The order should follow uncertainty, not the org chart.

This also makes early roadmaps rather suspect.

I have seen versions of this countless times:

Q1: build features.
Q2: build more features.
Q3: discover nobody wants it.

I would prefer to bring Q3 forward.

Once the dangerous assumptions survive contact with reality, then by all means make the roadmap.

Until then, a beautifully planned roadmap is often just beautifully formatted fiction.

I may have to rename the Shaping Department

I’m not sure yet whether Shaping survives as the name.

But its job has changed completely in my head.

Discovery should hand it an economic hypothesis.

Something like:

We believe buyer X experiences problem Y and may pay for outcome Z.

Shaping should then identify the assumptions inside that sentence and work out the cheapest sequence of experiments capable of proving or killing them.

Only after enough of those assumptions survive should Engineering receive anything resembling a durable product mandate.

That seems particularly important now because of the strange irony of agentic software development.

We are rapidly approaching a world where building is no longer the expensive part.

Knowing what deserves to be built is.

If ten autonomous software engineers can build your terrible idea over the weekend, somebody still needs to make sure it is not a terrible idea.

Otherwise all we have invented is a much faster way to build Zettabox.

And I’ve already done that once.

I’m not doing it again.

How Many Electricians Does It Take to Change a Light Bulb?

Stevie Bennett — Fri, 16 Oct 2026 17:09:12 +0000

I have recently been observing a phenomenon I can only describe as the industrialisation of doing absolutely fuck all.

Not ordinary laziness. We’ve all had a Friday afternoon when the prospect of opening another spreadsheet makes us want to climb into the stationery cupboard and die.

No, this is something far more sophisticated. This is twenty people, all working very hard, all attending meetings, all producing documents, and somehow collectively achieving less than one bloke with a screwdriver.

The easiest way to explain it is with a light bulb. Not a clever one. No Bluetooth. No subscription required to access the illumination functionality. The sort of thing you buy in Tesco.

1. Dave

A large organisation discovers that a light bulb has gone out and engages an electrician. Let’s call him Dave.

Dave arrives on Monday morning. He replaces the bulb, checks the wiring and tests the switch. The light comes on. He turns it off. He turns it on again. Beautiful.

You might imagine that would be the end of the story. You would be spectacularly wrong.

Dave has confused the successful installation of a working light bulb with the successful delivery of the Light Bulb Programme. These are entirely different things.

The Light Bulb Programme has a Programme Board, a Lighting Design Authority, a Risk and Assurance Function, and a gentleman called Martin, the Programme Assurance and Stakeholder Alignment Lead.

Martin’s first job was replacing batteries in emergency torches. He once spent three days investigating a faulty torch before somebody noticed he had put the batteries in backwards. He was promoted to Torch Maintenance Coordinator, where he could supervise battery replacement without going anywhere near a battery.

Twenty years later, Martin is an authority on the governance of illumination.

Martin has concerns.

Martin has not personally produced any light since 2004.

2. The Lighting Design Authority

The Design Authority asks for an architectural diagram. Dave produces one. There are arrows. Everybody likes arrows.

It is circulated to seventeen people, including three on annual leave and one who left the organisation in 2022.

“Dave, could you just talk us through the architecture?”

“Electricity comes in here, passes through the switch and powers the bulb.”

“And the bulb itself?”

“Produces light.”

“Fantastic. Could we capture that in a separate document?”

At the next meeting, Martin asks whether anybody has confirmed that the bulb is compatible with the switch.

“I’ve turned it on and off several times, Martin.”

“Yes, but I think we need to be careful about confusing successful testing with formal confirmation of compatibility.”

The programme manager nods. “That’s a really important distinction.”

Dave briefly considers eating the test report. Instead, he agrees to add a sentence.

Without Martin, the electrician might have walked away under the entirely mistaken impression that turning a light bulb on and off constituted evidence that it could be turned on and off.

3. The forty-document handover

Over the following weeks, Dave produces an Architecture Definition Document, an Interface Definition Document, a Functional Specification, an Operational Support Manual, a Troubleshooting Guide, a document explaining the relationship between the switch and the bulb, another explaining the relationship between the bulb and the room, and a rollback procedure, which consists of turning the switch off.

Forty documents in total.

Martin suggests a simple orientation document explaining what each component does.

“For example, this component called Light Bulb. What does that actually do?”

“It produces light, Martin.”

Dave briefly considers whether prison would really be that bad. Instead, he writes document forty-one:

Light Bulb: The component responsible for producing light.

Light Switch: The component responsible for switching the light on and off.

It reads like GhostDoc, that old Visual Studio extension that generated comments with all the intellectual sophistication of a damp flannel. A property called UserName? The user name. Marvellous.

The document is accepted. The organisation now has a comprehensive understanding of the light bulb.

Unfortunately, the office is still dark.

The Design Authority then asks why the documentation says “light bulb” when the approved terminology is “Illumination Delivery Component”.

Dave changes the heading. Document forty-two.

This is, and I really cannot emphasise this enough, a fucking light bulb.

4. This is enterprise lighting, Dave

Eventually, Dave says it out loud.

“Look, it’s a fucking light bulb. Can we please just turn the bloody thing on?”

The room goes quiet.

“Dave, I appreciate you may be used to smaller domestic installations, but this is a large professional enterprise. We have processes, stakeholders and security requirements. It’s a rather different level of complexity.”

Martin nods. “Enterprise lighting operates at a completely different level.”

Now, before this engagement, Dave had been lead electrical engineer on some of the largest commercial buildings in Britain. Skyscrapers. Hospitals. Substations, backup generators, thousands of circuits. On those projects, fitting a single bulb was a task for the most junior apprentice, possibly as a reward for identifying which end of the screwdriver to hold.

He had not expected to be lectured on enterprise electrical engineering by a man whose principal technical achievement was connecting his laptop to the projector, with assurance provided by a man once defeated by a torch.

Dave considers explaining this. Then he looks at Martin, who is making a note about stakeholder alignment, and decides life is too short.

“Fair enough. You tell me how you’d like it installed.”

“Excellent. That’s exactly the collaborative approach we need.”

5. The Great Switch Access Crisis

The programme enters its operational handover phase. Dave’s key to the electrical cupboard is confiscated. He is no longer permitted to touch the switch.

A week later he is invited to Light Bulb Production Readiness: Critical Path and Outstanding Delivery Actions.

“Dave, we’re a bit worried. The light hasn’t been turned on in production.”

“Correct.”

“What’s preventing that?”

“You took my key away.”

“Yes, but that was part of the agreed handover process.”

“Then ask your electrician to turn it on.”

“But can you confirm it will work?”

“I tested it in development and test. I haven’t been allowed into production.”

“Could you do that today?”

“No.”

“Why not?”

“Because. You. Took. My. Fucking. Key.”

The programme manager writes something in his notebook. “Right. So we’ll capture that as an outstanding action for Dave.”

Dave points out that the organisation now owns the installation, the cupboard, the switch, the keys and the electrician.

“Absolutely. But you’re still our subject matter expert. We’d really appreciate it if you could take ownership of getting this over the line.”

Dave asks whether that means he can have his key back. It does not.

Martin intervenes. “Perhaps it would help to separate the question of who has access to the switch from the question of who is responsible for ensuring the switch gets switched.”

Martin is delighted. He has identified two distinct workstreams.

6. Scope, security and the observation framework

To reduce risk, the organisation decides to deploy a single bulb. The rest of the building will stay dark while it considers the security implications of illuminating multiple rooms.

Somebody asks who is responsible for observing the room once the switch is flicked, and whether that person is authorised to confirm that illumination has occurred.

Martin raises a further concern. The room is currently lit by daylight. How will they distinguish successful illumination from a false positive?

The meeting agrees the bulb must be tested after sunset. Unfortunately, Electrical Operations does not provide out-of-hours support.

Then somebody asks whether the bulb has been penetration tested. Could light visible through the window constitute an information disclosure vulnerability?

The security team requires a representative production environment. The light cannot be turned on until the penetration test is complete. The penetration test cannot begin until the light is on.

The meeting concludes that there is a dependency. Everybody nods solemnly. It is added to the risk register.

Dave’s contract is extended for another month.

7. The electrician builds something else

Dave is no longer upset by any of this.

He is paid his full rate to attend meetings about a bulb he finished installing months ago. He has no access and no authority, and most questions can be answered by pointing at one of forty-two documents.

This leaves him with rather a lot of spare time.

So he builds an automated electrical installation system. Robotics, machine vision, software that designs a circuit, installs it, tests it, finds its own defects and fixes them. Before long it can wire an entire house without him.

Martin, meanwhile, is having an excellent year. He has identified seventeen documentation gaps, chaired eleven stakeholder meetings and escalated three critical dependencies. His performance review describes him as instrumental in driving the programme towards production readiness.

Not a single photon has emerged from the production bulb.

Martin is promoted to Head of Illumination Strategy.

Nobody asks whether he knows how to change a light bulb. That would be rather beneath him.

8. Governance is not delivery

I am not suggesting governance is pointless. The more serious the consequences of failure, the more important it is to establish that a system is safe.

But there is a difference between governance that reduces risk and governance that makes people feel less anxious. One produces evidence. The other produces meetings.

Some organisations have become extremely good at observing delivery without participating in it. They can produce a beautifully colour-coded spreadsheet showing the Light Bulb Programme is 94% complete. Ask what is physically stopping the light coming on, and they have no idea.

The incentives are the interesting part. The electrician’s measure of success is simple: does the fucking thing work? His job ends when it does.

Martin’s job can continue indefinitely, provided there is always something else to discuss before somebody turns it on. Every delay produces a dependency. Every dependency produces a meeting. Every meeting produces an action. Every action proves Martin is indispensable.

It is a magnificent little perpetual-motion machine. Unfortunately, it runs entirely on other people’s productivity.

It would be a terrible shame to discover that the only person in the organisation who understands the light bulb is the one person they have forbidden from touching it.

Although it would explain the spreadsheet.

9. How many electricians does it take?

Dave attends what he has been assured is the final production readiness meeting.

“We’ve made tremendous progress. Documentation, handover, ownership model. I think we’re almost ready.”

Dave looks at the light bulb. It is off.

He checks his phone. His system has just finished another project. Three houses wired. Two defects found and corrected. No human intervention.

“Dave, are you comfortable the light bulb is ready?”

“Yes.”

“So when will it be turned on?”

“When your electrician turns on the switch.”

“Is there anything you need from us?”

“Not a thing.”

“Fantastic. We’ll capture that as an action for Dave.”

Martin raises his hand.

“Sorry, just one final point. Could we get a simple diagram showing which direction the switch needs to move?”

Dave looks at Martin. Martin looks at Dave. The programme manager looks delighted.

“Really good point, Martin. Let’s get that documented.”

The meeting closes. Everybody thanks everybody else for their time.

Dave’s contract is extended for another month. He opens his calendar.

Light Bulb Production Readiness: Weekly Progress Meeting. Recurring. No end date.

He accepts. After all, the light bulb isn’t going to turn itself on.

Although, funnily enough, the one Dave has just designed probably will.