How to Stop Your AI Workforce From Melting Your Brain by 5pm
Or, why my synthetic company needs a throttle control before it melts my brain.
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.