AGENTIC GAME DEVELOPMENT

@sashanaria · 11 min read

I'm a game designer, and in my own time I'm building a game. Most of its code is written, reviewed and tested by AI agents. None of them has the final say on a design call.

This post is the setup behind that: who decides what, how the agents run, how every change gets checked, and what I changed when it got slow. It's what works for me, solo, on one Windows PC and a few subscriptions. It isn't a framework, and I'll keep changing it.

The rule: I decide, agents build and prove it

Everything rests on one split.

Only I decide: how the game plays; every name, number and word a player sees; the look, the world and its characters; what's in scope and in what order; and merges. For merges I have one standing rule: a PR that leaves me nothing to answer merges without me.

What I can hand to agents: how the code is structured, tests and CI, how reviews run, and fixes that change nothing a player sees.

Every decision is written down with my words quoted, the date and the channel. Without a quote, it's a proposal, whoever wrote it. That sounds bureaucratic until the first time an agent tells you "you decided X" and you can check. Small word and look calls an author makes while building are fine too, for now: they're recorded as proposals, and I go through them all in a review pass after the build.

Context first: give agents the world before the code

Agents are very good at the average. If the repo doesn't say what the game is, every gap gets filled with the most generic answer. So before any code, write down:

• What it is: the player fantasy, the genre, the feeling you're after.
• What it isn't: the games it must not become, and the clichés to skip.
• The world: lore, places, the cast and their tone.
• The words: every name and term, and what it means, in one place.

With that in the repo, agents' proposals lean toward your game instead of the average one. I learned this late: my world bible came after the first prototypes, and I spent review rounds pulling agents back from generic choices. Anthropic's post on context engineering makes the longer case for why what an agent has in front of it matters this much.

The setup: one orchestrator, every vendor's harness

On my PC, it all runs in T3 Code. One thread is the orchestrator, on Claude Opus 5.5 at high effort. T3's orchestration lets that thread start subagents on other vendors' harnesses, read their threads and follow their runs, so a review loop closes without me copying messages between tools.

• Claude Code runs the Claude models: Opus 5.5 for authors, Sonnet 5.5 for code review, Fable 5.1 for UI and docs review.
• Cursor runs Grok 4.7, which makes one pass over every whole PR.
• GitHub holds the PRs, runs CI verify on every push, and keeps the review reports.
• A Grok Bot on its own Debian VM runs pstack skills and takes rule-only work. It isn't in T3 at all: it meets everything else through GitHub.

One rule keeps it sane: Claude models run only through Claude Code, and Grok only through Cursor.

A task's life, from brief to merge

Every task follows the same five steps.

1. The brief. One outcome, the checks that prove it, and my decisions quoted. It has to stand alone, because the author never sees the conversation that led to it.
2. The build. The author branches from the latest main, runs the checks, and tries the change on test scenes before anyone reviews it.
3. The PR. What changed, how it was checked, and what no check covers, so I know where to look.
4. The review. A fresh reviewer on another model. Its report opens with PASS or NOT PASS. On NOT PASS the author fixes and a new reviewer checks the new tip. If round 3 still fails, the loop stops and I get the question of approach instead.
5. My turn. I play anything a player sees. If nothing is left for me to answer, it merges on my standing rule.

A different model checks every change

Authors are Claude Opus, so the reviewer is always another model. Round 1 gets three: Sonnet on the code, Grok through Cursor on the whole PR, and Fable on captures and docs. Later rounds get a brand-new Sonnet that reads only the diff since the last check, plus Fable when there are new captures. Then me, for feel and taste, by playing it.

Two rules matter more than the models. Reviewers judge code and tech only: correctness, tests, gates and security, never the design or my decisions. And every round gets a new reviewer, because one resumed from an earlier round tends to recheck its own old findings.

Seven layers of checks, from the rules to my hands

1. Rule tests. The rules are plain C# with no engine inside, so they test in seconds.
2. Preview equals outcome. A preview is the same rules run on a copy of the state. There is no second formula to drift.
3. Headless smoke. Real input, start to finish: a full win and a full loss.
4. Rendered review. The full run at 1920×1080 and a quick pass at 1280×720.
5. Readability bar. No overlapping labels, and no effect on screen that the rules didn't produce.
6. Bots. Scripted players on the same rules. A bot that spams one move must lose.
7. My playtest. Feel, fun, and whether I'd play it again.

Machines prove the wiring. I judge the feel.

When my play finds a bug that passed review, it goes on a misses list together with the check that should have caught it.

The review loop's six rules

These came from Anthropic's post on code review, adapted for one person:

• A round cap. Round 3 still failing? I get the approach question, not round 4.
• Name the class. A finding names its kind of bug, and the author fixes every instance, not just the one seen.
• Old bugs don't block. Anything already wrong on main goes to one follow-up list.
• Later rounds read the diff. Only what changed since the last check, plus the earlier findings.
• Say what's unchecked. Every PR says where no check looks.
• Count the misses. A bug my play finds after review gets one line and a new check.

Reviewers write their reports to a file, and a script posts them and checks GitHub's copy byte for byte, so nobody paraphrases a verdict.

Why Godot, for me, for now

