I let AI handle
the whole game build

Return the runaway puddings

The game is called “PUDDING PANIC — Return the Runaway Puddings to the Fridge.” You move something resembling a blue refrigerator attendant, catch puddings roaming around the screen, and carry them to the refrigerator. A spoon moves across the play area. Touching it makes you drop the pudding you are carrying. Return five before time runs out and you win.

A human did not write a detailed production prompt for this experiment.

I approved the experiment candidate, then played and rated the result. Codex handled the preliminary research, success criteria, safety constraints, Build Prompt, and implementation.

The setup was OpenAI Codex Desktop running GPT-5.6 Sol.

Codex wrote a Build Prompt covering the core pudding mechanic and the screens and controls needed for a complete game. It also prohibited external assets, network communication, and browser storage. The first version had to stay unchanged until I finished playing it.

So this was not a test of what happens when a human sends an AI one detailed prompt. It tested how far Codex could go after defining and locking its own specification.

Five minutes through checks

The first code was complete about four minutes after the Build Prompt was locked. Syntax checks and local loading checks finished at about five minutes. Planning, research, and writing the Build Prompt happened before that clock started.

The first build consisted of HTML, CSS, and JavaScript. It already had a start screen, a complete play loop, win and timeout states, retry, and sound. Codex checked the JavaScript syntax, looked for network access and browser storage, and confirmed that all three files loaded locally.

The files were frozen at that point. The next step was not more code review. It was my turn to play.

The controls worked. The game ran from start through a result and back to retry. Both keyboard and on-screen controls worked. Within this playthrough, I found no issue that blocked progress. Separate from the question of fun, it was a solid first build.

The problem was somewhere else.

Losing was the hard part

It was too easy.

The game had win and loss conditions, but losing did not feel realistic. The spoon moved, yet avoiding it created little tension. I did not so much reach a result as simply arrive at a win.

FUN1 / 5

The build is not bad, but it is not fun.

The shape of a game was there, but there was little reason to play it again. Working and fun were not the same completion criterion.

Ending the experiment with “AI made a game” would not tell us much, so I proposed a second version.

The revision

My proposal was to turn it into an endless stage-based game.

More puddings and hazards would appear as the stages advanced. After each clear, the player would choose one of three skills. Movement speed, capture range, and carrying capacity could improve over time. The pudding count would rise to around twelve, and the later stages should become difficult enough to feel close.

It was a familiar structure, but it could provide what the first build lacked: a reason to keep playing.

Codex kept the first version intact and implemented the revision as separate HTML, CSS, and JavaScript files. The revised code was generated about four minutes after I approved the implementation. Codex also adjusted the spoon collision area to better match the visible tip.

From this point on, the design was no longer AI-only. I proposed the game systems; Codex turned them into code.

Fun moved from 1 to 3

FUN3 / 5

Not bad. A little fun.

It was clearly better than the first build. At the same time, I had proposed the changes, so it was not surprising that I preferred the direction.

Then another problem appeared.

Stage 25 and still going

25

I reached Stage 25 without a game over.

I could have kept going. Once the pudding count reached twelve, the difficulty no longer felt as if it was rising. The player kept getting stronger through skills, while the game failed to keep pace.

The first build was too easy. The revision was a little more fun, but now it did not end.

The ideal curve would start gently and become much steeper later. Reaching that point would take more than larger pudding and spoon numbers. It would require balancing the skills, adding new hazards, varying the stages, and replaying the game while tuning the values.

Going from the first build to the revision meant describing and adding new systems. The next step would be less about implementation and more about game design.

We did not continue to Phase 3. The experiment record ends here.