Donchitos ships 49-agent Claude Code studio, then measures that more process made the game worse

A GitHub template called Claude Code Game Studios turns a single Claude Code session into a 49-agent, 74-skill studio, complete with directors, department leads, and specialists. The scaffolding is the headline. The buried benchmark is the actual story.

The repo, by a developer posting as Donchitos, organizes agents into three tiers. Three directors (creative, technical, producer) guard the vision. Eight department leads own domains. The rest are specialists: gameplay-programmer, engine-programmer, ai-programmer, network-programmer, economy-designer, qa-tester, live-ops-designer, community-manager. Each agent declares a model in its frontmatter. The three directors ask for Opus. Lead-programmer and fifteen specialists name Sonnet. The remaining thirty inherit whatever model your session is running.

That last detail matters more than the count. Most of the studio is not a separate billing plan. It is your existing session wearing hats.

The rigor test is the interesting part

The repo asks a fair question: does this produce games, or documents? Then it answers with a measurement instead of a sample project.

Four games were built from one brief at different modes.rigor levels, and the documents each wrote before its first line of game code were counted. At minimal, one document (the one-page brief), 0 minutes. At standard, 30 documents, 58 minutes. All of them produced a running, tested game. Then two blind reviewers and a human playtest ranked the standard build last.

Read that again. The heavier tier wrote 29 more documents and the result landed at the bottom of the ranking. The repo’s own conclusion: “the extra 29 documents bought traceability, not a better game.”

That is a rare thing in the agent-tooling space, which mostly ships demos and vibes. Here is a template author publishing a result that undercuts the template’s own most elaborate setting. The default is minimal for exactly this reason, and the repo says so plainly: the heavier tier “costs more to reach working code without producing a better result, and gives nothing back when someone new picks the project up.”

Process is the product, and the product is unproven

Strip away the studio metaphor and what you have is a process-enforcement layer for one model. The 15 hooks validate commits, pushes, asset changes, and design-doc reads and writes. The 14 rules are path-scoped coding standards that fire when you edit gameplay, engine, AI, UI, network, scene, or asset files. The 62 templates cover GDDs, UX specs, ADRs, sprint plans, HUD design, accessibility.

None of that is a model capability. It is scaffolding around a model, the same way a real studio’s hierarchy is scaffolding around people. The bet is that structure catches mistakes a single chat session would not. A magic number gets flagged. A design doc gets written. Someone asks whether a feature fits the vision.

The rigor benchmark suggests the bet is only half-right. Structure catches mistakes. It does not, by itself, make the game better. The minimal build skipped almost all of it and still produced a running game that beat the documented one in a blind test. That is a sample of one brief and four builds, and the repo does not publish the brief or the games, so the result is suggestive, not conclusive. But it points somewhere uncomfortable for anyone selling process as quality.

The “it runs the game” rule is the sharpest idea here

The single best design decision in the repo is not the agent count. It is the rule that a story changing anything the player sees is not closed until the game has been launched, observed, and a screenshot retained in production/qa/evidence/.

The repo states the reason without flinching: “a passing test says nothing about a menu drawn off-screen.” A parse check is not a run. This holds at every rigor level, including minimal, where automated tests are waived but the visual check is not.

That is the correct instinct for agentic software work in general, not just games. Agents are very good at producing artifacts that pass the checks they were told to pass. They are much worse at knowing whether the artifact is any good. Requiring a human or agent to actually look at the output, and to keep the evidence, is a cheap guard against the failure mode where green tests hide a broken product.

The repo’s own benchmark found that 30 documents before the first line of code produced a game that ranked last. That is the most honest thing in the agent-tooling space this month.

What the hierarchy actually buys

The three-tier structure is worth taking seriously as an orchestration pattern, separate from games. Directors hold the vision and review. Leads own domains. Specialists do the hands-on work. Escalation paths and quality gates run between them. The /team-* skills coordinate multiple agents on a single feature: /team-combat, /team-narrative, /team-ui, /team-release, /team-polish.

This is the multi-agent pattern the frontier labs keep gesturing at, made concrete and cloneable. Whether it works better than one well-prompted model is the open question, and the repo’s own data leans toward “not much, for the game itself.” Where it may pay off is on long projects, where the cost of losing context and the value of a written record compound. A solo developer picking up a project six months later benefits from the 30 documents even if the playtest did not.

The repo also ships studio-tests/, a catalog of all 74 skills and 49 agents with per-category rubrics and behavioral specs, plus /skill-test and /skill-improve to lint and iterate on the scaffolding itself. That is the template testing its own process, which is more self-aware than most agent frameworks manage.

What it means for builders

Two takeaways, and neither is “clone this for your next game.”

First, the repo is evidence that the interesting work in agent tooling has moved from the model to the harness. The model is a commodity input here, swapped per agent by frontmatter. The value is in hooks, rules, path scoping, and the discipline of writing things down. Anyone building agents should be studying the harness, not the prompt.

Second, the rigor benchmark is a warning. More process is not more quality. It is more traceability, which is worth something on a long project and worth nothing on a jam. The repo’s default is minimal, and its own numbers say that is the right call for reaching working code.

What to watch: whether anyone publishes a benchmark with more than four builds and one brief, and whether the “launch it and look at it” rule spreads beyond games. The screenshot-in-the-evidence-folder requirement is the part of this repo most likely to outlive the studio metaphor.