Why AI one-shots tiny games

Why does "make me a snake game" work on the first try while "add rate limiting to our billing service" still goes sideways? Same models. The gap taught me more about using AI than any prompt guide.

Three boring properties stack up for the tiny game. The corpus has rehearsed it: tutorial games are among the most-rewritten code on the internet, so the request lands in the model's deepest home field. The task has edges: one file, no dependencies, nothing outside a browser tab — worst case, you close it. And the big one: verification collapses into experience. Normally, checking AI output is the tedious part — reading diffs, running tests. For a game, that job has a different name: playing. Two minutes with your thumbs covers acceptance criteria nobody could have written down, because "feels responsive" was never writable in the first place.

The rule worth stealing for everything else: put the acceptance where your senses are. Requests that produce something directly experienceable — a page you click, a deck you flip — inherit the cheap acceptance check. One trap: reading a chart verifies the rendering; wrong data reads exactly like right data. And invisible-correctness work (refactors, migrations, anything with concurrency) inherits none of it. That still needs tests, review, and a rollout plan.

Honest limits: leave the tutorial genre and quality drops fast. Playable is a low bar — an off-by-one in the score passes for a design choice. And most software can't be felt in two minutes, which is why the boring apparatus keeps its job.

The question that sorts it all: how quickly can you feel a mistake?