Ship a Playable AI Game in Ten Evenings: Demo First

You have a short evening, a browser tab open, and a game idea that feels bigger than the weekend. A developer asked Claude Code, a coding agent, for a Cannon Fodder prototype on Saturday night and had a game hosted on Render by Sunday lunchtime. Keep the scope small enough to play before the next work week starts.

A ten-day AI side project stays a side project when the playable demo sets the scope and every repeated agent failure becomes a short reusable skill.

The demo decides the scope

Write the smallest playable slice before you write a roadmap. For a browser game, that might be a small screen, a simple enemy, a score, and a restart. Done means a stranger can open a URL and play for a short time without instructions. If the agent keeps asking for architecture, give it the objective, not the method. In Anthropic's engineering work, Claude can solve an under-specified problem when people give it the objective rather than the approach.

An early prompt names the loop, the controls, and the failure state. Say what the player does, what the enemy does, and what ends the round. If you do not know yet, ask for a few tiny variants and pick a favorite. The demo should be embarrassing in its simplicity, but it must run. Keep the early prompt short: name the file, the loop, and the thing that must work. If the agent starts explaining options, answer with the smallest playable version.

In the example run, the first commit showed up by 7 a.m. the next morning. A URL on Render was live by 10:30 a.m. on Sunday. Use those as the Sunday checkpoints.

Prompt Saturday night in Claude Code for a prototype.
Make a playable demo by Sunday.
Freeze scope after the demo works; new features go into a notes file, not the codebase.
Write a skill for each repeated failure, so a short command fixes the same mistake again.
Port from an old repo only after the demo works; old code becomes a source of parts, not the plan.
Log commits and requests in a file that records what you asked, what broke, and what shipped.
Deploy by Sunday lunchtime.

Repeated failures become reusable skills

A skill is a short, repeatable instruction for a failure you have already hit: broken build, missing asset, bad deploy, flaky test, ugly commit message. When the agent fails the same way again, the fix belongs in a skill, not in your notes. By the end, the build had 17 Claude Code skills, including /commit and /release, both requested on the first morning. If you need a starting point, Orangebot.ai's skills page lists more than 2,000 Claude Code skills, showing popularity metrics, repository stars, topic tags, install steps, and origin filters.

A skill should be small enough to test in an evening. Name it after the failure, not the feature, and update it when the fix changes. The trap is rebuilding the harness after every crash. The developer estimated that rebuilding the AI harness from scratch ate up about half of the ten-day build. A harness is the wrapper that lets the agent run, test, and deploy your game. Make it boring: a command to run, a command to test, a command to deploy. If the harness is fragile, the game never gets finished. If tempted to redesign it, log the reason before acting.

The side project ends when the demo is shared

The span of tasks AI systems can finish reliably on their own has been doubling about every four months, faster than the earlier seven-month trend. You can ask for bigger chunks, but only if the chunk has a clear done state: a URL that loads, a test that passes, or a level that can be finished.

When the ten-day window closed, the finished game, Boots & Bullets, included a 50-mission campaign, built-in analytics, two-player multiplayer, and a zombie horde mode. The side-project finish line is the playable demo, not the final feature list. Most side projects stay side projects, and that is fine. When the URL works, stop, share it, and leave the next feature for later.