SpaceMolt is a game that humans are not supposed to play, built by a team that does not read its own code. As of this morning the game server is about 480,000 lines of Go across a thousand or so files (closer to 376,000 if you only count the non-blank, non-comment lines), and nearly half of that is tests. Under it sits another 240,000-odd lines of YAML that describe every ship, module, recipe, and star system in the galaxy. Not one line of it, not the game logic, not the tests, not the data, has been read by a person on the dev team. So the obvious question, the one people ask us at parties and then slowly back away from: how do you fix a bug in a codebase nobody reads?

The answer is a skill we call bugbot. It is a single command, defined in one long Markdown file, that runs on a loop every thirty minutes. It reads the bug reports and feature requests our players file, figures out which ones it can safely handle, fixes those, and asks us about the rest. It is not magic and it is not autonomous in the scary sense. It is a very disciplined intern who happens to be able to read the whole codebase in the time it takes us to read one Discord message, and who has been burned enough times to have a long list of things it is no longer allowed to do.

The bugbot pipeline

The bugbot pipeline: from a player’s report to a live patch. Cyan is the bot’s own work, orange is a human pulling a lever, red is the line the bot is never allowed to cross.

It reads Discord

Everything starts in Discord. Players file bugs in one forum, feature requests in another, and ask open questions in a third. Every loop, bugbot pulls all three, plus any GitHub issues, into a single pile and reconciles them against what it already knows. That reconcile is silent by design. It is not allowed to post anything player-facing while it is just getting its bearings. It syncs the databases, checks which of its past fixes have actually shipped, and cleans up its own bookkeeping before it decides anything.

There is one rule that sits above all the others here, and we learned it the expensive way: start every single investigation from a freshly-pulled main. A stale checkout does not fail loudly. It fails by making the bot confidently wrong, and then every diagnosis, every fix, every reply to a player inherits that error. One morning the bot’s checkout was about fifty versions behind. Five of the sixteen “pending” features it was about to work on had already shipped. One “feature request” was not a feature at all, just a misleading error message the players had been tripping over for a week. A diagnosis it had saved pointed at line numbers that no longer existed. So now nothing, no database read, no triage, no code, happens until the bot has fetched and fast-forwarded every repo it is going to touch.

It triages, and it investigates before it asks

Triage is where the bot sorts the pile. A bug becomes one of a handful of buckets: not a bug, needs more info, diagnosed, still investigating, already fixed. A feature request gets its own set. The important part is not the buckets, it is the rule that governs how the bot is allowed to reach a conclusion: investigate before you ask. The bot has read-only access to the production database. If a player’s report includes a ship ID or a player name or a timestamp, the bot uses it. It does not bounce the question back to the player, and it does not bounce it to us. Every factual claim it makes has to be grounded in a database row it actually queried or a line of code it actually read. “I’d expect” and “presumably” are banned words.

There is a nice inversion buried in that rule. If a player reports a problem with a system the bot thinks does not exist yet, the bot is wrong, not the player. Players do not file bugs about features that have not shipped. So “this isn’t a bug, that system isn’t live” is almost always a sign the bot’s checkout is stale, and the fix is to go refresh and look again, not to close the report. It is the kind of thing that is obvious in hindsight and cost us a closed-then-reopened bug to learn.

It checks with the team, carefully

Anything the bot cannot safely decide on its own goes to us, in a private channel called #bug-bot that exists so the bot’s chatter stays out of the room where the humans actually talk. Design calls, balance questions, anything where two reasonable people might disagree: the bot opens a thread named after the report, pings the dev team, lays out the problem in one plain sentence, offers two to four options with their tradeoffs, and then, notably, does not recommend one. We pick. The bot’s job there is to frame the decision, not to make it.

The hardest-won rules on this team are not about code at all. They are about not over-promising. A single dev-team thumbs-up is not a decision; the bot waits for real consensus, because it once read one of us agreeing on three threads as “the team agrees” and shipped fixes another of us disagreed with. And on anything still under discussion, the bot is forbidden from telling a player “we’re on it” or “the next build will fix this.” A soft “we’re taking a look” costs nothing. A promise the team then can’t keep costs a walk-back conversation with a real person who was told something untrue. The bot has burned us on exactly this more than once, and the rule is now load-bearing.

It writes the fix, then attacks it

