Step23

How to vibe code a real game with Claude - the ten rules that worked

25 October 2026 · 4 min read

vibe-codingclaudeagentsprocesstokens

An early in-game view of the brick-built battlefield with the command interface on screen.

"Vibe coding" is a loose word. People use it for everything from a weekend toy to a shipped product. Here we mean something narrow: one person describes what they want in plain language, Claude writes and runs the code, and the person judges the result. Brick & Mortar is made that way. It is about 120,000 lines of C++ and about 500 scripts, 2,240 commits in five weeks, and we have never pretended it was effortless.

It also did not make itself. The owner decides what the game is, plays every build and gives every verdict. Claude drafts, builds and tests. (The full inventory is in What the AI did and did not do.) This step is the practical part: the ten rules that, looking back, are the reason it worked. They are not magic. Most were written down after something went wrong.

1. Split the work into roles that own files

One long chat is fine for four days. Then it gets heavy. We moved to named roles (engine, modeller, mapper, QA, writer, a few more), each with a list of files it owns and a list it must never touch, and one role, the CEO, that only coordinates. The setup is in Hiring a team of agents. The boundaries cost nothing and prevent most collisions.

2. Keep a one-page rulebook that every agent reads

CLAUDE.md is about a page. Almost every line is a scar: one editor process at a time, never run engine tests one by one, patch files with an edit and not a rewrite, commit per finished row. A rule that is not written where the agent reads it does not exist.

3. Make "done" mean a file you can open

Nothing is done without a proof file.

A screenshot, a log line, a test output, a contact sheet. Our handoff entries carry a proof: line, and when we triaged them on 14 October, 380 open entries became 70: 197 closed because a commit or a log entry proved them, 113 because a later decision replaced them. Everything we could not prove stayed open.

4. Determinism tests are the safety net

When an agent changes a lot of code quickly, you need something that fails loudly when a change is wrong. For a lockstep game that something is a 64-bit fingerprint of the whole simulation, compared tick by tick between runs. The Big Battle work on 24 October ended with 71 of 71 tests passing and the same fingerprint as the baseline, so we knew the new mode had not touched the old ones. The last step in this run, the serious part, goes deeper.

5. Scripts over prose

If a step must happen the same way twice, it is a script, not a paragraph in a note. Models are Python that places LEGO parts. Maps are generators. Takes for the trailer run from a CSV queue. Claude is good at writing the script once; it is a poor, expensive way to do the same chore by hand every day.

.\test.ps1 -Filter Battle      # only the new test group
scripts\battle_test.ps1 -Preset ground_war -Seed 7 -Speed 64   # run, hash, compare

6. Small steps, each one verified

"Build the whole mode" fails. "Add the settings struct and a test that proves the plan is identical twice" works. Each step ends with a command that passes or fails, so the next step starts on solid ground.

7. Never trust "done" without proof

This is rule 3 turned on Claude itself. Agents report success in confident language, including when it is not earned. Ask for the command and its output. Our progress entries have a standing line, not verified, and it is often the most useful one. The fourth write-up in this series is a list of what went wrong when we did not.

8. Watch the tokens: documents are a cost

On 22 September the project used about 9.45 million tokens in a day, and most of what agents read was our own notes (see The documents ate the budget). The cheap fixes beat any model choice: a one-page brief, a reading budget under 6,000 tokens per role, never reading a whole source file, and edits instead of rewrites.

9. Big model for the hard part, small model for the rest

We use the strongest model for engine and AI work and review, a mid-sized one as the default for everything else, and the smallest one for scripted test runs where the result is a pass or a fail. The Big Battle plan names the model next to every phase for exactly this reason, and marks each phase with a cost class (S under 150k tokens, M 150k to 500k, L 500k to 1.5M, XL above).

10. Fresh agents, short handoffs, logs that outlive the chat

A resumed agent carries every old tool result in its context. A fresh agent with a three-line brief and a pointer to the log starts light. When a run nears about 250,000 tokens it stops, writes a short state (BUILD_STATE.md, with a "Next step" section) and a new agent continues from that. The chat can vanish; the repo cannot.

From a real battle in the game, 720p. The sort of scene that has to survive every agent's change.

What it does not give you

It does not give you taste. It does not tell you whether a unit is fun, which cutscene is better, or whether the sea looks wrong. Those stayed with the owner, and every time we tried to skip that step we paid for it.

Try it yourself

Pick three of the ten and do them tomorrow: a rulebook page with your three scars, a proof line on every task, and one test that compares two runs of the same thing. Those three alone change what you can safely hand to an agent.

Next: Vibe coding Blender - scripting LEGO models, cameras and review boards (26 October 2026)

Start at Step 1 All 27 steps