Battle Drones: AI Built It. Who Decides If It Works?

By Lazar Milicevic · Published November 5, 2026 · 7 min read

▶ Watch the video version of this article

Your admin work lives in the gaps between tools: an invoice arrives by email, someone retypes it into accounting, someone else updates the CRM. An AI-built custom tool sounds like the fix, and a polished demo makes it look finished. A new open-source game from Simon Willison, built mostly by Claude, shows a better way to decide whether the thing actually works.

What Willison Built, and What It Does and Doesn't Prove

Battle Drones is a Command & Conquer-style real-time strategy game that runs in the browser. Simon Willison published it on 20 October 2026 and wrote it up on his blog. According to secondary coverage, it took 12 major iterations and 321 commits, mostly by Claude Code, and Willison reviewed almost none of the TypeScript himself.

The unusual feature is multiplayer. Two devices within microphone range send each other audio messages to keep game state in sync, with no server. Willison chose sound because he wanted static HTML that costs nothing to run and didn't want to be responsible for keeping a server alive. Per his post, the audio version caused headaches, so he added online multiplayer through a stateless WebSocket relay on a Fly.io shared-cpu-1x instance. He estimates that costs no more than $2.19/month, which is his upper-bound estimate, not measured billing. The project README describes the no-network sound duel as an experiment whose link is a constant high-pitched noise many people find unpleasant. He also says the audio multiplayer was very new when published, with little active testing.

So what does this prove? It proves an AI agent can produce a playable, inspectable experiment, with source code you can read. It does not prove reliability for any business workflow. A game that is fun to play and an invoice pipeline you can trust are different claims, and the difference is the rest of this post.

"Make It a LOT More Fun" Worked Because of Measurement

Willison credits one instruction for the game becoming enjoyable: he told Claude, "Make it a LOT more fun." Taken alone, that reads like a magic prompt. It wasn't.

According to secondary summaries of the release notes, the phrase kicked off a long overnight run. Claude ran over a thousand simulated AI-vs-AI playtests and used them to rebalance units. Its own notes report that across 1,200 test matches, games still undecided after 25 minutes fell from 14% to 0.9%, and wins from far behind on resources rose from 24% to 46%.

Treat those numbers carefully. They are the agent's own measurements, read through a secondary summary rather than checked against the primary post. Whether the game is actually fun still rests on Willison's own playtesting.

The lesson transfers cleanly. A vague direction improved the game because there was a loop underneath it: simulate, measure, adjust, repeat. Strip out the loop and "make it better" is just a wish. If you want the same effect on your own tools, you have to build the measurement in.

Where Vague Instructions Work, and Where They Stop

A vague instruction is fine when you can judge the result by looking at it. Tell an assistant to make an invoice screen easier to use and it might reorganize fields, simplify labels, or make the next action clearer. You look at the screen and decide whether it feels better. That's a legitimate feedback loop.

It breaks down when the requirement is behavioral. Tell it to make invoice processing more reliable and you've left the important questions open:

• Does reliable mean it catches duplicate invoices?
• Does it preserve the original tax amount?
• Does it refuse to invent a missing customer identifier?

Those are three different requirements with three different tests. "Make it production-ready" fails as an acceptance test for the same reason: it leaves essential behavior undefined.

My rule of thumb: use open-ended instructions for taste (layout, wording, flow), and exact tests for behavior (what gets saved, what gets rejected, what gets escalated).

Why Handoffs Are Where AI-Built Tools Fail

Producing an answer and completing a business process are different milestones. This is why "we tried ChatGPT" so often ends with "but it didn't integrate with anything."

Consider the typical small-business chain. A customer emails a document. Somebody copies it into accounting. Somebody else updates the CRM. A chat message becomes the unofficial record of what happened. Every handoff is another chance for a manual entry mistake, and later an audit problem.

Hiring another person may be too slow or expensive. Generic software may miss the one detail your niche workflow depends on. So a custom AI-built tool is attractive, and that's a fair instinct. But a polished screen doesn't prove the handoff works. The screen is the easy part. The risk lives in what the tool writes to your accounting system, what it silently skips, and what it does with input it didn't expect.

Battle Drones is a useful model here because it hands you something concrete: a playable version and the source. For your own tool, demand equivalent evidence: the input, the action completed, the saved result, and what happens when the input is wrong.

The One Acceptance Test to Write Before You Build

This is my own framework, not a sourced standard. It's the smallest test I know that exposes most of the failures that matter. Write it before you ask an AI assistant to build anything.

The scenario: a supplier sends the same invoice twice.

The tool must:

1. Create exactly one draft record.
2. Flag the second submission as a duplicate.
3. Show why it was flagged.
4. Wait for a person to approve the draft before anything gets posted.

Set up a small test folder with synthetic data (or redacted real files):

mkdir -p acceptance-test/inbox
# 1. a sample invoice
cp invoice_sample.pdf acceptance-test/inbox/invoice_001.pdf
# 2. an exact copy: the duplicate
cp invoice_sample.pdf acceptance-test/inbox/invoice_001_copy.pdf
# 3. a third version with one required field removed
cp invoice_missing_field.pdf acceptance-test/inbox/invoice_002_incomplete.pdf

Then give your assistant this instruction: build a local prototype that processes these files, records its decisions, and sends incomplete records for review.

Run the files through twice, then check the saved records:

[ ] Did the second run create duplicates?
[ ] Did the incomplete invoice land in the review queue (not silently dropped, not guessed)?
[ ] Can every decision be traced back to its source file?
[ ] Did anything get posted without a person approving it?

A prototype that fails still gives you a useful result: you know exactly which behavior needs fixing. A prototype that passes becomes your first artifact. Only then connect it to your real accounting system, in a test environment, and keep the approval step while you learn what holds up.

What Deterministic Replay Teaches About Auditability

One detail from the Battle Drones engineering is worth borrowing. Replays and lockstep multiplayer need a deterministic simulation, meaning the same inputs must always produce the same outputs. According to one secondary write-up, Claude had to replace Math.sin() and Math.cos() with its own versions because Chrome and Safari return slightly different values.

That's a good picture of how reliability bugs hide. Two environments each produced a plausible answer, and the answers differed in the details. For a game, that desyncs two players. For a business tool, it's the same input giving different outputs on different runs, which is exactly the thing an auditor asks about.

The business version of deterministic replay is a decision log. For every record your tool touches, store the input file, the rule that fired, and the output it produced. If you can re-run the same input and get the same decision, you can trust the tool. If you can't, you have a demo.

The game also supports agent-vs-agent matches that can be recorded and replayed, with the post showing a replay of Claude Haiku 5.5 against GPT-6 Luna. Recording what happened so you can replay it is the same habit at work, and it's one you can apply to any automation you build.

Where I Apply This in Practice

The automations I build for clients follow the same pattern: pick the awkward input first (duplicates, missing fields, odd attachments), define the saved result and the review step, and only then wire anything to live systems. The starting point is always the same: one concrete test, run on bad input. If you want to see how I work, you'll find more at bizflowai.io.

Want more like this?

I'm Lazar Milićević, a senior engineer who builds AI automations that ship, and I share practical AI automation walkthroughs for solopreneurs and small teams.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milićević, senior engineer building AI automations.

Visit bizflowai.io for our services, case studies, and AI consulting.