Short version. This was an experiment to see if I could build something I've never tried before, using AI and good design principles, and a sprinkle of nostalgia. Claude Code wrote it. I designed it, played every build and sent a lot of it back. The first few attempts failed, but I learned along the way. Version 1.0 of the game went live in October 2026.
01 · The question
What's left for the designer?
I grew up on The Incredible Machine, a nineties puzzle game where you finish a Rube Goldberg contraption with a few parts from a bin. I wanted my version to have its own look and modern physics.
The experiment came out of a question I keep getting at work. If AI writes the code, what does the designer still do? A game is a hard test. It either feels right in your hands or it doesn't.
Five months, and a lot of stops
Pick a point on the line. Dashed ones are where something didn't work and I changed course.
The first build was a generic physics sandbox: a beige playfield, brown rectangles, floaty balls. It worked but none of it was fun. I gave it failing grades on every count: visuals, physics feel, bugs and structure.
That failure was useful. It showed that AI will build exactly what you describe, and I had described a physics toy instead of a puzzle game.
What changed in the second designGo deeper · 2 min
The rebuild started from what makes the original feel like itself. Each level is a mostly built, locked contraption, and you place a few specific parts to finish it. The parts are a toy box of things that set each other off, including a cat and a mouse with simple minds of their own. The goal text is always on screen. And a run is a replay, not a dice roll: press Run twice and you see the same thing twice.
Writing those four things down before any code was the most useful hour of the project.
02 · The decision
Review it like a player, every milestone
I split the work into seven milestones. Each one ended the same way: screenshots, clips, passing tests, and a round where I played the build and marked every part Good, Keep or a note.
I didn't read the code. I played the game. When something felt wrong, I said what I felt, in plain words, and Claude worked out why.
Things I sent back
My notes, with the spelling fixed. The more I said about why, the better the fix. Flip one to see what changed.
Early notes like "too top heavy" said what felt wrong. Later ones said what was wrong, why it mattered, and what a fix might look like. Those came back closer to right on the first try, and some became rules for the whole game.
03 · What I asked for
Press Run, get the same thing
A puzzle game needs physics you can trust. If the ball lands in the bucket once, it has to land there every time, on every computer. The first engine couldn't promise that.
So the game moved to a different physics engine, set up so the same placements give the same result down to the last bit, in every browser. Replays match in Chromium, Firefox, WebKit and Node.
The same shot, four browsers
Same ball, same ramp, same placements, run in four browsers at once.
Identical replays paid off twice. I could trust my own playtests, and Claude could build a solver that plays every level and searches for shortcut solutions I didn't intend. Each of the 62 puzzles has a verified answer and a shortcut check.
Finding the look
Three screenshots from the build, in order.
What I cut, and whyGo deeper · 1 min
The plan had a daily puzzle with a share card and clip export. I cut both before launch. A daily puzzle only matters if people come back daily, and nobody was playing yet. They're designed and waiting for an audience.
04 · What I'd tell another designer
Less making, more deciding
My first attempt failed because I asked for the wrong thing, and AI built it faithfully. A better model didn't fix that. A better description of the game did.
Each new model wrote better code. None of them could tell that the rocket felt top-heavy, that the redrawn art looked wrong, or that a daily puzzle needs players before it needs a share button. Those calls came from playing every build and saying what I felt in plain words.
So I spent less time making the thing and more time deciding what it should be, then checking that it was. If you want to try it, write down what makes the idea good before you start, and play every build yourself.