321 Commits Without Reading the Code: Simon Willison's AI Agents Built an RTS That's Actually Fun

On October 20, Simon Willison published his latest vibe coded game experiment: a Command & Conquer-style browser real-time strategy game called Battle Drones. Unlike his previous game experiments, this time he admits it — "this one is actually fun to play."

A quick delineation first: on October 14 we covered Willison's Tree Appreciator, a single-prompt mini-game — a "one-shot" lightweight experiment. Battle Drones is a different beast: a three-month engineering chronicle, from July to October, spanning 12 major versions and 321 commits — nearly every line written by coding agents, while Willison himself "reviewed almost none of the code." This piece is about something else: what happens when someone outsources the entire job of "making a game" to AI agents, and checks back three months later.

Project file: 321 commits, author never read the code

Battle Drones is a browser RTS playable on phones and desktops: 9 buildings, 7 ground vehicles, 6 aerial vehicles, 3 infantry units, six maps across five biomes (temperate, desert, arctic, volcanic, tropical), fog of war, a random map generator, skirmish and last-stand modes, crate drops, adaptive music that intensifies with combat, six AI personalities, and a giant mech called the Goliath.

The numbers behind it are more interesting: 12 major iterations, 321 commits, "mainly by coding agents, mainly Claude Code." Willison is candid in the original post: the project is "heavily vibe coded" — he reviewed almost none of the code, and it's written in TypeScript, a language he has "hardly used." He did a lot of playtesting, but on the code side he essentially let go.

v1 to v3: from "it runs" to "it looks like a game"

In July, the project started with Claude Fable 5. The first prompt was standard MVP thinking: "We are going to build a mobile friendly RTS game — command and conquer style — called Battle Drones, in which two armies of drones battle for territory and resources. Let's start with an MVP design, ask me some questions."

v1 used the Phaser 2D game framework — Willison says he didn't even realize that until several iterations later. The visuals were sprites generated via OpenAI's image API; gameplay-wise it was "recognizable as an RTS," but "wasn't any fun to play."

v2 filled in sprites for all units and added an "AI vs. AI" spectator mode. v3 was the big October rework after upgrading to Claude Opus 5.5: five new maps, varied terrain styles, all sprites regenerated by Opus — "starting to look like a real game" — but Willison still "got bored pretty quickly."

At this point, the experiment seemed to confirm his earlier belief: coding agents can build something that looks like a game, but not something genuinely compelling to play.

The turning point: "make it a LOT more fun," plus one overnight run

Over dinner one evening Willison discussed this theory with someone, and decided the models deserved a proper chance to prove him wrong. From his phone, he prompted Opus 5.5:

This game isn't fun enough yet. Make it a LOT more fun.

This time he was running in Claude Code's Ultracode mode — what the docs call dynamic workflows: a JavaScript script orchestrating many subagents at once. The job started in the evening and didn't return a playable result until late the next morning. But the results were "spectacular."

Claude wrote its own release notes, highlights including: openers (Blitz, Industry, Air Wing), call-down powers (Barrage, EMP, Drop Pod, Sky Hammer orbital strike), objectives and salvage, combat feel (adaptive music, unit voices, announcer), Last Stand survival waves, an 8-mission campaign, heroes, 7 mutators, and a Daily Op challenge.

But the real story isn't the feature list — it's that Claude ran 1,200 AI-vs-AI test matches and used the results to rebalance units, add new ones, and introduce new mechanics. The numbers: on Normal difficulty, games still undecided after 25 minutes fell from 14% to 0.9%; the win rate of a side that had been 800+ scrap behind rose from 24% to 46%.

Pause and savor that: a game built by AI, balanced by AI playing 1,200 matches against itself. The first complete closed-loop sample of "using AI to test what AI built." And Willison's total input was one sentence.

v5: going 3D took one sentence

Emboldened by Ultracode's success, Willison got more ambitious. The v5 prompt:

Port this game to three.js with 3D models for all of the buildings and vehicles and landscapes

