AI Game Development: Build One Playable Loop First

By Lazar Milicevic · Published October 29, 2026 · 7 min read

You have an interactive product idea (a training exercise, a campaign mini-game, a niche tool with game mechanics), but no game dev team and no budget to hire one. Simon Willison just published four AI-built games and called October an inflection point for "vibe game development." Before you act on that, you need to separate the news from the build decision. This post gives you one bounded test to run before you commit real money.

What Willison Actually Claimed (and What He Didn't)

Willison's claim is narrow: AI-assisted game creation hit a new tipping point in October 2026. On October 28, 2026 he wrote that he vibe coded four games he genuinely enjoyed playing over the past few weeks. He compares it to November 2025, which he called the moment coding agents became reliable daily drivers for engineers. On X, he said Claude Opus 5.5 can now build video games that are actually fun.

The four projects are Tree Appreciator, Emberwick, Battle Drones, and Pumpkin Farmer (also called Quarter Sun Cove). Here is what the sources give us about them:

• Tree Appreciator was built in the Claude iPhone app in chat mode, not Claude Code. Claude worked for 3 hours and 7 minutes and returned a spot-the-difference game with music, animation and achievements.
• Battle Drones took 12 major iterations and 321 commits by coding agents, mainly Claude Code, to become a browser game. Willison wrote that he reviewed almost none of the code.
• Quarter Sun Cove was the most ambitious. It used Opus 5.5 Ultracode, burned millions of tokens, and took nearly two days to build.
• According to a summary of the post, none of the four took more than four hours of Willison's own work. Claude Code ran by itself for many more hours.

What the sources do not give us: dollar costs, user counts, revenue, retention, or any evidence of customer demand. These are one experienced engineer's hobby projects. "Inflection point" is his opinion and forecast, and he says he hasn't done an exhaustive study. Treat it as a reason to run your own test, not as proof the category is ready for your business.

Why a Playable Loop Beats a Written Spec

A playable loop exposes weak ideas that a written description hides. An interactive idea needs controls, visual feedback, rules, and a clear result working together before anyone can judge it. A spec can sound great while the mechanic itself is boring.

A playable round answers three questions fast:

• Can someone understand what to do without being told?
• Does the action feel responsive?
• Is there any reason to try again?

For a small agency, this might mean testing a browser game for a client campaign. For a founder, it might mean trying an interactive training exercise before commissioning a larger product. Those are possible applications, not outcomes the article demonstrates. The real opportunity is making an idea testable with a smaller initial commitment.

My take: the useful threshold is when small teams can afford to reject more ideas early. A prototype that reveals a boring mechanic before you've commissioned artwork is a valuable result, maybe the most valuable one.

The Scope Trap: Don't Ask for the Whole Vision

The failure mode is asking an agent to build everything at once: accounts, payments, leaderboards, multiplayer, custom artwork. Every extra system is another way for a promising prototype to turn into a maintenance job. Saving development effort only helps if you spend that freedom testing the right question. Otherwise you've just produced more software to look after.

Battle Drones is a useful cautionary example. It's Willison's most successful project, and it needed 12 major iterations and 321 commits to get there. It also includes audio-based multiplayer. That's a polished endpoint reached through a lot of agent work by someone who knows exactly what he wants. It is not a first prototype. Your first target is much smaller:

The business question is narrower than "can AI build my game?" It's: what is the smallest playable thing that answers whether this idea deserves more work?

The One-Loop Brief and Acceptance Checks

Give your coding agent a brief with a finish line. This is a suggested exercise, not a project I've tested for this post:

Build a single-screen browser game.
- The player moves a basket left and right to catch falling objects.
- Each catch adds one point.
- Missing three ends the round.
- Include restart.
- Use simple shapes. No accounts, no external services.
- Explain how to run it locally.

Then add acceptance checks, because "it launches" proves nothing about the rules:

Acceptance checks:
1. Movement responds to input.
2. A catch counts exactly once.
3. The third miss ends the round.
4. Restart clears both the score and the miss count.

Build and run the prototype in your environment.
Report which checks you actually performed and which you could not.

That last line matters. Agents will sometimes imply they verified things they only wrote code for. Make them separate "checked" from "assumed." Then play it yourself. A successful launch isn't proof the rules work.

Test It on One Human, Then Log Your Own Numbers

After your own playthrough, put it in front of one person without explaining the controls first. Watch where they hesitate. Don't help. Hesitation points are your bug list, and they're usually design problems, not code problems.

Then run a tight repair loop:

1. Name the specific hesitation ("player didn't realize the basket moves with arrow keys").
2. Ask the agent to fix that one problem.
3. Re-run the same four acceptance checks.
4. Keep the scope frozen until the loop makes sense.

The artifact you want is one playable round with observable behavior. Alongside it, record the time you spend prompting, testing, and repairing. That log is the only real cost data you'll have. The sources don't give a dollar total for any of Willison's projects, and I won't invent one. What you can do is price your own run:

• Check Anthropic's Claude Opus page for current Opus 5.5 token pricing before you budget, and confirm the live numbers against Anthropic's own pricing documentation.
• Third-party guides list lower-cost model tiers and batch discounts. Those come from secondary sites, so verify on Anthropic's pricing page before quoting them.
• Opus 5.5 on subscription plans reportedly requires a paid tier, per third-party sources, so confirm your plan's access on Anthropic's site.

A single-screen catch game is a very different token bill from a two-day Ultracode run. Your own time log plus your actual usage dashboard gives you a real number for your scope.

What a Prototype Doesn't Prove

A working loop answers "is this mechanic worth pursuing?" It does not answer production questions. Be explicit about the gaps:

• Code quality and safety. Willison said he reviewed almost none of the Battle Drones code and playtested instead. That's a fine way to evaluate a hobby game. It is not evidence of security, maintainability, or legal safety, and unreviewed code shouldn't ship to customers.
• Demand. Four games someone enjoyed playing says nothing about whether your audience wants yours.
• Reusability. One encouraging data point: Willison released Battle Drones under Apache 2.0, and within a day a French steampunk fork called Panache appeared. That shows output can be reused and remixed, which is worth knowing if you want a starting point to adapt rather than build from zero.
• Distribution. If you were hoping to sell on Steam, note the mood there. Steam Next Fest started October 19, 2026, and players complained it was flooded with AI-generated games and asked Valve for a no-AI filter. Valve's Steam team said at Steam Indie Connect on October 27 that it won't gatekeep AI tools and has no AI filter for now. Counts of AI games in Next Fest vary by outlet and none are primary sources, so I won't quote one. Valve has also published AI-disclosure rules for developers that have been revised since, so read the current Steamworks text yourself before you plan a release.

A browser game for a campaign or an internal training exercise avoids most of the storefront problem. A commercial release on a crowded platform does not.

Where bizflowai.io Fits

I'm a senior engineer who builds AI automations that ship, and the pattern in this post is the same one I use before any build: define one bounded workflow, write acceptance checks the agent has to report against, put it in front of a real user, and log the actual hours before committing a budget. If you've got an interactive or workflow idea and aren't sure it deserves a full build, that scoping-and-test step is a sensible place to start. More at bizflowai.io.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

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

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

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