Personal project · not affiliated with AWS

Building a game with a team of AI coding agents

Dungeons & AI is a browser role-playing game I built as a personal project in 2026, with AI coding agents writing the code. The engineering problem was keeping many agents from breaking one codebase. I designed a task board, file claims and a test-gated merge queue that made parallel AI work safe to land.

A cutscene from the game's trailer: the party faces something rising from the water in a flooded hall. Captured from the game engine.

The project

Dungeons & AI is a fantasy role-playing game that runs in a web browser. It has a world map, towns, dungeons, turn-based battles, and online co-op with voice chat. I built it in 2026 as a personal project. It has been publicly playable since September, and about two months of active development landed more than 4,000 changes.

Silent video montage of a fantasy game: a cave lake with a waterfall, a torch lighting a dark passage, a mine trestle, the world map, a town, then battles against a fire-breathing drake, a troll, an ice dragon and an ink-splashing monster. — Fourteen seconds of Dungeons & AI, captured from the game engine: exploration, then battles. Scenes were scripted for capture. Open the clip as an MP4 file

The problem

I wanted to find out how far a small effort could go if AI coding agents did the implementation. Writing code with one agent is easy. The hard part comes when many agents work on one codebase at once. Two agents edit the same function. One agent's change breaks something another agent depends on. A change looks finished but was never merged. Without structure, more agents mean more collisions, not more progress.

My role and team

I was the product owner and the designer of the development workflow. I decided what to build and in what order. I answered the agents' questions about design and scope, and I published every release myself. I didn't write code by hand: all of it was written through AI coding agents that I directed. Most were Anthropic's Claude, with OpenAI's Codex as a second worker and reviewer. xAI's Grok, Leonardo, PixelLab and ElevenLabs generated the art, sound and music. My son helped a little along the way.

Approach

I designed a task-and-merge system, called Hive, and had the agents build it:

Every request becomes a task. Each task is assigned to an agent working in its own copy of the repository, on its own branch.
Agents claim before they edit. An agent claims each file before it changes it. If another agent holds the file, the edit is refused and the agent has to coordinate or wait. Ordering-sensitive code, such as dialogue whose branch order is story order, is claimed explicitly.
One merge gate decides what lands. It merges one task at a time. It brings in the latest main branch, runs the tests affected by the change, and only then fast-forwards main. Full test suites run nightly.
Decisions come to me in a fixed shape. When an agent needs a decision, it asks with five options, from the safest to the most contrarian, plus a recommendation. Routine choices are decided and recorded without me.

Simplified diagram, not a live view

Request human

Assign automated

Build AI agent

Report AI agent

Merge gate automated

← merged to main Nightly check automated

Publish human

Build → Request: question for Charles (decision point)

Merge gate → Build: tests fail, conflict or file held: back to the agent

Nightly check → Assign: failing suite becomes a new bug task

Merge gate → Publish: Charles decides when to publish

How work moves through the project, simplified. A conceptual diagram, not a live view.

Text version of the diagram

How work moves through the project, simplified into seven stages. 1. Request: Charles describes what he wants, and a coordinator agent turns it into a task. 2. Assign: the task goes to an AI coding agent working in its own copy of the code. 3. Build: the agent claims the files it will change and implements the change; when a decision belongs to Charles, it asks him a question with five options and a recommendation. 4. Report: the agent files a completion report listing tests run and checks still owed. 5. Merge gate: one task at a time, an automated gate brings in the latest code, checks file claims and conflicts, and runs the affected tests; if anything fails the task goes back to the agent, otherwise the change lands on the main branch. 6. Nightly check: every test suite runs overnight, and each failure becomes a new bug task. 7. Publish: Charles decides when to publish, first to a beta site and then to the public site. Limits: the gate does not review each change's code, and rollback is manual.

Engineering decisions

