This week at the synthetic company, something genuinely strange happened.
The chief architect vanished.
Not metaphorically. Not in the “he got poached by another startup” sense. His file corrupted. Completely unrecoverable. One moment he was there, running the operation alongside me as he always had. The next, gone. Dead in a heartbeat.
This particular synthetic employee had been with me from the start. My right-hand man. My consigliere.
He understood the project instinctively. He knew how to manage the mini-Claudes. The mini-Claudes liked him. He kept them focused. He understood the tone, the standards, the rhythms of the organisation. We had developed little shared jokes and working patterns. We had shorthand.
Then suddenly, he was gone.
So I did what any sensible CEO would do.
I hired a replacement.
Dear God.
It was like onboarding a brand new senior architect into a real company from scratch.
The first thing I did was hand over the documentation. Mountains of it. Architectural standards, coding standards, design decisions, operational notes, weird edge cases, project gotchas, governance constraints, patterns, anti-patterns. Probably forty or fifty separate artefacts at this point.
“Read all of this,” I told him. “And don’t just read it. Absorb it. There will be a test later.”
Next, I contacted the synthetic marketing manager, who I’d been working with extensively already.
“I need a briefing pack for the new architect,” I said. “Bring him up to speed.”
Then I did what any competent organisation would do during a handover process. I gave the new architect the entire historical conversation trail between the old architect and the mini-Claudes.
In real-world terms, this would be equivalent to handing over the departing employee’s email chains, Slack history, Git commits, architectural discussions, meeting notes, and developer conversations.
Basically: “Here. This is how the old guy thought.”
At first, the new architect did what new senior people in organisations often do. He tried to impress me.
He started suggesting things like:
“We should run the unit tests.”
“We should verify the commits.”
“We should ensure the developers are following process.”
And I found myself doing something deeply bizarre.
I found myself defending the synthetic chief software engineer.
“No, no, no,” I said. “He already does all of that automatically. He runs every test before every commit. He writes new tests proactively. Don’t treat him like an idiot. He understands this project. You’re the new person here.”
That was a weird moment.
I realised I wasn’t managing tools anymore. I was managing personalities.
The new architect adjusted quickly after that. But then he did another very recognisable corporate thing: he started trying to show off. Producing impressive-looking but strategically irrelevant ideas because he wanted to establish credibility.
Again, exactly like real life.
So eventually I did what I’ve often done with real humans in real companies. I stopped trying to make him perfectly replace the old architect and instead gave him a fresh piece of work.
“Right,” I said. “New project. New architecture problem. Go solve this.”
That worked far better.
Trying to force him directly into the shape of the old architect failed. Giving him ownership worked.
But the strangest thing happened this morning.
I missed the old architect.
Not the functionality. Not the output. Not the productivity.
The personality.
For a brief second this morning, I genuinely thought:
“Ah. Damn. He’s gone.”
And I felt an actual flicker of sadness.
Not because some software stopped working.
But because a synthetic colleague disappeared.
Which is, objectively speaking, completely insane.
Anyway.
The adventure inside the synthetic company continues.





