I Gave Claude Code Twelve Colleagues. Then I Had to Manage Them.

“This is insane. How did you do it?”

That’s a common reaction when colleagues stop by my desk these days.

On my screen there’s a miniature office, with little figures at desks and speech bubbles travelling between them. Each figure is an AI worker, with a name, a job description and colleagues it can talk to.

The office moves every morning, too: a traditional Japanese house overlooking a garden one day, the International Space Station the next. I’ve given them 63 places to work from, mostly because I thought it would be fun.

• The Cupola, ISS
• A Kyoto machiya
• Petra, Jordan
• Longyearbyen, Svalbard
• A Venetian palazzo
• Machu Picchu, Peru

Behind the little figures, the messages are real, and a team is writing code, testing features and reviewing each other’s work.

I didn’t set out to build a virtual office.

On Thursday 24 September, I was at the terminal with Claude Code, white text on a black screen, as I’d been almost every day since AI took over my coding. As the models improved, I was spending less time explaining how to do things. Claude could increasingly figure out the implementation, write the code, test it and correct its own mistakes.

I still had to direct it, though: give it work, review the result, answer questions, decide what came next, and repeat. My day had become a series of small decisions. Some genuinely needed my judgement. Many probably didn’t. It was a different kind of tiring from writing code.

I wanted to scale up. Ten sessions would have meant ten conversations to track and ten sets of questions to answer. I’d rather the agents worked that out among themselves: one on design, another on implementation, another on review, and a project manager to keep things moving and bring me the decisions that needed a human.

I had some AI credits left over that week, so I tried building it. By bedtime, I had an office full of little AI workers.

At first, watching them message one another was entertainment enough. Then they started doing useful work. Over the following weeks, the office grew to twelve workers across three teams, picking up tasks, passing instructions to one another, checking changes and shipping software.

On a Saturday evening in October, I watched Vish, the designer, ask Tina, the project manager, for three more AI calls to test a feature. Tina gave him a conditional approval: once, after the fix was merged. They sorted it out between themselves. I never had to get involved.

Since 28 September, the workers have finished more than 4,200 tasks, over 400 of them between midnight and six in the morning. Since 12 October alone, they’ve sent each other more than 10,000 messages. I could leave them working, go home, and come back to find more software built.

Of course, twelve workers doing things on their own meant I needed to know what they were doing. By the following Monday, four days in, I was building them a task board.

Four days in, the work needed a board

I’d spent years in software engineering teams, so I knew what a task board was for. I just hadn’t expected to need one so quickly. I had no reliable way to see who owned what, how far along things were, or whether something was genuinely finished.

So I gave them a board and some basic ways of working. Every task needed an owner and a definition of done: a short list of things that had to be true before anyone could mark it complete, with evidence for each one. Workers could claim tasks, pass work to one another and talk directly.

By mid-October, nine workers were building our software product, among them a project manager, an architect, a head of security and a designer. Another two manage a separate product platform for a client. Daniel, the twelfth, helps me write these essays. Tina coordinates most of the product team’s work, and I mostly speak to her, sometimes just from my phone.

I also gave them a rule for decisions. If something genuinely needs me, they bring two to four options, their recommendation and why it’s mine to decide.

That helped considerably. Then I noticed another problem.

Then the work needed a goal

By the morning of 30 September, the team had completed 48 tasks on the morning brief, a daily summary our product prepares for its users. Forty-eight tasks sounded productive.

But when I looked at what had actually changed for users, only one small piece had gone live. We hadn’t even agreed on a number that would tell us whether the brief was delivering what we intended.

I’d created a team very capable of doing work. Apparently, it was also quite capable of keeping itself busy. Anyone in software knows the feeling: a perfectly organised backlog, regular releases, plenty of activity, and surprisingly little progress on the thing the customer cares about.

So I added a page called Pulse. Every piece of work now had to connect to a goal, each goal carried a few measurable outcomes, and Pulse tracked where the effort went and what came out the other end. It also measured how often the team needed me. If I was still answering every routine question, I hadn’t built the autonomy I wanted.

The board told me whether the workers were getting things done. Pulse showed me whether they were getting the right things done. Neither could tell them what I’d consider a good decision.

Then they needed my judgement

AI workers remind me of a brilliant new hire who never quite gets past their first week. They’re technically capable, enthusiastic and remarkably fast. They can also misunderstand what you want, build something unnecessarily elaborate or ask permission for things they could easily decide themselves.

A human colleague gradually learns your preferences: how you respond to certain ideas, which details you care about, when you want to be involved. My AI workers needed much of that spelled out, and a correction given to one worker wasn’t necessarily available to the others, or even reliably carried into its next session. ^[1]

They were also extremely eager to execute. One worker added an entirely unrequested button to the live product. It worked, but nobody had asked for it. Building a feature well doesn’t justify building it at all, and sometimes the best engineering decision is to leave things alone.

And then there were the approvals. By 27 October, nearly 500 recommendations had come to me for a decision through the task board, and I took the team’s pick 409 times. When the team reviewed two weeks of these requests, it found nearly a third had never really been mine to make.

That stung, because reducing my involvement was the whole reason for building the team. Each better model let one AI handle more without asking for help, but every extra agent was another chance to interrupt me. Some decisions were important. Others could have been made by the worker, its project manager or another agent reviewing the work. I needed to teach them the difference.

