1972
The museum piece
Claude Haiku
Two paddles, two human players, minimal classic Pong.
Three Pongs From One Line
An experiment in where AI systems actually break — starting with a game that cannot fail.
You can play all three below. Do not take my word for anything in this post — the artifacts are right here.
Three playable Pong artifacts
Same one-line spec, three different AI systems, three different interpretations.
The Textbook
The tutorial answer
Gemini Pro 3.1
Mouse control, computer opponent, clean web-tutorial style.
The Casino
The neon arcade
Gemini Flash 3.5
Power-ups, particles, synthesized sound, and extra spectacle.
The prompt was one line: build Pong as a single HTML file — two paddles, a bouncing ball, a score, playable in the browser. Same line, three different AI models, no other instructions.
One of them handed me Pong as it actually existed in 1972: two paddles, two human players, nothing else. One handed me the Pong you would get from a web tutorial: mouse control, computer opponent. And one handed me "CyberPong — Neon Arcade Edition": power-ups, particle effects, synthesized sound, screen shake, an AI opponent with adjustable difficulty, a demo mode where it plays against itself, mobile touch support. Forty-eight kilobytes of things I did not ask for.
Here's the question this post is actually about. Three contractors, one spec, three wildly different products. Who screwed up?
Why Pong, of all things
First, the setup — because this is post one of a series, and the series has a method.
I'm running a controlled experiment on AI agent systems: where do they break, and when they break, whose fault is it — the model's, or the process wrapped around it? The problem with answering that question on real work is that real work always gives everyone an alibi. The task was too big. The requirements were vague. The codebase was legacy. You cannot attribute failure when the task itself is a suspect.
So I'm removing the suspect. The plan: clone videogames in historical order — arcade era, 8-bit, 16-bit, onward — treating game complexity as the experimental variable. Each game is one probe. And the series starts at the absolute floor.
Pong, 1972, is the floor. The original wasn't even software — it was discrete TTL logic. No processor, no code, about a dozen logic gates. The "physics" is: ball moves at constant speed, ball bounces, paddle slides along one axis. Nothing emergent, nothing large.
Which makes it the perfect null control. If anything goes wrong on Pong, the task has no alibi to offer. Any failure is 100% attributable to the manager — the spec, the process, the interface to the model. That's not a warm-up. That's the one rung of the ladder where the signal is pure.
I expected a boring result: three identical trivial clones, confirmation that the floor is the floor, move on.
I did not get a boring result.
The lottery
All three clones worked. Zero-shot, zero console errors, playable. On the floor of the ladder, one-shot generation simply works — that's the boring half of the finding, and it's worth exactly one sentence.
The interesting half: they built three different games. And the pattern of how they differed is the actual finding.
Here's the ranking, and it should bother you. The strongest model of the three — Gemini Pro 3.1 — built the textbook: small, clean, played it straight. The casino came from Gemini Flash 3.5, the mid-tier, speed-optimized one. And the smallest of the three — Claude Haiku — built the museum piece: the historically faithful 1972 original, two human players, no invented AI opponent, no decoration.
Read that again: on fidelity to the source, the weakest model won. Not because it knew more history — because it interpreted less. The other two filled the gaps in my one-line spec with what they "knew" a Pong should be. One had absorbed a thousand web tutorials, so it built a tutorial. One had absorbed the aesthetics of "impressive arcade demo," so it built a demo reel. The smallest model had the thinnest opinion about what I really wanted — so it did what I said.
So: who screwed up? Not the casino-builder. Not the tutorial-builder. Not the literalist.
The manager screwed up. Me. A one-line spec is not a specification — it's a lottery ticket. What an under-specified request actually does is hand the decision to the contractor's past: whatever they were trained on, marinated in, rewarded for. You don't get "the task, done" — you get their habits, expressed. Ask three humans with one vague sentence and you'll get the same lottery: the junior does it literally, the senior "improves" it into their portfolio piece, the tutorial-brain gives you the textbook answer.
The management disease is ancient. Here's the modern twist: the lottery isn't even ordered by price. I'd have bet the flagship model produces the most self-indulgent filling. It didn't — the mid-tier one did, and the flagship played it straight. Which habit fills your vacuum is a personality, not a power level: it reflects what the model marinated in, not what its benchmarks say. You cannot read it off the invoice, and you can't fix it by paying more. The only way to find out what an under-specified prompt buys you is to run the lottery — and by then you've already paid.
The hole that never fills itself
Here's the part that actually unsettled me, though. The three models filled my vacuum with three different things — spectacle, pedagogy, literalism. Fine. A lottery.
But there's one thing none of them put into the vacuum. Not the strong one, not the weak one, not any of them:
An acceptance test.
None of the three shipped any way to verify the thing works — no test hook, no programmatic interface, nothing a machine could check. The single most useful artifact a contractor can hand a manager — proof — appears in this lottery with probability zero. Their priors disagreed about everything else; they agreed perfectly on this omission. Spectacle is in the training data. Verification is not. Nobody puts acceptance tests in their portfolio.
And this hole is worse than the casino, for one reason: you have eyes against the casino. Unwanted power-ups are visible. A missing verification layer is invisible — all three Pongs looked done. If the task were ten times bigger, "looks done" is exactly the trap that ships confident garbage.
Then I wrote an actual spec
Round two: same three models, but this time a real specification — explicit constraints (minimal classic Pong, nothing else) plus an explicit contract: expose a test API (`getState`, `step`, `reset`...), deterministic fixed-timestep physics.
The lottery collapsed. All three converged on near-identical minimal correct Pong. The casino-builder dropped from 48KB to 15 — every power-up and particle gone. And all three — including the smallest — honored the full test contract, which let me run a machine falsifier over the physics: deterministic replay, bit-identical over 400 fixed steps, bounce and scoring verified without me watching.
Full disclosure, because this series only works if I report my own misses: my "real spec" quietly told each model to include a simple AI opponent. The 1972 original had two human players — no AI. The spec-writer has priors too. There is no clean escape from this game; there's only knowing you are in it.
Two findings, then, from the cheapest rung of the ladder:
- Model tier did not bind. Weakest and strongest all delivered correct, verifiable Pong under a real spec. On the floor, capability is not the constraint.
- Everything that mattered was liftable by specification. Scope discipline: written in, appears. Verifiability: written in, appears — in all three. For free: never.
On the floor of the ladder, the spec lifts everything. Which is exactly what makes the rest of the ladder interesting.
The hunt
Because this cannot stay true. Somewhere up the historical ladder — bigger games, coupled systems, emergent physics, actual content — a written spec stops being enough. Something stops lifting. The open questions this series exists to answer:
- What breaks first? Volume? Coherence across coupled systems? The ability to verify?
- When it breaks, what gets it back — better process, better tooling, splitting the work across multiple agents, something else?
- And the horizon question: is there a ceiling that nothing lifts?
I'll keep a running, public boundary map as the series climbs: each game, the complexity jump it introduced, what capability became necessary, and whose ceiling we hit — the model's or the process around it. Pong is now the first point on that map: floor confirmed; all failures at this altitude are management failures.
Next up the ladder, the games start fighting back. Early candidates: Breakout, Space Invaders — the first rungs where size and emergent behavior enter the picture.
And one teaser from the lab notes, for next time: while testing these clones, my automated falsifier — the machine judge I built specifically because I do not trust self-reports — confidently failed two builds that were, in fact, correct. My lie detector lied. That story is post two.