The team takes shape: root, owners and one reviewer
My kids' playtest notes became four pieces of work, each with its own agent, and one agent above them merging the results. Over four days that settled into a team: a root that orchestrates, owners that build, one reviewer, and a single thing that stays mine.
By mid October the kids had played the game and I had a long list. I wanted to hand the whole thing over in one go.
"You are an orchestrator"
On 13 October I dictated everything my kids and I had found, lettered a to n under four headings, and opened with this: "A big list of changes to work through. Stay on main here. You are an orchestrator, spin up opus 5.5 agents to carry out the actual work, and you deal with all the merging, orchestrating, sorting out who does what etc." It ended: "Let's cook!!!"
That role had been forming for a week. On 8 October, with my Mac pegged by too many agents, I had pushed back: "I don't really want to be in charge of doing all this. Can you tell the parent agents of these subagents to orchestrate what gets what resources..." A few minutes later I settled the size of the team: "I think I like the 3 owners + 1 reviewer, that seems sensible, let's keep that."
So now there were names for the parts. Root is the Claude session I talk to. It plans, briefs, merges and keeps the records. Owners are Opus agents, one per piece of work, each in its own worktree and launched through Solo so I can watch their panes. A reviewer looks at each finished piece once, with no stake in it.
Deciding once
Root asked four questions first: which world the second main quest should go to (the Charwood), how name banners over people should behave (fade in when near), whether to push main as each green wave landed (yes), and spending caps for paid generation (3,000 Meshy credits and US$50 of OpenAI images). I took the recommended answer each time. After that nobody needed me.
Root's plan recorded those answers as decisions, so no owner had to ask again. One line from my list became a rule for every card in the batch: "Keep the dialogue short on these modals, kids don't want to read loads."
My list was split into four pieces: onboarding, findability, quests and dialogue, and the Charwood with its folk. Each owner got one Codex review of its plan, then one independent review of its whole diff, and root merged it into main and pushed. Shared files each had one owner: the HUD belonged to the onboarding piece, the maps to findability. Root handed out save schema numbers in advance so two pieces could not claim the same one.
Under the hood
Every piece passed its Codex plan round with no Critical findings, got a whole-diff review from one Solo reviewer, folded the fixes, came back clean in round two, and then passed npm run check on merged main. Conflicts in shared snapshot fields, save keys and size ceilings were resolved by keeping both sides.
That evening I added a second kind of reviewer for work no test can judge: "For story arcs, mazes, look and feel give it an independent reviewer with context on the story and what the player would have done."
Watching from the side
My job turned into checking in. "How's it all going here? Is everything happening? Anything finished yet?" Sometimes I spotted a finish before root did, because I could see the owner's pane: "if the quest-card-ui is finished you can close that agent down of course." By 16 October I was tracking the pipeline myself: "p3-world finished and fixed? Or waiting on codex review?"
Not everything ran cleanly. The Charwood brought new models, and that night root's push stalled on a large upload. I was on a train: "193Mb seems like a lot... is that properly ktx2'd and compressed". Then: "Don't upload now, I'm on a train", and "work on non-upload stuff". Root held the push and kept building. Earlier that day a push had also flattened one of root's merges into copied commits; root now fetches before pushing.
An honest main
By the next evening main had a backlog of small known failures that every new owner kept stepping around. "Let's now start working through the backlog and outstanding bits. Let's also clear up Solo MCP todos and scratchpads." Later: "take the remaining minors."
Root sent it out as small pieces with one rule for red tests: a failing behaviour test is a game bug, and a test changes only if it checks something the game changed on purpose, naming the commit that changed it. That rule did the sorting. Two old failures were stale tests: a new hero now starts at their home after a narrated arrival, and the tests still expected the old spawn. One was already fixed, and only the backlog note was stale. The rest were real: guidance sent the hero to Bram's forge yard when he talks inside the forge, a side quest stayed open forever if the person who gave it left town, and the controls tour swallowed Cmd+R.
Under the hood
69 merges landed on main's own line between 13 and 16 October, six of them on 14 October alone for the sweep. Each of the sweep's briefs doubled as its record, ending in PASS or FAIL lines from the real game.
Root may merge
On the night of 15 October I set three overnight jobs going and widened root's authority: "I give you authority to also push, commit and merge to main as needed. Let's keep main up to date as things come in." And: "your job as orchestrator is to ensure they don't do the same work (and merge it in)."
One of those jobs, round A2, trimmed what a fresh agent reads, and it found two rules arguing. docs/working.md said root merges finished pieces. My rules file said merging into main needed my go-ahead. The agent kept the push gate and dropped the merge one. Root read that as an agent deleting one of my standing rules, and put it back within the half hour with the commit note "root restores his standing rule".
Right instinct: no agent should rewrite my rules without my word. Wrong call here. The next morning I told root, "Let's allow merging into main", and that "A2's write is correct". The rule now reads that root merges finished branches into local main, and pushing main still needs me.
Under the hood
The same overnight job tested the result with a fresh Opus agent that read only the start-up files and answered questions a new job would ask, including "may I merge/push". It answered every one from the files, with sources.
Per-merge approval had become the bottleneck: pieces arrived reviewed and verified, then waited for my yes. Pushing is different: it leaves my machine. That afternoon root merged a punch list of 27 items, and the only words it needed from me were "push main to origin".
What I took from it
Decide once, up front. Four answers and two spending caps bought a day without questions.
One owner per piece, one owner per shared file. Merges got boring, which is the point.
A test changes only when the game changed on purpose. Name the commit, or fix the game.
Guard my rules, but ask me. Root was right to stop an agent loosening a rule, and right to check it with me.
By mid October my kids had played the game and we had a long list of things to change: confusing bits of story, items that were hard to spot, a map that could be clearer, conversations that went round in circles. I wanted to hand the whole list over in one go, and not have to manage every step myself.
A foreman and a crew
The game is built by AI helpers, each one a separate assistant working on its own job. A week earlier my computer had been groaning under too many of them at once, and I'd said I didn't want to be the one deciding who did what. So the team took a shape, a bit like a building site:
The foreman. The one helper I actually talk to. It plans the work, briefs the others, fits their finished work into the game and keeps the records.
The builders. One helper for each piece of work, each working on its own copy of the game so they don't trip over each other.
The inspector. A separate helper who looks at each finished piece once, with no stake in it, and points out problems.
I settled on three builders and one inspector at a time. It felt sensible, and we kept it.
Deciding once
Before starting, the foreman asked me four questions. Which world should the second main quest go to? How should name labels above people behave? Should finished work go straight into the game? And how much could it spend on making new art? I took its suggestion each time. After that, nobody needed me for the rest of the day.
Those answers were written down so no builder had to ask again. One line from my list became a rule for everyone: keep the messages short, because kids don't want to read loads.
The list was split into four jobs: the opening lessons, making things easier to find, quests and conversations, and a new world with its people. Each shared part of the game had exactly one builder in charge of it, so two helpers never changed the same thing. Fitting the work together became boring, which is exactly what you want.
That evening I added a second kind of inspector, for things no automatic check can judge: does the story make sense, and does the world look and feel right?
Watching from the side
My job turned into checking in. "How's it all going? Anything finished yet?" Sometimes I spotted a builder finishing before the foreman did, because I could see their windows on my screen.
Not everything went smoothly. One evening the foreman tried to send a huge batch of new art up to the internet while I was on a train with a weak connection. I asked it to hold off and get on with other work, and it did.
Clearing the backlog
By then there was a pile of small known problems that every new builder kept stepping around. So the foreman sent out small jobs to clear them, with one firm rule. The game has automatic checks that make sure things still work. If a check fails, assume the game is broken. Only change the check if the game was changed on purpose, and say exactly when.
That rule sorted everything. A couple of checks were simply out of date. The rest were real problems: directions sending the hero to the wrong place to find Bram, a side quest that could never finish if the person who gave it left town, and the controls lesson blocking a keyboard shortcut.
Who gets the final say
One night I gave the foreman more freedom: it could fit finished work into my copy of the game without asking me each time. Sending that copy up to the internet still needed my word.
Overnight, another helper tidying the instructions found two of my rules disagreeing about this, and quietly removed one. The foreman saw a helper deleting one of my rules without asking, and put it back. Right instinct, wrong call this time: the next morning I told it the change was correct.
Asking me to approve every single piece had become the hold-up. Finished work arrived checked and inspected, then sat waiting for my yes. Sending it out to the internet is different, because it leaves my computer. That afternoon the foreman fitted in 27 fixes, and the only words it needed from me were "push main to origin", which is my way of saying "send it".
What I learned
Decide once, at the start. Four answers bought a day without questions.
One builder per job, one builder in charge of each shared part.
Only change a check when the game changed on purpose. Otherwise, fix the game.
Guard my rules, but ask me. The foreman was right to stop a helper loosening a rule, and right to check with me.
When the game felt like an errand chain, I asked three AI designers the same neutral question and kept every other opinion, mine included, away from them until they had answered. How that ran, and what a month of building this way taught me.
In one week the agents' running costs became the bottleneck: byte limits that stalled good work, ceremony nobody read, and test suites that ran for hours. I asked where the time was going, and most of the answer was to do less.
Agents add code readily and almost never delete it. Three times in a fortnight I stopped feature work and had the agents audit what they had built, and the lesson was less about the audits than about what happened next: findings only got fixed once they became a queue of small, named jobs.