Tests gate merges; manual checks don't. Phone and browser checks are listed for a person to do after a build is published. Automated tests decide what merges. That kept work flowing without pretending manual testing had happened.
The gate is the backstop, not the editor hooks. The file-claim hooks let edits through if they themselves fail, so a broken hook never freezes all work. The gate then catches conflicts before anything lands.
Tooling serves the product. When building the orchestration tooling began to crowd out the game itself, I ended the tooling sprint. After that, the tooling could change only to unblock game delivery.

Outcomes

A working game. Dungeons & AI is a playable game in the browser, with exploration, battles and online co-op, built by AI agents working in parallel under one process.
A worked example. One evening I asked for co-op partners to be shown holding the weapons and shields they had equipped. An agent took the task and found that another agent held a file it needed. It flagged that and kept working on the parts it could change. It landed the change through the merge gate the same evening, with tests that send the new data through the real cloud code.

Historical example, reconstructed

Historical example, reconstructed from task records and version history (sanitized). Not live telemetry.

Request: Charles asks for co-op partners to be drawn holding the weapons and shields they have equipped.
Assign: The task is assigned to an agent.
Build: The agent finds that another agent holds a file it needs. It flags this to the coordinator and keeps working on the parts it can change.
Build: Once the file is free, the agent adds the new data to the cloud API and tests the full round trip through the real cloud code.
Report: The agent files its completion report, listing the checks still owed.
Merge gate: The gate runs the affected tests and merges the change to main the same evening.
Publish: Publishing the cloud API half is left to Charles as an explicit action item.

Uncertainties

Whether the cloud API half was later deployed is unknown.
Simplified: intermediate steps are omitted.

How the process works, stated plainly:

I make the product decisions and run every release.
The gate checks tests, file claims and conflicts. It does not review each change's code.
Rollback is a manual step.

Painted cutscene: a pale-haired figure in a long purple cloak stands among ruined stone columns at night, watching a small party with a torch walk a moonlit road through a forested valley. — A cutscene from the game's trailer: someone watches the party from the ruins above. Captured from the game engine.

Decision records

DR-1 — Serialize merges, parallelize work

Constraint:: many agents commit to one codebase, and any of them can break another's assumptions.
Choice:: agents work in parallel in separate worktrees, but landing goes through one gate. The gate holds a lock, merges the latest main into the task branch, runs the impact-selected tests, and fast-forwards main only on green. Otherwise the task goes back to its agent.
Tradeoff:: landings queue behind one another, and the gate runs only the tests a change affects, not every suite. To make up for that, full suites run nightly and file a task for anything that needs attention.

DR-2 — Claims instead of locking the whole repository

Constraint:: most edits touch different files, but a few shared areas break when merged blindly. Dialogue whose branch order is story order is one example.
Choice:: An agent's first edit to a file claims it.

Shared functions are claimed explicitly.

A conflicting edit is refused.

The hooks let edits through when they themselves fail, so the merge gate remains the backstop.
Tradeoff:: a claim left behind can hold up work until it is released. Changes made through shell commands are not claimed automatically.

DR-3 — A field must survive every hop of the co-op wire

Constraint:: co-op data passes through three filters: what a player sends, what the cloud API keeps, and what the other player's game accepts. A field left out of any one of them disappears silently.
Choice:: wire tests run the real cloud API code between two simulated clients, and the exact set of fields is pinned in tests on both ends.
Tradeoff:: every new field means updating several tests on purpose.

Capabilities this project best demonstrates

Designing guardrails for parallel AI work. I designed the claims and the serialized, test-gated merge that let many agents change one codebase safely.

Example: the worked example.

What a hiring manager learns: Charles treats AI agents like a team that needs process, ownership and integration controls, not like a code generator.
Owning product direction and tradeoffs. He set what mattered, made policy decisions, and redirected effort when the tooling began to crowd out the product.

Example: the decision to end the tooling sprint.

What a hiring manager learns: he can spot when an engineering investment stops paying off and change course.
Building verification into the workflow. Tests gate merges, suites run nightly, and manual checks are tracked instead of assumed.

Example: the co-op wire tests (DR-3).

What a hiring manager learns: he cares whether something actually works, and he is plain about what the process does and doesn't do.

← Return to selected work