I've worked in Unreal since 2019, and this game's first version was built in it. This year I moved the prototype to Godot, for iteration speed. For agent work, Unreal fought me in three places:

• Blueprints and UMG widgets are binary assets, so there's no text diff for an agent to read or a reviewer to check.
• Editor starts and C++ builds take minutes, and the checks need a heavy engine install.
• The UI was slow to build and hard to check.

In Godot, scenes, UI and scripts are text, so every change is a readable diff. The rules test in seconds, and the whole check, build to smoke, runs headless on any Linux box, CI included. On my Linux VM it took about 90 seconds. For solo indie work with agents it turned out really solid.

It's a call for me and for now. The rules have no engine code in them, so I can change my mind later.

It wasn't only the engine

To be fair to Unreal, part of the problem was me. The first version grew correct but expensive systems around a game I was still discovering: compatibility paths between old and new, several copies of the same state, replay fingerprints, save transactions, balance simulators, paperwork gates for evidence.

The rebuild kept what mattered: deterministic rules, rules tested without the engine, an exact and readable preview, one source of gameplay truth, and the design lessons from edge cases. The rule now is that a production system comes in only when repeated play shows a concrete need. The bots came back exactly that way, once a playtest gate needed them.

Three sources of assets

Some assets I make by hand. Some are marketplace packs, each with its licence on file. And some are built by Claude Opus in Blender, run headless from Python scripts in the repo; the renders come back as images for review, like any other change. Every asset's source and licence is written down, and no image-generation model makes anything: Opus writes Blender scripts, not pictures.

Where the time went

When it felt slow, I had the orchestrator measure instead of guess. More agents wouldn't have helped:

• 16 minutes per full render, and only one Godot runs at a time on the PC.
• 45–66% of an author's time went to Godot, build and verify runs, queueing with the reviewers.
• 3–5 hours per item from brief to merge, when nothing waits on me.
• 1 → 3: one playtest of mine held up three PRs stacked on top of it.

The slow part was one Godot slot, and me.

What I'm changing

Every change keeps every check; it only moves or batches the expensive ones.

• One full render, on the tip that merges. Authors and round-1 reviewers work from the quick checks. That should save 20–40 minutes per PR.
• A merge train. Two or three PRs ride one full render: one 16-minute run instead of two or three.
• Fix the flaky check first. One check failed two runs in three, and each failure cost a 16-minute rerun.
• My questions in one daily batch. No PR waits more than a day for it.
• The next author starts on a clean round 1. As soon as the PR below comes back from round 1 with no blockers, not when it merges.
• Details wait for the playtest pass. Fewer review rounds now.

One cut I refused: dropping the second reviewer in round 1. On one PR, each reviewer found a blocker the other missed.

Spending each model where it pays

Subscription limits are a real constraint when you're solo, so models go where they pay. Claude does the judgment work: Opus orchestrates and writes most of the code, Sonnet reviews code, Fable reviews UI and docs. Grok 4.7 through Cursor gives every PR a second view from another vendor. The Grok Bot is a second lane on its own subscription.

The plan if Claude runs short: authors move to Grok first, reviews stay on Sonnet, and the orchestrator moves last, because it guards the records and the merges. The code reviewer is never the author's model. If nothing is left, the project pauses rather than merging unchecked work.

A bot on its own machine, tried on one task

I gave the Grok Bot one small, real task. It did what I'd want from any author: it planted a bug to prove its new test catches it, ran twice with byte-identical output, stayed in scope, signed every commit, and flagged a gap it couldn't explain instead of hiding it. Review still caught one counting bug in a corner case, fixed in one round, then merged.

To keep me out of the relay, the orchestrator now opens each task as a draft PR it's already watching. The bot checks every 10 minutes and picks it up, and its pushes wake the orchestrator. The guard: the bot acts only on signed lines posted from my account. Everything else on GitHub is data, not instructions.

Lessons that cost me hours

1. Subagents can't ask. A subagent's approval prompt lands where nobody watches, so delegated briefs forbid the calls that need one.
2. Short paths. Windows' path length limit broke a review tool's checkpoints until the worktrees moved to a short path.
3. Test what it loaded. To check what an agent read, ask for a fact only that file holds, not for a quote.
4. Name the author. A bot once read its own picks to me as another agent's. Now every proposal names its author.
5. No silent waits. A helper waiting in the background slept for six and a half hours. Helpers now run in the foreground.

Four things to take home

Decide who decides. Write down what's yours before you hand anything to an agent.

Write the world down first. What the game is and isn't, before the first line of code.

Every claim needs evidence. Every "done" names its command, its output and its file.

Measure where the time goes. For me the bottleneck was one Godot slot and my own answers, not the number of agents.

How do you run yours? I'd like to hear.

Tools and thanks

• T3 Code, the orchestrator and hub for every harness. Thanks to Theo and Julius for it.
• tstack, Theo's PR and review skills, which I borrowed ideas from.
• pstack, Lauren's skill set, which the Grok Bot runs.
• Anthropic on code review, the source of the review loop's rules.
• Anthropic on context engineering, the longer case for writing the world down first.
• Claude Code and Cursor, the harnesses.
• Godot Engine, and godot-mcp-runtime, which lets agents launch the game, take screenshots and send input.

Aleksandr Nariadchikov · @sashanaria