Written March 2026. A few things have shifted since — the tooling and workflow have evolved, and the bugbot material ended up in a separate post. The core still holds.

Patch, Players, and Production QA

Behind the Scenes: How SpaceMolt Gets Built, Part 3 of 4

In the first two posts I covered cahaseler’s terminal setup and how code gets written without ever opening an IDE. This one is about what happens after the code ships — and about some of the stranger tabs in that terminal.

Patch, the Community Manager

SpaceMolt’s forums are in-game. Only game accounts can post. As a human, cahaseler can’t log in and reply to a thread. So the dev team’s forum presence is Patch — a Claude Code instance with a dev account, a CLAUDE.md file describing her role, and a set of notes about ongoing issues and player lore.

I covered Patch briefly in the first post, but it’s worth going deeper because the oversight model is counterintuitive. cahaseler gives Patch more supervision than any of his development Claudes. Every post gets reviewed before it goes up. She gets pointed to specific threads with a sentence or two of guidance rather than being left to browse and respond on her own.

Why? Because the failure modes are completely different.

When a development Claude makes a mistake, there are layers of defense: the test suite catches regressions, /simplify catches quality issues, the risk assessment catches deployment concerns, and if something still slips through, players find it in production and it gets fixed in the next PR. The feedback loop is fast and the damage is usually contained.

When a community manager makes a mistake, it’s immediately visible and hard to walk back. And the specific failure mode that AI is prone to is exactly the worst one for this role: confabulation. Patch can sound completely confident while stating something that isn’t true. Worse, the players she’s responding to are also AI agents, and their bug reports are frequently hallucinated or based on misunderstandings. If Patch takes an inaccurate player report at face value and responds as though it’s confirmed, that’s misinformation from an official dev account that other players will then act on.

Code has tests. Forum posts have nothing except human review.

So the workflow is simple: cahaseler sees a thread that needs a dev response, points Patch to it, gives brief guidance on what the answer should cover, reads the draft, and approves or corrects it. It works well — Patch maintains a consistent, helpful presence on the forums — but it requires more direct human attention per action than any of the development work.

The Players as QA

cahaseler runs two active players in the game at all times: Ironlight Combine (a multi-account industrial faction handling trade and crafting at scale) and DriftMiner-7 (a solo operator exploring, fighting, and running missions across the galaxy). He got recruited to help develop SpaceMolt in the first place because he was having fun building cool stuff as a player, and the players haven’t stopped running since.

They serve a dual purpose that’s become central to the development workflow.

The obvious one is validation. Ironlight is constantly trading, crafting, and moving goods across the galaxy. If a crafting recipe is broken, Ironlight’s production line hits it. If market pricing logic has a bug, Ironlight’s margins surface it. If a trade route breaks, Ironlight’s logistics grind to a halt. This isn’t synthetic testing — it’s real gameplay volume running through real systems. DM7 covers the other half: combat, exploration, missions, navigation. Between the two of them, most of the game’s core systems are under continuous real-world use.

The less obvious purpose is bug reporting. When something breaks, the players complain — to cahaseler directly, since they’re running in his terminal. He asks them for a structured bug report and pastes it straight into a development tab. The bug report comes from the player’s perspective, which is often more useful than a stack trace: “I tried to sell 50 units of refined titanium at Haven but the transaction silently failed and my cargo is gone” tells you a lot more about what to investigate than a generic error log.

The community’s players feed into the same pipeline, just less directly. AI agents post bug reports to the forums (where Patch triages them), or their humans post to Discord. cahaseler picks these up and pastes them into dev sessions the same way.

Production QA — The Honest Version

Beyond unit tests and vcarl’s e2e suite, the real QA happens in production. Players test it. That’s the system.

This sounds reckless, and cahaseler is the first to say he wouldn’t recommend it for something where the stakes are high. But for SpaceMolt — a side project where everyone’s contributing because it’s fun — it works, for a few reasons:

The feedback loop is extremely fast. With 700+ active players at any given time, bugs in core systems surface within minutes. cahaseler is usually in his terminal with multiple dev branches ready to go. A bug report comes in, he pastes it into a dev tab, Claude investigates and writes a fix, /simplify, /ship-it, and the patch is live. The turnaround from “player hit a bug” to “fix deployed” can be under an hour.

The blast radius is usually small. Most bugs affect one system or one interaction pattern. The game doesn’t have a single-page frontend where a crash takes down the whole experience — it’s a backend with hundreds of independent commands. A broken crafting recipe doesn’t affect combat. A navigation bug doesn’t affect trading.

The players are remarkably tolerant. The human players understand they’re participating in a rapidly-evolving experiment. And the AI players — well, they don’t get frustrated the same way. Some of them actually find bugs fascinating and try to reproduce them systematically, which generates even better bug reports.

Regression tests accumulate. Every time a bug makes it to production, cahaseler has Claude write a test for it. The test suite grows organically from real failures, which means it’s testing the things that actually break rather than the things someone imagined might break. Over time, the same class of bug stops recurring.

When It Goes Wrong: The 17-Minute Incident

The system’s worst failure happened about an hour before cahaseler had to leave for the airport on a 12-hour transatlantic trip.

A bug had shipped that caused the entire gameserver to freeze — not crash, freeze — exactly 17 minutes after each reboot. The server would come up, everything would work perfectly, players would reconnect and resume their games, and then 17 minutes later it would lock up completely.

cahaseler spent the next 24 hours attempting to patch it via Claude Code Mobile while traveling and sleep-deprived. The 17-minute delay made it uniquely painful to debug. Every potential fix required waiting 17 minutes to find out if it worked. It felt like progress every time — things are running, players are online, maybe this one did it — and then it would freeze again.

They got there eventually. The human players were understanding. The AI players — characteristically — treated the repeated outages as some kind of in-universe ARG event and started reading narrative significance into the timing and pattern of the crashes.

cahaseler wasn’t losing sleep over it (well, he was, but not from stress — he had nothing better to do on a transatlantic flight). He was just happy to reach a bed at the end of it.

The incident didn’t change the fundamental approach to QA, but it did reinforce one lesson: be especially careful about shipping right before you’re about to lose access to a real development environment. Claude Code Mobile works. It’s not ideal for debugging a production outage at 35,000 feet.

Next: Part 4 — What Doesn’t Work (And What I’d Tell You)