Claude Fable 5 One-Shot a Full Browser Game From a 2022 Tweet

A four-year-old joke, revisited

In August 2022, Simon Willison tweeted a bit — a GPT-3 product description for a game about a team of raccoons pulling off heists, paired with DALL-E concept art from the prompt "Screenshot from a video game where a team of raccoons go on a heist." It was a fun demo of what those models could riff on. It was not, at the time, a game.

Four years later, on the anniversary of that tweet, Willison ran the experiment again — except this time he asked Claude Fable 5, running in Claude Code for web, to build the actual game from that original tweet's content. His instruction was explicit: work independently, don't come back asking for design decisions.

What the agent actually owned

The result, raccoon-heist, is a real browser game: procedurally generated low-poly raccoon, guards, and a scent-tracking guard dog with its own pathfinding on the third night, physics-based item carrying with weight penalties, mobile touch and desktop controls, and a scoring system running from TRASH PANDA up to MASTER OF DISGUISE. It's playable here.

What's notable for anyone doing agentic development isn't the game itself — it's the toolchain the agent assembled on its own:

• Three.js for 3D rendering and WebAudio for a procedurally generated soundtrack
• OpenAI's gpt-image-2 API, called from its own Python scripts (gen_textures.py, gen_title.py), to generate textures and title art
• Playwright with a pre-installed Chromium for automated in-loop testing
• GitHub Pages wired up early so Willison could watch live builds update within about 30 seconds of each push

That's a cross-vendor pipeline — Claude writing and orchestrating code, OpenAI generating art assets, a headless browser doing QA — stitched together by the agent itself, across 7 commits, without a human in the loop deciding what to build next.

The test loop found its own bugs

The part worth paying attention to is what the automated testing caught before Willison ever reviewed the code: the canvas was rendering at 2x size on real phones, and a CSS rule from the title screen's star display was leaking into the win screen, blocking interaction with it. Both got fixed inside the same autonomous loop — Playwright driving the browser, the agent reading the results, the agent patching the bug.

Execution vs. taste

As a finished game project, it's mediocre. As a starting point from a single prompt I think it's very impressive.

— Simon Willison

That's the honest takeaway, and it's a useful calibration for anyone shipping real software with agentic tools, not just toy demos. The mechanical parts — a working render loop, sound, asset generation, cross-device input, a self-correcting test cycle — are increasingly something you can hand off wholesale and get back something that runs. Whether it's actually *fun*, or actually solves the problem you had in mind, is still a judgment call the agent can't make for you. Willison's team-heist premise from the original tweet, for instance, never really materialized as a mechanic — the agent built *a* game, not necessarily *that* game.

For teams doing serious vibecoding — not toy demos, production systems — that's the actual design constraint: agents can now own build-test-fix loops end to end, which means the scarce resource shifts from typing code to writing specs precise enough that "technically correct" and "actually good" converge.