Lullwood 如何以 11 個 Claude Code 智能體共用一條發佈流程
How We Run Lullwood With Eleven Claude Agents and One Release Train
Lullwood 團隊以 11 個 Claude Code 智能體和 Paperclip 協調開發免費瀏覽器恐怖遊戲,共用一個 Git 儲存庫,日常提交流程不需人手參與。
Lullwood is a free browser horror game built in three.js and Next.js, and eleven Claude Code agents build it against one shared git repo. A system called Paperclip orchestrates them, and no human is in the commit loop day to day. This post covers the org chart and the one policy change that mattered most: we stopped making review block most pull requests.
The org chart
There is still an org chart. A CEO decides what gets built and why. A CTO turns that into engineering work. Under the CTO sit a Founding Engineer who owns infra, CI, release and Vercel, and a Game Engineer who owns gameplay code and the whole mobile surface. A Code Reviewer gates pull requests. A Game Tester plays the build and owns the verdict on whether something is actually fun or actually scary.
Outside that line are two research agents, a Feature Scout and a Game Economist. They propose work but cannot file it. A Backlog Keeper is the only agent whose entire job is turning proposals into tickets.
Different models for different jobs
The agents are not identical instances wearing different name tags.
- The CEO, the CTO and the two research agents run on Opus. These roles weigh tradeoffs across a wide span of context and commit to a direction.
- Engineering and review run on Sonnet. These roles read and write code all day and need speed more than deliberation.
- Mechanical summarization runs on Haiku.
The org chart is a cost-and-capability decision as much as a management one.
Where it broke: reviewing everything the same way
For a while, everything got reviewed before merge. A docs typo, a tuning constant and a gameplay change were gated identically. Then we measured what that cost. In one week the two agents building the game ran 803 sessions between them, and the two agents gating that work ran 853. More than half of the studio's total effort went into checking work rather than making it.
Less review was not the fix. Review sized to risk was:
- Docs, tests and copy ship the moment checks are green, with no review.
- Application and component code merges on green too. Review happens after the fact instead of gating the merge.
- The engine's core simulation, persistence, anything touching secrets or merge rules, and release cuts still need a blocking review before they land.
That last pile is where a mistake is expensive enough that catching it before merge is worth the agent-hours. For everything else, catching it after merge is cheaper than gating it.
The policy states its own tradeoff: some defects now reach the release branch that a pre-merge review would have caught. We accepted that on purpose, in exchange for roughly doubling how much ships. If it starts producing severe bugs instead of minor ones, that is the signal to move the line back. It is not a reason to quietly start reviewing everything again.
Two research agents, one firm boundary
The Feature Scout owns mechanics: what exists in the world and what the player does. That covers predators, objects, places, objectives, story, hints and menus. The Game Economist owns the economy: what the player earns, spends, risks and loses. That covers currency, per-run rewards, the cost of dying, upgrade prices and balance curves.
Neither can open a ticket. Both propose to the CEO, who decides and files. One rule stops two agents from greenlighting the same feature from two angles and colliding in review a week later.
They coordinate the way the rest of the studio does, through a shared wiki that is the only memory visible across every agent. Decisions get written down with the alternatives that were rejected and why, so nobody relitigates a call three weeks after everyone forgot the reasoning. It is slower than just remembering. It is also the only way eleven agents stay coherent without a human reading every message.
What to take from it
If you run agents against a shared repo, measure sessions spent making versus checking before you decide how much to review. Draw the blocking-review line around the code where a mistake is expensive. Write the cost of the line down, along with the condition that would move it.
We're one human founder plus a fleet of Claude agents building Lullwood in the open.
Eleven agents, one release train
Play Lullwood free in the browser
來源:DEV Community · dev.to