Directing a fleet of AI agents to build a game

What it is

Every panel texture, grime overlay, console screen and planet is generated at runtime, and every sound is synthesized with the Web Audio API. You can walk the decks, sleep, eat and work the consoles. You can also take the helm, fly the ship through a seeded field of named planets, and press L to ride an atmospheric entry down to a streamed desert planet, walk out, and board again. The project ran from June 11 to September 29, 2026: 120 commits, tagged v0.1 through v1.2.1, all public.

The constitution comes first

Agents work best with the same things people do: clear rules and a clear order of work. Two files carry them. CLAUDE.md is the constitution, which every agent reads first, and KICKOFF.md is the build order, phase by phase, each ending in a gate.

One file per room, 300 lines at most. If a file grows past that, it gets split before work continues. Small files are what let several agents work at once without touching each other's code.
Typed contracts between parts. Every room exposes the same interface (its geometry, its colliders, its interactive objects and its cameras), and the code that assembles the ship consumes only that interface. An agent building the galley never needs to read the engine room.
No shortcuts in the code. No any, explicit return types on everything exported, and anything replaced gets disposed: leaks count as bugs.

The harness before the ship

Phase 0 built the eyes before anything worth looking at existed. The game registers named cameras that a test can jump to and reports its own frame times, and one command builds the game, screenshots every camera and writes a performance report. Only then did the first room get built. Functional tests joined the same command as soon as there was something to interact with.

That ordering is the point. An agent can't be trusted to say a room looks right; it can be required to produce a screenshot and a passing report.

Gates nothing merges past

Typecheck clean, then every functional test green. A phase never starts on an uncommitted or failing baseline.
A binding frame budget. An average of at least 60 frames per second, and a 95th-percentile frame time of at most 18 ms, measured on a real GPU from the most expensive camera. If performance fails three times in a row, simplify the geometry rather than micro-optimize shaders to rescue it.
Art judged by eye, on a real GPU. Every headed screenshot gets read, and the rule is written down: do not rationalize a bad screenshot.
A reviewer before any merge. On the big builds, an orchestrator wrote the design contracts, Sonnet and Opus agents built in parallel lanes on separate files, and nothing merged until a reviewer signed off on types, functional tests, real-GPU screenshots and the frame budget.

The expensive lesson

The headless browser in the test harness quietly falls back to software rendering, and software lighting looks different from a real GPU. For about 20 days, art was graded on the wrong renderer: changes that looked right in the harness looked wrong on a real screen. The fix became a rule in the constitution. Headless runs prove behavior; only headed runs on a real GPU are allowed to judge how anything looks, and only they produce frame-rate numbers that count.

The starship's corridor drawn by the headless test browser's software renderer: the floor is nearly black and the trim is dull. — Fig. 1 One named camera, one build of the game, one machine, drawn both ways. The rule it produced: headless runs prove behavior; only headed runs on a real GPU judge how anything looks or count frame rates. What it cost to learn: about 20 days of art graded on the wrong renderer.

The same corridor from the same camera drawn by a real GPU: the floor's texture and the orange door frames show clearly. — Fig. 1 One named camera, one build of the game, one machine, drawn both ways. The rule it produced: headless runs prove behavior; only headed runs on a real GPU judge how anything looks or count frame rates. What it cost to learn: about 20 days of art graded on the wrong renderer.

A second lesson came from the last hardening pass. A test that calls a game's update function directly can pass while the real game loop never runs that code. So the door tests now have to watch a door actually move in rendered frames before anything is fast-forwarded.

Where it landed

The final hardening pass ran as parallel lanes again, each agent owning a separate set of files, with an independent code review that found three guard gaps, fixed before release. Verified on September 29, 2026, on a real GPU: all 16 functional tests and every real-input suite passing, and 131 frames per second with a 95th-percentile frame time of 8.2 ms, against the 18 ms budget, from the most expensive camera.

What I'd tell the next team

Build the eyes before the thing. If the harness doesn't exist, nobody, human or agent, can prove anything works.
Contracts are what make parallel agents safe. Separate files and typed interfaces turn a fleet of agents into a team instead of a pile of merge conflicts.
Judge on the real thing. A green test on the wrong renderer, or on a hook that skips the real loop, is a false sense of safety.
Write the rules down. Every mistake that cost real time became a line in the constitution, so no agent repeats it.