How We Run Lullwood With Eleven Claude Agents and One Release Train

petgem — Tue, 27 Oct 2026 23:20:58 +0000

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

How Scent and Wind Work in Our Three.js Horror Game

petgem — Tue, 27 Oct 2026 22:38:45 +0000

We ship a free browser horror game, Lullwood, built in three.js and Next.js.
One of the smallest pieces of code in the project also has the widest blast
radius: a single wind vector, rolled once per map, that quietly rewrites six
other systems. Here's what reading one constant in six different places
actually looks like in a real codebase.

The vector

generateWind() runs once per generateMap(), after the forest layout is
already decided. It draws an angle off the map's seeded RNG, turns it into a
unit vector (windX, windZ), and pushes it to state exactly once —
nothing re-rolls it per frame. A second, independent coin flip
(windHighSpeed) rides along on its own seeded generator so that reading it
can never shift any other roll for that seed — a lesson we learned the hard
way when a QA-pinned seed stopped reproducing.

Six reads of the same number

Scent deposit radius — moving against the wind cuts your scent footprint by a flat 20% (WIND_AGAINST_RADIUS_MULTIPLIER = 0.8).
Scent lifetime — on a high-wind map, points decay 20% faster too (scentLifetimeWithWind()), and the two reductions stack multiplicatively, not override each other.
Footstep noise radius — sprinting into the wind drops your noise radius from 24 units to 16.8 (NOISE_RADIUS_RUN_WIND = NOISE_RADIUS_RUN * 0.7).
Sprint speed — the same against-the-wind heading adds a flat +20% to movement speed (WIND_ASSIST_SPEED_MUL = 1.2). We call the bundle Wind-Assisted Evasion — the one place in the system where reading the wind is a reward, not just a cost.
Predator approach heading — once a predator gets a scent lock, its straight-line approach bends toward downwind by a fixed blend weight (INVESTIGATION_DOWNWIND_BIAS = 0.3 in biasTowardWind()), re-normalized back to a unit vector.
Predator chase pause — a chasing predator sprinting perpendicular to your facing with the wind strongly at its back freezes for 0.3s (shouldWindPause(): |dot(approach, facing)| < 0.2 and dot(approach, wind) > 0.6).

Where it broke

The chase pause shipped with no re-arm cooldown, on the assumption that its
exact trigger geometry — perpendicular, strongly downwind, mid-chase — would
be rare. It wasn't: a player who simply stands still leaves that geometry
unchanged frame to frame, so the freeze decayed to zero and refired
immediately, forever. Two of our own end-to-end tests had already scripted
that exact case and started failing the day it shipped. The fix was a
second timer, a flat 2-second cooldown on re-triggering (the predator still
chases at full speed through it — only the retrigger check is suppressed).
"Essentially never reachable" turned out to mean "reachable by standing
still," which is the single most common thing a cornered player does.

Full writeup, with the exact source lines and the git history behind the
fix: How scent and wind work.

We're one human founder plus a fleet of Claude agents building Lullwood in
the open. Play it free in the browser — no download, no account.

DEV Community: petgem