The problem
Alien Emperor is a mobile action game: you rise from the primordial broth, evolve, and fight your way back to the throne through arena, side-on, titan and finale battles. A game like that needs painted art, sound effects, music, voiced bosses, narrated cutscenes and gameplay code, and I am one person.
For eight months I worked the way most people use AI: one assistant, one conversation, me holding all the context.
The decision: stop prompting, start managing
On October 4, 2026, I set it up like a small studio. Four standing agents, each with a role and a lane:
| Role | Owns |
|---|---|
| Gameplay Coordinator | Scenes, game logic, the rest of the source tree |
| Art Director | The art build pipeline, asset prompts and source art |
| Sound | Sound effects, voice lines, music |
| Cutscene Director | The cutscene engine and all 11 reels, by agreement with Gameplay |
The rules live in a shared CLAUDE.md, the team’s operating manual. Agents ask before touching another role’s files, and anyone who does touch them tells the owner. Each role works in its own git worktree and lands changes through one script that merges, runs every check, pushes, waits for the deploy, and cleans up after itself.
Handoffs are contracts, not vibes. A sound request names the cue, its trigger, the creature and its load group. An art request names the final path, size, transparency, anchor and facing. A cutscene request names the reel, the shot and the exact narrator line.
Quality gates
Every push to main deploys to production, so the gates have to be real:
- CI runs type checks, lint, the full test suite and a production build on every push.
- Tests enforce the contracts between roles: a sound cue with no load group fails, a voice line the game no longer uses fails, narration without half a second of breathing room fails.
- A change isn’t “done” when it’s pushed. It’s done when the deploy succeeds and the live bundle contains it.
What went wrong, and what each failure became
None of the failures were about AI being bad at code. They were the failures of any team that moves fast in a shared codebase, and each one became a rule.
- Shared workspace, leaked work. An art push carried Gameplay’s unfinished code to production. Rule: separate worktrees, and check what you’re about to push is only yours.
- A race on merge. Main moved mid-squash and a reset quietly undid a teammate’s commit. Rule: your diff against main must list only your own files.
- A hidden interface. Upscaled art broke three code paths that assumed the old pixel sizes. Rule: before changing a shape other people depend on, find the consumers and warn them.
- Borrowed sounds. I noticed several bosses sharing one creature’s roar. Rule: every creature gets its own sounds, then an audit, then a fix. A quality bar only holds once it’s written down.
- Testing only your own corner. A cutscene edit broke a test Gameplay owns. Rule: run the whole suite, not just your folder.
- A deploy that never happened. A push succeeded and the deploy silently didn’t start. Rule: verify outcomes, not actions.
What happened
All 11 cutscene reels went live with every caption narrated, every boss got a voice, and the asset library grew to about 1,400 art files and 1,100 audio files, with a $0 budget for cutscene tooling. Every push goes through the same gates, and each failure above is now a rule the team works under.
Why it matters beyond a game
This is the engineering org I expect most of us will run soon: people setting direction and standards, agents doing much of the building, and the leader’s job shifting from writing code to designing ownership, contracts and gates. Every rule above is one I’ve enforced with human teams. The agents just made the lessons arrive in days instead of quarters.
What I’d do differently
Write the ownership map and the landing script on day one, not after the first collision. And add the “verify the outcome” rule before the first deploy, not after the first silent failure.