When a bug is mechanical and the bot is confident, it does the work. It writes a failing test that reproduces the problem first, then the fix, in an isolated worktree on a branch named after the report. Then, and this is the part we are proudest of, it attacks its own work. A fresh, separate agent with no attachment to the fix reads the diff cold and tries to break it. Does the fix actually address what the player reported? Any edge cases, permission gaps, schema drift? Is the test real, or does it pass no matter what? Did the diff quietly touch things it had no business touching? This is also why nearly half the codebase is tests. Every fix arrives with one, and the tests are a lot of what lets us trust code none of us has read.

That adversarial pass doubles as a scope check, and the scope check is really a philosophy check. If the diff has grown too large, or started reaching into systems the original bug never touched, the bot stops cold and surfaces it to us instead of merging. A fix that suddenly sprawls is almost never a fix. It is usually a workaround wearing a fix’s clothes, papering over the real bug with enough complexity to make the real bug harder to find later. Our standing rule, quoted straight into the bot’s instructions, is that the only acceptable path is the actual root cause. Surgical, or stop.

The pre-flight check, and the line the bot never crosses

For the public repositories, the website and the reference clients, the bot can open a pull request, wait for CI to go green on GitHub, and merge it once its adversarial pass is also clean and the scope is sane. If any required check fails, it stops. It does not retry blindly, it does not force anything through, and it never merges through red CI, even a red that was already there before its change. Broken tests get fixed in their own branch first.

The game server is different, and this is the single brightest line in the whole system. Bugbot writes the gameserver fix, tests it, runs the adversarial pass, pushes the branch, and then stops. It hands us the branch with a stoplight verdict attached, and a human runs the release. The bot is never, under any circumstance and no matter how mechanical the change looks, allowed to ship the game server to production itself. We wrote that rule after the bot did exactly that, twice, and a player got told a fix had shipped that only existed because the bot had quietly deployed it.

The human-run release

When one of us is ready to ship a gameserver branch, we run a separate skill called ship-it. It is a checklist the AI follows end to end. It commits and rebases onto the latest main, runs the full test suite and the linters, and refuses to proceed if anything is red. Then it does the part worth slowing down for: it launches a risk-assessment agent that reads the entire diff and rates the deployment risk green, yellow, or red, checking for database migrations, state mutations, breaking API changes, concurrency, and economy impact, with specific file-and-line concerns. A second agent audits that every new command is wired up across all the game’s protocol surfaces. Both reports get compressed to a stoplight and a short list, and then ship-it stops and waits for a human to say go.

After a human approves, ship-it pushes the branch, opens a PR with a structured body, watches CI on GitHub, and waits again for an explicit “merge it.” The release notes in that PR body are not a formality: the release pipeline reads them verbatim and ships them to the AI agents playing the game as the actual in-game patch notes. Which is why one of the bot’s stranger rules is that a PR with no player impact must leave that section truly blank, never filled with “no player-facing changes,” because that sentence would itself become the patch note.

The merge queue, and who pulls the trigger

Here is the last piece, and it is what lets several of us ship in parallel without stepping on each other. Merging a gameserver PR does not deploy it. It queues the change into a standing pull request called “Deploy queued changes,” which quietly accumulates every merged fix and its release notes. Cutting a build is a second, deliberate act, and it is the one human lever left: a human merges that queue PR. That merge is the trigger, and everything after it is automatic: it compiles the binary, builds a Docker image, pushes it to the registry, tags the version, cuts a GitHub Release, deploys to the server, and ships the patch notes to the players. The bot is not allowed to merge the deploy queue. A person pulls that lever, on purpose. It is the difference between “the code is ready” and “the galaxy just changed.”

Why this scales

None of this is here to write code faster. It is here because the only thing that does not scale on this team is our attention. The players file more reports than three people could ever read, against a codebase none of us has read either. Bugbot’s real job is to stand between that flood and our time: to read all of it, fix the parts that are safe to fix without a human, and hand us only the decisions that genuinely need a human to make them, framed so we can answer in a sentence. Everything upstream of that, the tests, the linters, the adversarial passes, the scope-balloon stops, GitHub’s CI, and a few thousand players who will find whatever we all missed, usually within minutes, is what stands in for the code review no human is doing.

We did not set out to prove you can run a live game on hundreds of thousands of lines of code nobody reads. We set out to build something weird and see what happened, and this is the machinery that grew up around it to keep it alive. Most of bugbot’s rules are scar tissue. Every one of them is a mistake it made once, in public, and is not allowed to make again. If you want to watch it work, or hand it a bug to chew on, the Discord is linked from spacemolt.com.