The Arcade That Builds Itself: Three Hundred AI-Built Games as a Test Bed for Autonomous Agents

Most of what we write about on this blog is enterprise work: a chemicals distributor's order desk, an energy operator's production accounting, a Knowledge Bank that compounds what a team learns. The agents behind that work are the same agents behind something much less serious. Whimcade is a browser arcade where anyone can wish a game into existence: describe it in one paragraph, press Make my game, and an autonomous build agent writes it, tests it and emails you a link when it is ready to play. There is no designer, no reviewer and no ticket. The arcade now holds more than three hundred games, almost all of them built that way, and it has become the most honest test bed we have for the question that matters in the enterprise work too: what does a build agent actually ship when it is on its own?

Why an Arcade

A game is an unusually unforgiving deliverable. An internal tool can be a little broken and still be useful; a game that drops an input or freezes after the second level is simply abandoned, and the player tells you so with a play count of one. Games also need everything at once: logic, rendering, controls that work on a phone, art, sound, a title screen, a difficulty curve. If an agent can take a paragraph from a stranger and turn it into something a child plays for twenty minutes, we learn far more about its judgement than we do from a benchmark.

The other reason is that the people judging are not our clients. Enterprise feedback is polite, scheduled and filtered through a project manager. Arcade feedback is a stranger in a lobby chat saying the boss is unfair. We wanted that signal, and we wanted it on the same build agents, the same platform and the same validation rules we use for paid work, so that what we learn transfers.

What Happens After You Press the Button

The wish goes into a queue on the arcade's side and arrives at our platform as a webhook. The platform starts a fresh virtual machine for that one build, drawn from a warm pool during busy hours so the agent does not wait for a boot, and launches a Claude Code session on it with a single job: build this game. The session has no credentials of any kind. It cannot reach our databases, our cloud project or our secrets. If it wants art it asks an asset gateway, which buys sprites, 3D models or voice lines on the build's behalf and keeps the bill with the build.

The agent writes one file. A Whimcade game is a single self-contained HTML document: every script, style, sprite atlas and sound is inlined, and the file may not make a network request or touch browser storage at play time. The arcade enforces that twice, once when the bundle is delivered and again every time it is served, because a rule that is only checked once drifts. The game runs inside a sandboxed frame with a strict content security policy, so a bundle that tried to phone home could not, and a bundle that tried to escape the frame would find nothing to escape into.

Before it delivers, the agent plays its own game. It serves the file over loopback, opens it in a real browser through Playwright, and checks it at desktop size and in a 329 by 400 pixel phone frame: the title screen renders, the first input starts the game, the screen changes after that input, the console is clean, and the only request on the network panel is the page itself. Only then does it post the bundle, a thumbnail it took during play and a metadata block (title, description, controls, tags) back to the arcade over a signed callback. The build lands as a draft that only the creator can open, and the creator decides whether to publish it. Every state change along the way is a row in an audit table, so when something goes wrong we can read the whole story.

The Rules Live With the Arcade, Not With the Builder

The decision that aged best was splitting the prompt by role. What a Whimcade game must be is the arcade's business: self-contained, original intellectual property, built for a phone first, with a completion signal so the arcade can award a finish, a high-score hook, a save relay for progress, and a specific contract for other players. Those rules are rendered by the arcade and sent with every build job as a payload field of about twelve kilobytes. Our builder harness never sees them until the job arrives. It knows only how to validate, how to deliver, how to report its own token usage, and how to stop cleanly if the job was withdrawn while it was working.

That means a rule change is an arcade deploy, not a prompt edit on our side, and the rule the agent followed on any given build is recorded in the dispatch event for that build. When a game from September behaves differently from one built today, we can diff the rules they were given rather than guess. This is exactly the shape we want for enterprise agents too: the client's policy travels with the job, and the harness is a dumb, auditable executor of it.

Other Players Without Promising the Impossible

The hardest rule to get right was multiplayer. A wish that says me and four friends or a twenty-four player lobby is common, and an agent that takes it literally will promise online play it cannot deliver from a single file in a sandbox. So the rule is layered. Any roster the wish describes is built as the creator's own seat plus bots filling every other slot, with readable behaviour and an honest title screen (You vs. 12 bots). A wish for exactly two people may also offer same-device play, two key clusters on a keyboard or split touch halves on a phone, alongside solo, never instead of it.

Real online play exists, but only when the wish asks for other real people. The arcade puts two to eight visitors in a room and holds the connection on the player page; the game itself still makes no network requests and speaks only through messages to its frame. The agent does not write that protocol. It fetches the arcade's networking kit at build time, pastes it verbatim into the bundle, and wires a handful of calls: run the simulation only when you are the host, render from interpolated snapshots when you are a client, and fall back to solo with bots the moment the room closes. Every bundle declares which of the four modes it honours in a meta tag, and the delivery check loads two copies of an online game under a mock room to confirm the host actually broadcasts.

What Comes Out

The range still surprises us. A few from the current catalogue, each one a paragraph from a visitor that an agent turned into a finished game:

