My Lie Detector Lied

The Pong builds were correct. My automated judge said they failed.

Not once. Twice. Out of three correct engineered builds.

That was the more useful bug.

Round one was the lottery: ask three AI models to build Pong from one vague sentence, and you get three different interpretations of "Pong." One model builds the 1972 original. One builds the web-tutorial version. One builds a neon arcade product I did not ask for.

Round two was the correction: give the same task a real engineering spec, including a fixed-step test API, and the lottery collapses. The same models produce small, deterministic, testable Pong builds.

That was supposed to be the happy ending. I had stopped judging games by vibes. I had a machine judge now.

The judge promptly lied to me.

If the build is right and the test says FAIL, who is on trial?

The judge had a theory of Pong

The point of the second Pong round was not just "make Pong again, but stricter." The point was to make the game falsifiable.

Each engineered build had to expose a test API: get the state, move a paddle, pause the game, reset it, step the simulation forward by a fixed amount. That gave the checker something better than screenshots. It could drive the game like a lab instrument.

The falsifier's job was modest:

1. Confirm the API exists.
2. Run the same fixed-step sequence twice and demand an identical trajectory.
3. Check that the ball stays inside the vertical bounds.
4. Check that paddle and wall physics actually reflect the ball.
5. Park both paddles and confirm that scoring eventually happens.

No model self-report. No "looks good." No asking the contractor whether the building is structurally sound.

The judge would run the game, observe the state, and return a verdict.

This is exactly the kind of thing I trust more than prose. Which is why the first report was so annoying.

The compact ledger:

Two false FAILs out of three. The builds survived. The judge did not.

False fail number one: the checker changed the game

The first false FAIL appeared while testing the Gemini Flash 3.5 build. The build itself was correct.

The checker tried to make the left paddle track the ball so it could force a paddle return and observe the physics. Simple enough: put the paddle where the ball is, step the game, wait for contact.

But the first version tracked the ball too perfectly. It aimed at the paddle center.

In one of the Pong implementations, the vertical angle of the ball after paddle contact was computed from where the ball hit the paddle. Hit high, the ball goes upward. Hit low, the ball goes downward. Hit dead center, the vertical component goes toward zero.

So my falsifier carefully created the exact condition that erased the vertical velocity it wanted to observe.

Then it complained that vertical behavior was missing.

That is a beautiful class of bug. The checker did not merely misunderstand the system. It intervened in the system, changed the behavior, and then treated the altered behavior as evidence against the build.

The fix was not philosophical. It was mechanical: stop center-tracking. Aim off-center, so paddle contact should impart a visible angle.

One false FAIL down.

False fail number two: the checker waited for luck

The second false FAIL appeared while testing the Claude Haiku build. Again, the build itself was correct.

After offset tracking, the checker still wanted to observe a wall bounce: a vertical velocity flip during the rally. That sounds reasonable in Pong. A ball with vertical velocity should eventually hit the top or bottom wall and bounce.

But "eventually" was doing too much work.

The game was correct. The source showed the wall reflection logic. A direct probe showed vertical velocity being imparted by paddle contact. The ball could reach the wall. The physics were there.

The checker's scenario was the fragile part. It treated the absence of a wall bounce inside one particular driven rally as evidence that wall physics were missing. But that rally depended on the chosen field size, speeds, paddle policy, and step budget. Change those parameters slightly, and the event might not happen when the checker expected it.

That is not a physics failure. That is a test that mistook a lucky scene for a property.

This is the subtler lie. The first checker bug created the bad behavior. The second one demanded that good behavior reveal itself through one specific little theater.

Both mistakes produced the same kind of output:

FAIL.

Same verdict. Different disease.

From little theater to mechanism

The hardened checker stopped asking "did the rally happen to show me the event I wanted?"

It started asking for mechanism-shaped observations.

For paddle physics:

• Did an off-center paddle contact return the ball by flipping horizontal velocity?
• Did that same off-center contact impart meaningful vertical velocity?

For wall physics:

• Was a vertical reflection observed while the ball was actually near the top or bottom band?

For determinism:

• Did two identical fixed-step runs produce the same trajectory?

The shift is small, but it matters. The first checker treated one messy rally as the property. The hardened checker split the property into smaller observations: return, angle, wall reflection, determinism.

A scenario is a little story you hope will happen. A mechanism is the thing you are actually trying to prove.

After that hardening, all three engineered Pong builds passed.

Not because I relaxed the standard. Because I stopped testing the wrong thing.

A falsifier is not an oracle

This is the real finding from Pong, and it is more important than the three games from the first post.

An independent falsifier is necessary. It is not sufficient.

The primitive builds had no test API, so the only available gate was "runs, renders, no console errors, human can play it." That is not enough for anything serious. The engineered builds exposed a machine-checkable surface, and that immediately raised the floor. Good.

But the falsifier itself became a new artifact with its own bugs, priors, blind spots, and incentives. It had a theory of Pong. Parts of that theory were wrong.

The dangerous move would have been to trust the FAIL because it came from the tool whose entire purpose was not being fooled.

That is how automation becomes superstition: you stop believing the model and start believing the harness.

The rule has to be harsher:

Do not trust the build. Do not trust the model. Do not trust the verifier. Trace the mechanism.

The verifier earns trust the same way the build does: by being inspected, falsified, hardened, and made to explain exactly what it observed.

There is a management lesson hiding under the engineering lesson, too.

In the first post, the manager's error was under-specification. I wrote a lottery ticket and got three different games.

In this post, the manager's error moved one level up. I wrote a judge, then almost treated the judge's verdict as ground truth.

That is still delegation without inspection. It just wears a lab coat.

The better frame is not "automated tests replace judgment." The better frame is "automated tests move judgment to a narrower and more inspectable place."

That is a win. I would much rather debug a brittle wall-bounce check than stare at a 20,000-line generated game and wonder if it feels done. But it is still judgment. It is still design. It is still work.

Pong is the friendliest possible version of this problem. Two paddles. One ball. One canvas. A simple deterministic API. Even here, the judge found a way to be confidently wrong twice.

The new boundary

Pong taught two things at once.

First: at this altitude, generation is not the bottleneck. With a real spec, even the small model produced correct, deterministic, machine-checkable Pong.

Second: verification is already nontrivial. Not impossible. Not mystical. But not free.

The boundary did not appear where I first expected it. I was watching the models. The first serious crack appeared in the test harness.

That is useful. It means the next experiments should not only ask whether models can build more complex games. They should ask whether we can still build cheap, honest falsifiers for those games.

Breakout adds bricks. Space Invaders adds hostile systems. Later games add state, timing, content, and taste. Somewhere along that climb, the judge stops being exact and starts becoming a partial witness.

When that happens, the question changes.

Not "did the AI make the game?"

"Which parts can still be falsified, which parts require human terminal judgment, and how do we keep those two from impersonating each other?"

That is the next anatomy lesson. Fun Is Not a Spec follows the part a deterministic verdict still cannot settle.