I have never played pachinko. I have no particular interest in pachinko. I now own a 3D pachinko machine that knows the diameter of its own screws.
Nobody asked it to know that.
Prompt I Used
Three paragraphs. About 180 words. One message, no follow-ups, no clarifying questions, no plan and no idea what should come out of it.
Here it is, verbatim:
I want you to build a pachinko game at the level of the most epic 3D games. It should be utterly perfect, visually beautiful, with every single thing done at AAA quality—from textures to physics to anything you could think of.
Fan out sub-agents and have sub-agents tackle each one individually so that the game is utterly perfect. You should /loop on each item and have a separate sub-agent check it visually to ensure it looks triple A. That separate sub-agent should be a really harsh critic, and if it doesn't look triple A, it should keep going.
Don't stop until each sub-agent is utterly wowed with the quality when compared with the actual real pachinko games. It should literally compare them side by side blind and say which one looks better. Do this in ThreeJS. /loop until it's utterly perfect. Fan out sub-agents and ultracode.
Then I went about my day and left my Claude Code alone. It cooked for over 24h straight, and here it is: ROCORO. Full 3D board, ball physics, hold queue, session stats, seven camera angles, four quality presets, and a lot of physics, dimensions, probabilities, and other stuff I'm not even aware of.
Read that prompt again, because the writing in it is genuinely bad. "Utterly perfect" appears three times. "Triple A" twice. There is no spec, no file structure, no list of features, no tech decisions beyond the word ThreeJS. It said to "make it really good" in several different ways.
Two years of people selling prompt engineering as a craft, and this thing is out here beating carefully written specs while typing "utterly wowed".
Matt Shumer's Gauntlet Loop
The prompt is an adaptation of Matt Shumer's Gauntlet Loop. He built a Three.js first-person shooter the same way and called it Claude of Duty. I swapped the subject to pachinko and otherwise kept his structure.
The idea fits in a paragraph. You give a lead agent a goal and a quality bar, and you do not tell it how to get there. It splits the work into pieces. Each piece gets a specialist builder and a separate critic with fresh context, and the critic's only job is to hold the output against the bar and refuse to pass it. The critic has to be a different agent, because an agent grading its own work will always favor it. Loop until the output wins or you kill the run.
The bar is the whole trick. Not "make it look good". A real thing you can point at: a screenshot, a test suite, a novel. Matt's phrasing is the cleanest version of it: give it the destination, let it choose the route.
One line in that prompt says the critic should compare the build "side by side blind" against actual real pachinko games. I typed it without thinking about what it would take to obey it literally.
To obey it literally, you need real pachinko games to compare against. So the agents went and found photographs of real pachinko parlours.
Then they kept going and found technical documentation for actual machines. Payout percentages. Pin counts. How many balls a tray holds. Hit probabilities. Screw dimensions.
I did not ask for the second part. There is no world in which I would have thought to ask for it. My mental model of "build me a pachinko game" stopped at "balls fall down, sometimes you win". The lead agent decided that a machine which does not obey real pachinko odds is not a pachinko machine, went and got the odds, and built to them.
The session odds it displays, 1 in 199.8, are not a number a model made up to look plausible. That is a real class of Japanese machine.
Bad Visuals Are The Interesting Part
Look at a screenshot and the first thing you notice is that the colours are wrong. Everything is blown out. Oranges bleeding into reds, highlights clipping, detail lost in the glare.
That is not a rendering bug. That is what the reference photos looked like.
Pachinko parlours are dark rooms full of LEDs, and photographs of them are an overexposed mess. The critic agents were grading the render against those photographs.
It did not render a nice picture of a pachinko machine. It rendered the photo. That is a more literal reading of "make it look like the real thing" than I intended, and I find it hard to be annoyed about it, because it is also proof that the loop actually looked at something. A model working from its own idea of "pachinko" would have produced something cleaner and completely generic.
The ugly bit is the evidence of how amazing this approach is.
Honest Odds
It is a pachinko game. Nobody needs a pachinko game. It is not a product, it does not make money, and it will be a novelty for about four minutes.
It also ran for the better part of a day and ate tokens like a rented mule. The last two words of the prompt are "and ultracode", which is the setting that says spend whatever it takes. Matt is upfront about the same thing: his original run needed that mode, and that mode is expensive.
To get to the same place by hand, I would have written a spec, described the physics, described the look, generated something wrong, screenshotted it, explained what was wrong, watched it fix that and break something else, and repeated that maybe 500 times over the next two weeks. I know this because that is what building anything with an AI has felt like for two years. The bottleneck was never the model. It was me, sitting there, being the critic.
The Gauntlet Loop takes the job I hate and gives it to a swarm of agents.
The input that used to be scarce was my attention. Now the scarce input is tokens.
It's Not a Magic Bullet
You cannot steer it. You type three sentences, and then it is gone for a days, and if it drifts, you find out at the end.
Long runs also die. Sessions crash, context fills, and a run that has been going for hours with nothing written down is a run you get to start again.
That pachinko prompt only works because it is about pachinko. "Compare it blind against real pachinko games" is a bar you can point at. Most of what I actually build has no "perfect example" to compare against.
I made my own version with a similar approach, but much more useful. FORGE is a Claude Code skill that takes the same principle and makes it survive a real project. You hand it a task or a plan, and it writes a self-contained mission brief: a measurable definition of done that it works out per problem instead of assuming a screenshot exists, builder and critic sub-agents, git discipline so progress gets committed rather than held in context, and a relay system so a dead session picks up where it stopped instead of at the beginning. It reads a Superpowers planning file if you already have one, so a planning session you already did does not get thrown away.
/plugin marketplace add dawid-ai/claude-skills
/plugin install forge@claude-skills
Then /forge <your task> or /forge path/to/plan.md. It writes the brief and hands it to a clean session. It does not brainstorm, it does not plan, and it will not argue with you about the idea.
More of these are coming.
Go play Pachinko Rocoro if you want ;)