Claude Opus 5.5 Built a Full Game in One Prompt — What That Tells You About Modern AI Capability
Simon Willison prompted Claude Opus 5.5 Max through the standard iPhone chat app to build a Three.js game in one shot, and the model spent over three hours producing a working spot-the-difference game with music and achievements. This documents a meaningful shift in who can build interactive digital products — and what plain-language prompting can now accomplish without any coding knowledge.
A Single Prompt. Three Hours of Thinking. A Working Game.
Something quietly remarkable happened earlier this month. Simon Willison — a well-known developer, co-creator of Django, and one of the more careful observers of AI capability — published a short post on his site titled Tree Appreciator describing an experiment with Claude Opus 5.5 Max.
The experiment was simple on the surface. Willison opened the default Claude iPhone app — not a developer environment, not Claude Code mode, just the regular chat interface — and typed a single prompt:
Build a three js game called “Tree appreciator” — it shows you two algorithmically generated trees and the game mechanics is about appreciating the differences between them. Think hard about how to make sure it is both fun and beautiful.
What came back, after Claude processed the request for three hours and seven minutes, was a fully playable spot-the-difference game complete with music, animation, and an achievements system. Willison describes it as “quite compelling to play.”
That is the news. Now let us unpack why it matters for you — even if you have never written a line of code in your life.
What Actually Happened Here
Three.js is a JavaScript library used to render three-dimensional graphics in a web browser. Building anything with it normally requires a developer who understands 3D geometry, animation loops, lighting, browser rendering, and audio integration. A “spot-the-difference” mechanic on top of algorithmically generated trees — trees that are procedurally different every time — adds layers of logic involving randomness, comparison algorithms, and game state management.
Willison did none of that manually. He described the intent of the game in plain English, added the instruction to make it “fun and beautiful,” and Claude Opus 5.5 Max handled every implementation detail.
According to Willison’s post, he found — somewhat to his own surprise — that telling Opus 5.5 to “make sure it is fun” works “uncomfortably well.” The word “uncomfortably” is doing a lot of work there. It signals that the result exceeded what even an experienced observer expected from a natural-language instruction about an inherently subjective quality.
The model did not just generate functional code. It made aesthetic and design decisions: what makes a tree look interesting, how to animate it pleasingly, what kind of achievements feel rewarding, how to layer music so the experience feels cohesive. These are judgment calls, not purely technical ones.
The Vibe Coding Shift — And Why It Matters in India
The phrase “vibe coding” has been circulating in developer communities to describe a mode of working where you describe the feel and intent of what you want, rather than specifying implementation steps. Willison tags his post explicitly with “vibe-coding,” signalling that this experiment belongs to that emerging practice.
For non-technical professionals in India, this shift is worth paying close attention to — because it changes who can build things.
Consider a scenario grounded in Indian professional life. Say you run a mid-sized educational institute in Pune that teaches English to school students. You have always wanted a simple interactive game for your website — something that helps students notice subtle differences in sentence construction, the way “Tree Appreciator” helps players notice differences between trees. A custom game like that would historically cost you anywhere from ₹80,000 to ₹3,00,000 in developer fees, plus weeks of back-and-forth on requirements.
With a capable model like Claude Opus 5.5 Max accessible through the Claude app, the same institute’s academic coordinator — someone with no coding background — could describe the game in plain language, specify the feel they want (“calm, encouraging, with a soft success sound when students get it right”), and receive working code as output. The coordinator would still need someone to upload and host that code, but the creative and technical generation step has been dramatically compressed.
This is not a hypothetical future. Willison’s post documents it happening in October 2026, on a phone, in a standard chat interface.
What the Three-Hour Processing Time Tells You
One detail in Willison’s account deserves specific attention: Claude took three hours and seven minutes to return the result.
This is not a bug or a failure. It reflects how extended thinking and long-context generation works in modern frontier models. Claude Opus 5.5 Max, when given a complex creative-technical task, does not return a quick first draft. It works through the problem — considering structure, testing logic paths internally, generating and refining code — before producing output.
For a non-technical user, the practical implication is this: complex generation tasks are not instant. If you prompt Claude with something ambitious — a full interactive tool, a detailed multi-section report, a game — you should expect to wait. The output quality is the trade-off for that wait time. Willison’s result, a playable game with music and achievements, reflects what extended processing time can produce.
This also means you need to think carefully about how you prompt for complex tasks. Willison’s prompt worked because it was specific about the concept (two algorithmically generated trees, spot the difference), honest about the quality bar (fun and beautiful), and left the implementation decisions to the model. That combination — clear intent, honest quality expectation, implementation freedom — is worth learning from.
The Limitations You Should Know
Before you conclude that Claude can build anything from a sentence, there are honest constraints to name.
What to Watch For Next
Willison’s Tree Appreciator experiment is part of a broader pattern: frontier models being used directly through consumer interfaces — a phone app, a chat window — to produce artefacts that previously required specialist skills. This pattern is accelerating.
If you are a non-technical professional in India curious about what this means for your work, the most useful thing you can do right now is pay attention to the type of prompts that produce strong results. Willison’s prompt is a good model: name the concept precisely, describe the experience you want the end user to have, and trust the model with implementation choices.
You do not need to understand Three.js to use this kind of capability. You need to understand what you want to build and be honest about what quality feels like. That, increasingly, is the skill worth developing.
Simon Willison’s full account of the Tree Appreciator experiment is available at simonwillison.net and is worth reading in full — not just for the result, but for the candid observation that telling an AI model to “make sure it is fun” now produces results that are, in fact, fun.