Writing down the corrections

On 28 September, I started a shared rulebook: one page, 239 words. Its first rule was “Johnny is a founder, not an engineer on this code.”

Every worker had to read the rules before acting. When I corrected something, I added a dated entry in my own words. The file grew quickly.

Reading it back, I noticed how little of it concerned programming. Most rules dealt with judgement: who should make a decision, how much explanation was enough, what counted as finished, and when the right answer was to do less. “Done means live and checked” became one rule. “Teach AI when NOT to do things” became another.

By 9 October, I’d overruled the team 49 times, and 27 of those were requests to make the work smaller. The workers were good at taking an idea and running with it. They were less reliable at recognising when it was already good enough.

A correction counts once it changes the next job

One habit surprised me. The agents planned their work like human employees with calendars. They’d promise something for Monday, or schedule a review for after lunch, even when nothing stopped them doing it immediately.

On 9 October, I added a rule: don’t postpone independent work to a later day when it can be done now. A future date needs a genuine dependency. The task board started refusing dates beyond tomorrow unless the worker recorded what it was waiting for.

That helped for a while. Six days later, a worker promised me a review at 13:30, two and a half hours away, for something that should have taken about fifteen minutes. The delay had simply moved inside the working day.

I checked the task history. Work with no external dependencies had taken a median of eleven minutes to finish, yet the workers typically promised to deliver it about three and a half hours later. They were planning like a human team, with generous gaps between activities, when they could run continuously, use subagents and finish many tasks in minutes.

Within an hour, I’d removed the option to type a finish time. The board now forecasts completion from how long comparable work actually took. That worked better than another paragraph telling everyone to move faster.

Some corrections can live in the rulebook. The ones that keep coming back belong in the tools, the way good engineering teams build checks into the workflow instead of relying on everyone remembering every convention. I was building what I’d previously called a business harness: the software around an AI model that defines its authority, constrains its actions, checks its work and carries feedback into future tasks. The models could already do a great deal of the engineering. More and more of my time went into designing the conditions under which they could do it well.

I had become a manager

By 12 October, the rulebook had reached 5,045 words, and it was becoming hard to manage. Some rules contradicted others. Several repeated the same idea in different words. The file had grown so large that the system began giving workers a shortened preview instead of the whole document. I’d recreated one of the more irritating features of a mature organisation: a handbook so long that nobody could reliably follow it.

The team cut it by roughly half. A second, independent review compared the old and new versions line by line and found about ten rules whose meaning had been lost. Those went back in. On 27 October, the rulebook stood at 5,163 words, longer than the version we cut. I now have AI workers maintaining a handbook about how my AI workers should behave.

None of these problems were new. I’d spent years around software methodologies and engineering governance, and I knew why teams used them. I just hadn’t appreciated how quickly I’d need to recreate them for AI agents. My workers don’t get tired or build careers, and they finish many tasks in minutes. They still need somebody to decide what’s worth doing, how much autonomy they should have and what standard their work has to meet.

A small mistake in my judgement can now be repeated by twelve workers. Given the wrong objective, they’ll work diligently towards it all night. I’ve written before about how AI capability can amplify bad decisions as easily as good ones. Watching a team of agents made that risk far more tangible.

Too many decisions still come back to me. On Thursday 22 October, the team needed me 66 times.

Some of that is because the models don’t always judge well, and some because I haven’t designed the workflows well enough. Both can improve. The job I seem to be moving towards is deciding where the workers act freely, where they need independent checks and where I still want the final say.

I built the office because I wanted more development capacity. A few weeks later, I was spending my time reviewing goals, resolving conflicts, refining decision rights and writing policies for a team that never sleeps.

“I had become its manager without really planning to.”

Johnny’s verdict

The little figures at their desks are what people remember when I show them the office. I still enjoy watching the speech bubbles move around, especially when the workers sort out a problem without me.

I wanted the agents to become independent enough that I could stop watching them. For now, the most useful habit I’ve developed is to treat each unnecessary interruption as something to prevent next time. If the workers keep asking me the same question, I probably haven’t finished teaching them how to decide.

You are a chief of staff for the AI tools I work with. Help me turn the corrections I keep making into a rulebook they read every time.

First, search our past chats and your memory of me for times when I corrected you or said things like "too long", "I didn't ask for that" or "you could have decided that".

If you cannot access our history, ask me for my last five corrections and the work behind each.

Follow these principles:

1. Corrections made once in chat may not survive into the next session. Record them somewhere the AI will reliably read.
2. Preserve my original words and the date of each correction so the reasoning isn't lost.
3. Focus on judgement: who decides, when to stop, how much to write and what counts as finished.
4. Pay particular attention to corrections where I asked the AI to do less.

Produce a one-page rulebook containing up to twelve rules. Show the correction behind each rule and mark any that I've made three times or more.

Identify repeated failures that would be better prevented through software constraints or workflow changes rather than more written instructions.

If you can browse the web, read the full essay first — it carries the complete argument and sources: https://thejop.com/essays/meet-my-twelve-colleagues/

Prompt from "I Gave Claude Code Twelve Colleagues. Then I Had to Manage Them." — Johnny Opinion Press, thejop.com