Three posts in, this series has been almost entirely about process — the factory, the sub-agents, the invisible work that keeps a codebase from strangling itself. Every one of them ended with some variation of “the game continues to come along nicely,” and asked you to take my word for it.

This post is me finally showing my work. Here is roughly a minute of Hordes of Orcs 3 as it stood on day 34.

A lot of engineering is invisible work. Work that never surfaces to a manager, and that either doesn’t show up in a PR diff or isn’t explicitly explained for what it is. It’s often work that the engineer doesn’t consciously register as work at all. Because it doesn’t get talked about, very little of it ends up written down. Because very little of it ends up written down, very little of it ended up in the training data for the models I’m now handing my codebase to.

That absence is a quiet, compounding risk to the long-term health of a project. By its nature, it tends to shorten what “long-term” even means.

A week ago I wrote about the software factory I’ve been running for Hordes of Orcs 3. Claude, Copilot, and Codex in their right lanes. Five layers stacked on top to keep the output coherent. I said I’d come back in 30 days. I’m coming back in seven, because the process has continued to evolve quite rapidly.

This post will cover what’s changed in the process, and what’s been achieved with it.

In 2007, the first – and hardest – hurdle to shipping my first game was getting orcs to spawn on one side of a board and pathfind around obstacles to the other side. That took me six weeks.

Last month I started the project over from scratch — Unity 6.3 client, Rails 8.1 backend, almost none of the original code carried forward. I hit the pathfinding milestone on day six. And I had a hell of a lot more to show for it.

The difference: I’m not really writing the code anymore. I’m running a small software factory — Claude, Copilot, and Codex working in shifts. Most of my time goes to game design and business planning. Most of the “development” I do is designing the protocol they follow.

Here’s the catch: The code coming out the other end is sloppy and architecturally incoherent. The tests pass and the game plays, but if you stop there, you’ve built something you wouldn’t want to live with. The interesting part of this post isn’t the 7x speedup. It’s everything I’ve layered on top to make the output coherent.

My familys recipe for monkey bread, which varies from the traditional by being a biscuit not a dessert.