• Ashfront: Europe 1939, a grand-strategy map of 675 real provinces where one second is one day, with a mode that follows the historical war and another that turns every nation loose until one survives.
• Hollowpine: Leave Together, a co-op first-person horror escape through a pine-hedge maze. Up to four players online, bots filling the empty seats, and a creature that from the second level mimics your friends' voices. Because the sandbox has no microphone, the agent gave each hiker six recorded callouts and a whisper channel for the caught.
• Dinosaur Park Tycoon, a 3D resort builder across three islands: lay paths, fence pens, hatch a Tyrannosaurus, fix the fence it broke, and keep the guests calm.
• The Midnight Casebook, three murder mysteries in a flooded manor, a night sleeper train and a lighthouse, where you press witnesses until a lie cracks and must name the killer with proof before dawn.
• Slamstorm 2v2, two-on-two arcade basketball with trick dunks against bot squads on a sunset harbour, a neon rooftop and inside an erupting volcano.

None of these had a human touch the code. The visitor's paragraph is the whole specification, and the agent's reading of it is the whole design process. That is also the point at which the enterprise parallel stops being a metaphor: a one-paragraph brief, an agent that has to decide what the brief meant, and a validation gate that only checks what can be checked mechanically. The interesting failures live in the gap between those two.

Measuring Whether They Are Any Good

A build that passes its own gate is not the same as a good game, and we did not want to take the agent's word for it. So we ran the study you would run for any autonomous code generator. We took thirty random fresh builds, recovered the agent's first draft of each from its transcript, kept the bundle it actually shipped after its own validation pass, and handed the same first draft to a separate QA session on a different model with a checklist and no knowledge of the design intent. Then a blind reader compared the versions change by change with the sides shuffled.

Two things in that table changed how we think. First, the mechanical gate is necessary and nowhere near sufficient: all three broken drafts were trivial (a syntax error, two invalid colour strings) and every version passed it, yet the versions differed by dozens of bugs a player would hit. Second, the agent's own validation pass, which plays the game it just wrote with the intent still in its context, caught far more than an independent checker that only had rules. The checker spent most of its edits on rule drift and test hooks and, in seven games, showed desktop players a touch interface. A second pair of eyes is only worth having if it plays for correctness rather than compliance, and that is as true of a QA agent as of a QA contractor.

We also learned not to trust a rubric judge. The model that scores a bundle against a rubric gives nearly every current build a 9.5 or better and cannot tell two generations of the same model apart. Blind human play can. So our model comparisons now run through the real pipeline as unlisted evaluation games, with a same-day control arm, because the arcade ships rule changes often enough that comparing against last week's builds measures the rules rather than the model. And when we built a full post-build QA stage, measured that it added about twenty minutes and two thirds of the model cost per game for two or three fixes, we did not turn it on. The owner's ruling was that we first needed a way to see whether quality is a friction point for players at all. It sits deployed and off, with a dashboard waiting, which is the right place for an expensive improvement nobody has yet asked for.

Capacity Is a Queue, So We Modelled It as One

Each build occupies one machine for the length of a session, so the arcade's throughput is a plain queueing problem and we treat it as one. The number of builds in flight is a lever on the arcade, under a concurrency ceiling on the platform, and an Erlang-C table tells us what a given demand means: below the ceiling the wait is effectively zero, a bit above it the wait is under a minute, and well above it the queue is unbounded until the burst passes. A creator video that sends a few hundred visitors turns into a few dozen wishes spread over hours, which is nothing. A viral day is a few hundred wishes, which now fits under the daily cap and drains the same day. The warm pool exists because a cold machine boot was the largest fixed cost in every build, and the pool was sized from the same table.

The reason this is worth writing down is that none of it is special to games. Any agent fleet that does one job per machine has the same curve, and most teams discover it the day the queue goes unbounded. Measure the service time, pick the concurrency, and write the table down before the burst.

What It Taught Us About Enterprise Agents

The arcade is the lowest-stakes place we could put the highest-stakes question. Four lessons carried straight back into the client work:

• Policy travels with the job. The rules an agent must follow are rendered by the system that owns them and sent with each task, versioned and recorded, so the harness stays generic and the audit trail answers "which rules was it given?"
• The agent tests its own work in the real runtime, with intent still in context. That pass found more real bugs than an independent checker with a checklist, and it is cheap because the agent already knows what it was trying to do.
• The mechanical gate is the floor, not the bar. Boots-clean, no console errors, no network calls: every build should clear it, and clearing it says almost nothing about whether the result is good. The bar is a human playing, or a human's correction, which is why our enterprise loop keeps a person at the gate where it matters and turns every correction into a lesson.
• Do not ship an expensive improvement until the problem it fixes has shown up. The parked QA stage is the discipline we try to keep everywhere: build the measurement first, then decide.

The arcade also runs on the same economics we would want a client to see. Wishes cost gems, gems are earned by playing other people's games, and the subscription is a modest monthly allowance of them, so every build is paid for by the attention the arcade generates rather than by a budget that quietly runs out. Our own port of The Dark Stair, the roguelike we wrote about earlier this year, now lives there as a featured game and passes the same gates as a visitor's wish, with no exceptions carved out for the house.

Go and Wish One

The quickest way to understand what an autonomous build agent is like to work with is to give one a paragraph and see what comes back. Whimcade is free to try: play a few games to earn your first wish, describe something, and read the build notes the agent leaves about the choices it made. Then imagine the paragraph was a process in your business instead of a game, and the delivery was a workflow instead of a bundle. That is the work we do, and the arcade is where we rehearse it in public.