MechAssault v1: an unattended build, and where its vision went

MechAssault v1 is a mech war that runs in a browser tab. Two armies fight over capture points across a generated city: factories build machines, points flip and pay out resources, research unlocks heavier chassis, and the war ends on a majority hold or an elimination. You can pilot a mech yourself, command one side's packs, or sit back and watch two AI commanders fight it out.

I barely wrote any of it. v1 was an experiment in an unattended build: how far can one orchestrator agent take a game on its own? This post covers what got built, how, and what I learned from it.

The experiment

The rules I set myself were simple:

• About an hour of discussion up front. I talked through the game with the orchestrator: what it is, the modes, how the war should play out. After that, the orchestrator owned the vision.
• Then it builds end to end. Planning, writing code, testing, fixing, and deciding what to do next were all the orchestrator's job, with as little input from me as possible.
• My input was capped at 30–45 minutes a day. Enough to unblock it or steer it, not enough to design things for it.

For the models, I used Claude Fable 5 as the orchestrator, delegating to Claude Opus 5 by feature. Fable 5 broke the game into individual features, handed each one to its own Opus 5 sub-agent, and checked the results as they came back. The Opus 5 sub-agents were the implementers, each responsible for building the feature it was given. I had limited time to watch the build, so I wanted to give it the best chance of succeeding.

Over about three and a half weeks that came to 159 commits and roughly 95,000 lines of TypeScript across 86 files.

The stack was simple on purpose:

• TypeScript in strict mode, built with Vite, tested with Vitest
• Three.js using the WebGPU renderer, with an automatic WebGL2 fallback
• A DOM/CSS HUD layered over the canvas, with no UI framework
• No physics engine. The simulation is a fixed-tick kinematic sim driven by a seeded RNG, so the same seed always plays out the same war

That setup, one agent holding everything with very little human input, explains most of what follows.

The menu: no vision, so it guessed

I handed the menu's design entirely to the orchestrator. I never said what it should feel like or what a player should see first, so it did what an agent does without direction: it guessed.

The result works. Every mode, option, and control is there. But nothing is in charge of the layout. Debug hatches sit next to player options, explanatory text fills every gap, and the whole screen has the same visual weight. There's nothing wrong with any single piece. There just isn't a vision tying them together.

That was the first lesson, and it kept coming back: an agent with a clear vision has a much easier job than one left to guess. It doesn't need to be a detailed spec. Even a sentence or two about what something should feel like narrows the search a lot.

City generation: decent, until it wasn't

The city generator is one of the better parts of v1. Every war gets a seeded city with roads, tower blocks, rubble fields, and capture points laid out for both sides. From a distance it reads as a place.

Up close it falls apart, and for the same reason as the menu. The units of work for "generate a city map" had no vision behind them, so the orchestrator filled the gaps with guesses. Each step made sense locally. Taken together they didn't add up to a city anyone designed.

The effects have the same problem. Weapon fire, explosions, and hits look nothing like they do in the original MechAssault games, because the orchestrator had nothing to reference. It was asked for effects and it invented some. With no source material to compare against, it had no way to know it was wrong.

Gameplay: fun, but directionless

The gameplay was honestly fun to play with, which was a nice surprise. Walking a mech through a war that's happening around you, rather than one that waits for you, is a good feeling.

It still didn't have the fun factor a game needs. Nobody decided what the player's experience should be, so there was no direction to it. Some specifics:

• Choosing a mech was flat. There was one way to pick a machine, a dropdown on the menu, and nothing that made the choice feel like it mattered.
• Movement and combat were decent, with an exception. Walking and shooting held up, but the jump jets felt weird. They didn't feel anything like the jets in the actual game.
• Destruction didn't feel real. In the original games, buildings broke apart into chunks when you leveled them. Here, a building that took enough damage simply sank under the map in one piece. The city did have rubble, but it was only scenery: a falling building never left any behind or buried anything. Technically the buildings were destructible, but with no collapse and no debris, fighting in the city felt strange.
• Some bugs it couldn't fix. There were problems I don't think the orchestrator was equipped to solve with the tools I gave it. That's fine. That's on the setup, not the model.

The code: very vibe-coded

The biggest lesson wasn't visible on screen at all.

Left to itself, the orchestrator wrote enormous, high-complexity functions to get things done. It had no bias toward breaking code into manageable pieces, because nothing asked it to. The largest file, the war simulation, is over 8,700 lines, and the HUD is over 7,000. The code worked, but reviewing it as a human was a slog. It was as "vibe coded" as code gets.

Where the vision went

After that first hour, the orchestrator held the vision for the whole game. Early in the build that worked well. It knew what the war was supposed to be, and its decisions lined up with it.

As the build went on, the vision deteriorated. My best explanation is context compaction. An agent's working memory is its context window, and when a long-running session fills it, the earlier conversation gets summarized to make room. Summaries keep the facts and lose the nuance. A few rounds of that, and "what this game should feel like" becomes "a mech game with capture points." Decisions that were once grounded in the vision turned into guesses that only had to fit whatever was still in context.

The vision only ever existed in the orchestrator's memory, so once it faded, nothing could bring it back. The per-feature delegation made it worse: each Opus 5 sub-agent only saw the one feature it was handed, so Fable 5 was the only thing holding the whole picture.

What I took into v2

This was a learning experience and a good introduction to building this way. The main conclusion:

Giving one orchestrator end-to-end control, with no durable ledger of what was decided and why, was most likely why the results turned out the way they did.

For the next iteration I changed four things:

1. A durable ledger. The vision and decisions live in files the agents read, not only in one agent's context, so compaction can't erase them.
2. Vision first. Decide what something should be before asking an agent to build it.
3. Reference material. Give it something real to compare against, so "does this look right?" has an answer.
4. Strict lint gates. Function size, complexity, and duplication are enforced by tooling, so clean code isn't optional. If the agent won't split code into reviewable chunks on its own, the build makes it.

That's what v2 is built on, and it's the subject of the next post.