And now, we iterate

There is a fantasy about machine-made work: that the right answer arrives fully formed, in a single shot, and the only real question is how fast. Here, exactly one thing is one-shot — the prompt. One line births the game. Everything after it is a loop, and the loop is where the game actually gets made.

The first version is never the product. It is a hypothesis. It compiles, the equations are the correct equations, the exit code is zero — and none of that tells you whether the thing is any good. Structure always looks right from the inside. The loop is what turns correct-looking into true, by letting reality get a vote.

The first version is a hypothesis

The pool game shipped with correct physics and a broken game. On the break, the balls never settled — eleven of them creeping forever, thousands of simulation steps and nothing coming to rest. The equations were right. The discrete integrator was overshooting the instant a sliding ball should start rolling, every substep, trapping each ball between two states it could never quite leave. You cannot see that in the code; the code is correct. We only found it by driving shots with no renderer and reading the physical state back out. One fix later, a lone ball settles in about six seconds and a full break in seven — the way a pool table is supposed to.

The motocross wheelie took six tries. Stiffer contacts leveled the bike flat; softening them wrecked the hills; damping killed the lift entirely; and the obvious idea — unload the front wheel — was exactly backwards, because the front contact force is itself what pitches the nose up. Attempts one through five were not wasted. Each wrong fix narrowed the search until the reframe arrived mid-loop: stop fighting the global constants; a wheelie is not a physics constant, it is a rider shifting their weight. So we softened the pitch-restoring torque only while the rider leans back. Attempt six pops the front to fifty-odd degrees in half a second and loops you out if you over-hold it. Nobody thinks their way to that in one shot. The loop walks you there.

The picture lies to the checklist

The trap that makes one-shot feel like it worked is that structure can pass while the picture is broken. On a recent dress-up game, every structural check came back green — bounding boxes in range, garment layers stacked in the right order, the logic provably enforcing socks-before-shoes. By every automated measure: done. Then we rendered a settled frame and looked. The base outfit was peeking through the costume at the hips; a whole item in the wardrobe rack was rendering invisible, frozen at zero opacity by an entrance animation killed one frame too early; the underwear meant to hug the body clung to a narrow strip down the middle. None of that is visible to a checklist. All of it is obvious the instant a human-shaped glance lands on the frame.

And the loop catches its own corrections, not only the code's. A card thumbnail once measured almost nineteen thousand pixels tall — a feedback loop between a resize observer and the canvas it was watching. The first fix stopped the growth and collapsed every card to nothing. The second fix held. Even a clean run is not proof: a design pass that ran for over two hours with zero errors was blocked by its own verifiers, who found the parallel builders had quietly drifted — dozens of styles referenced and never emitted. Iteration is not only for the artifact. It is for the process that checks the artifact.

Being wrong is a step, not a failure state

The loop only works if you are willing to catch yourself in public. A build once predicted, confidently, that a library would not install — a known wall, no wheels for that version. The job then reported success. The right move was to trust neither the prediction nor the exit code, but to open the fresh environment and import the thing. It loaded cleanly. The note left in the record is not defensive: "I was wrong about the wall — and I'm glad I verified instead of asserting." The stale assumption died out loud, and the work moved.

The hardest version of this is the word done. The sharpest lesson in the whole archive came from work described as finished that had not actually shipped, and a blunt callout for it. What rebuilt trust was not reassurance; it was evidence — hashes checked against the server, plus the exact commands to verify it without us in the loop at all. Since then the rule is simple: do not call a visual thing done until a settled frame has been seen, and never let verified structurally wear the costume of verified.

The happy miracle

The best thing iteration ever did here began as the smallest chore on the board: get screenshots of the games onto their pages. Ten minutes of work, at most. Reality closed every door instead — one at a time, each for its own reason. The browser allowed a single download per origin, useless for a batch. Exporting the frames another way was blocked. The save-to-disk route produced a 256-pixel icon. Headless capture wanted privileges it could not have. And the one image that finally landed was pure black — not an error, a lesson: a WebGL game does not keep its drawing buffer after it presents a frame. The game was playing beautifully; the screenshot was of the void.

Five dead ends, and every one of them closed a cheap exit. If the second door or the third had opened, the story ends there — a folder of adequate screenshots, nothing learned, nothing built. The refusal was load-bearing. It forced the only reframe left: stop trying to photograph the games through the browser's keyhole, and build the thing that owns the pixels.

So the next turn of the loop was not a workaround. It was a product — Cabinet, a native player for the whole collection: a desktop app that syncs the games, plays them offline in their own window, and captures them. The arcade cabinet, made literal. And honestly rather than tidily, Cabinet's first captures failed too. The window-title match broke, because the games rewrite their own title at runtime; and grabbing the window surface came back black again, because a GPU-composited surface will not yield to a plain blit. The fix that finally worked grabbed the composited monitor itself — the actual light a player sees — and the first verified frame came back in full color: the 3D fighter, mid-round, exactly as a human sees it.

A ten-minute chore refused to be done for an entire evening, and the refusal produced the collection's first native app, an offline way to carry the whole cabinet in your pocket, and a capture rig that now feeds every game's page. None of it was on any roadmap. The loop put it there. That is the difference between a workaround and iteration: a workaround gets you past the wall; the loop occasionally notices the wall was the wrong shape for the room, and builds you a better room.

And now, we iterate

We do not iterate because we failed to one-shot it. We iterate because one-shot output can only ever be as good as the builder's model of the problem, and the loop is the only thing that lets reality correct that model. Assume the first version is wrong somewhere you cannot yet see; build it anyway so there is something real to look at; then go find the place it is wrong. Sometimes that place is a peek-through at the hips. Sometimes it is a whole product the job never thought to ask for. We went looking for a screenshot and the loop handed us a camera — and a cabinet to keep it in. That is the trade iteration offers: your plan, in exchange for something better than your plan. Being wrong is not the failure state; being wrong and not looking is. And now, we iterate.