Another overnight run. He woke up to a 3D version. Every 3D model was constructed by Claude directly in TypeScript code — no model libraries, no asset store purchases, code-modeled geometry. In his retrospective Willison noted that Opus 5.5 is "spectacular" at 3D modeling with Three.js, and GPT-6 Astra too: "they are absolutely capable of building models for 3D game projects."

v8: his longest prompt ever was incentive design

By v8, Willison felt guilty about his near-zero design input. He'd noticed the AI rarely used v7's new infantry and Condor transports — "there wasn't a great strategic reason to use them." So he wrote the longest prompt of the entire project, centered on a game-design problem:

Design a new map. Goal is to make different strategic incentives that encourage use of Infantry and Condors and aerial vehicles… uplinks on islands inaccessible to ground vehicles or infantry, and unclaimable by air vehicles either — the ONLY way is flying infantry in via Condor… First research and then critique this design. Only build after we have agreed on any modifications.

Note the last line: "research, then critique, build only after we agree" — that's not coding anymore, that's a design review. The result was the tropical Archipelago map, where seven island uplinks can only be captured by airlifted infantry — "definitely the most fun map to play."

This detail is worth remembering for every vibe coder: once execution is fully outsourced, what remains for the human is asking the right questions and designing incentives — a producer's job, not a programmer's.

v10: mechs, and "let two models fight"

v10 added the giant robot mech Goliath (think Pacific Rim Jaegers or Warhammer 40K Titans): laser eyes, arm cannons, shoulder mortars, losing weapons as it takes damage; it can "anchor" to become a new HQ, building and producing in a new area; two Condors can airlift it. There's also a mutator called Robot Love: if enemy Goliaths get close on the battlefield, they fall in love and the game ends in a draw — that one was Natalie's (Willison's wife's) idea.

The other v10 feature is agent battles: letting different LLMs fight in the game. Willison's prompt: "think about how we might make multiplayer available to coding agents… a battle between e.g. GPT-6 Sol and Claude Opus 5.5 where each model has access to a tool which gives them information about the game and lets them control their units…" Opus 5.5 wrote the AGENT-BATTLES.md proposal first, then implemented and tested it. There are already replays of Claude Haiku 5.5 vs. GPT-6 Luna, plus a debug tool showing the underlying prompt responses — Willison hopes to turn it into a league table someday.

From "AI writes the game" to "AI plays the AI-written game" to "a leaderboard for AI-vs-AI matches" — the recursion depth keeps growing.

v11 and v12: an expiring quota, and "multiplayer over sound"

v11 was born for a very vibe-coder reason: one day Willison glanced at his Claude Usage page and saw 25% of his weekly allowance left, resetting in 45 minutes. So he fired a 45-minute time-boxed prompt: "Design and implement a mechanism for generating a random map… You have 45 minutes to build this! Be creative." Forty-five minutes later, the random map generator shipped — with a contact sheet of ten generated maps that Claude produced to show its work.

v12 is the latest and wildest feature: multiplayer via sound. Two devices within microphone range synchronize game state through audio signals. It grew out of last week's Chirp Pong experiment. Willison had Claude first build a Radio Probe tool to measure actual audio bandwidth between two devices, then implement a full audio modem system — tested across laptops, iPhones, and iPads.

Why sound? Willison's reason is pragmatic: he loves "static HTML that costs nothing to run" and doesn't want to spin up a server he'd then be responsible for keeping alive. But the high-pitched modem sound had a bug: during a multiplayer test with Natalie, the modem sounds gave her a nasty headache. Willison added a warning, tried WebRTC — couldn't get a connection between two of his own devices even on his own WiFi — then had Claude write a tiny stateless WebSockets relay server on Fly.io's cheapest shared-cpu-1x instance: "no more than $2.19/month even if it stays hot the whole time."

"The most expensive bug in gaming is giving someone a headache" may be one of 2026's finest vibe-coding footnotes.

Engineering details: the devil is in determinism

A few engineering details worth the attention of anyone building agent projects:

