Four games, four prompts

Before Claude for Games in San Francisco, I wanted a demo that answered one question in under a minute: how far can one prompt go?

So I gave Claude Opus 5.5 four prompts at max effort, one per game. A platformer, a roguelike, a physics game and a WebGL racer. Each one came back as a single HTML file you can play in a browser. They're at claude.rich/games: Wharf Pup, Escape the Rock, Sourdough Slingshot and Hill Bomb.

The biggest one, Wharf Pup, is 184 KB. The original Super Mario Bros. fit in 40 KB.

That comparison does more in a talk than any benchmark. Nobody needs to know what a token is to understand that a whole game now fits in one prompt and in a file smaller than a photo on their phone.

A demo is a promise

At a Build Day the demo isn't the show. It's a promise about what the room can build in the next two hours. If the demo needs a team of engineers, the promise is false, and the room knows it.

One prompt is a promise people can check. They can read it, change one line and run it themselves. That's why the prompt goes on the slide, right next to the game.

Show the receipts

Every game went through a QA pass before it went on stage: scripts that load the page, play it for a while and take screenshots, so I knew all four worked before they hit the big screen. Then the four games went public, so anyone in the room could open them on their phone during the talk.

A demo you can't touch afterward is a magic trick. A demo you can open, play and fork is documentation.

The format does half the work

Build Days in Santa Cruz de la Sierra, Mexico City and San Francisco taught me a simple run of show:

• A short intro with one live demo
• Teams form
• One long, uninterrupted build block, with people walking the room to help
• One-minute demos, for everyone who wants one
• Group photo

The build block is the event. The one-minute demos are the reward. Everything else should get out of the way.

At the Claude Community House in Mexico City we stretched the format to a full day: ten workshops, building in between, and demos at night.

Games are the best teacher I've found

Games are a cheat code for teaching agents. Everyone knows when a game is broken. You don't need to explain acceptance criteria to someone whose character just fell through the floor.

That makes games perfect for the hardest skill in agentic coding: telling the agent what "done" looks like. My four prompts were not one-liners. Each one ran 228 to 291 words: the hero (for Wharf Pup, a sea lion pup from Pier 39), how movement should feel, the enemies, the levels, the music. "Make a platformer" gets you something. A spec like that gets you a game. People learn to write a spec without anyone calling it a spec.

Games also give people permission to play, which is how most of us learned to build things in the first place.

What makes a good demo

1. It answers one question in under a minute.
2. The prompt is on the slide.
3. It went through QA like production, because on stage it is production.
4. It's public before you walk on stage.
5. The room leaves wanting to build, not wanting to clap.

Every prompt is on the games page, next to its game. Copy one and run it yourself.