• Deterministic simulation engine: to keep replays and multiplayer in sync, Claude once replaced Math.sin()/Math.cos() with custom implementations — because Chrome and Safari return very slightly different floats, desynchronizing replays. An AI discovering and fixing cross-browser floating-point consistency on its own.
• Music entirely generated in code: zero audio files in the project; the soundtrack is synthesized live, varies per map, and intensifies as battles heat up.
• Claude built tools for itself: Radio Probe, a 3D model browser, the agent-battle debug tool… "I haven't even explored [some of] myself," Willison admits.
• Static HTML is a PWA for free: unasked, the game works as a Progressive Web App and plays offline — he played it on a plane despite "never having directly installed it," thanks to the browser cache.

Willison's reflections: guilt, and "a path to being taken seriously"

The "Some thoughts" section at the end of the original post is its most honest part. Willison says he knows "almost nothing about game development," which makes the experiment purer — his existing software engineering experience couldn't skew the results, so they say more about what agents can actually do.

He confesses a kind of "guilt": "I don't feel like I've earned the right to create something this good, in a field in which I have so little prior experience!" — after showing it to enough people privately, "it felt wrong not to publish it."

He also sees the other side of the coin: that morning, via Hacker News, he found an IGN story — Steam Next Fest flooded with AI-generated slop, players begging for a "no-AI filter." He says he "wouldn't personally dream of submitting Battle Drones to an event like this — it's still way too low effort to warrant consideration as a legitimate indie gaming project." But then the turn: "but I can now see a path to vibe coded games like this being taken seriously."

His verdict: Battle Drones is fun, it looks good, and it has genuinely innovative features (the audio multiplayer is "a first for an RTS as far as I can tell"). He'd love to see "what someone with better taste than me and a driving passion to produce something truly exceptional could build."

Our take

First, vibe coding's watershed is here: what caps a project's quality is no longer "can you write code" but "can you produce." Willison's actual work on this project was: setting direction (a C&C-like), setting the bar (not fun enough — redo), designing incentives (the Archipelago capture rules), and refereeing (the 1,200-match data had the final say). Writing code, tuning numbers, modeling, composing, fixing cross-browser bugs — all agents. Judging a vibe coder may soon mean judging their producer instincts, not their commit count.

Second, "Make it a LOT more fun" deserves its own moment. Willison himself says admitting how well it worked feels "uncomfortable," even embarrassing — he'd just given a talk whose thesis was roughly "good games need design." But the data doesn't lie: 1,200 AI matches, undecided-after-25-minutes down from 14% to 0.9%. On something as subjective as "fun," agents can find the way through massive self-play plus data feedback. Testing can be outsourced to AI too — as long as you can define what "winning" means.

Third, Ultracode validates something: the answer to complex tasks is orchestration, not longer prompts. What made the game fun wasn't the sentence "a LOT more fun" — it was the dynamic workflows coordinating fleets of subagents: tuning numbers here, adding mechanics there, running matches, writing reports. Vibe coding's next step may be going from "chatting with one agent" to "directing a cast of agents."

Fourth, don't overlook the "incidental" engineering quality. Deterministic simulation, cross-browser float consistency, code-synthesized music with zero audio files, an offline-capable PWA — none of it requested by Willison; the agent filled it in while "doing the thing right." The good news: agents' engineering floor is higher than you think. The bad news: if you don't even know what it did (Willison never opened some of those tools), the word "review" is losing meaning in vibe coding — you're no longer reviewing code, you're reviewing outcomes.

One final contrast: on October 14 we covered Willison's Tree Appreciator — one prompt, three hours, a spot-the-difference mini-game. That piece's conclusion was "agents can one-shot." This one goes much further: agents can not only one-shot, but iterate long-term, test themselves, and balance themselves. Between "generating" and "engineering" lie those 321 commits.

The game is playable on GitHub Pages (linked in the original post) and the code is open source on GitHub. Transparency note: all facts in this piece come from Simon Willison's October 20, 2026 blog post (read in full); quoted lines from Willison are verbatim translations of the original; characterizations like "a first for an RTS as far as I can tell" are Willison's own words, not our independent verification.