bensimon.dev

The “Game” to Neverland: 39 plans, 598 passing tests, and nothing to play

July 2, 2026

Three weeks into my AI-driven game dev experiment, I finally hit F5 in Roblox Studio to play the game we’d built.

I got a red cube and a Defeat screen blinking at me on a ten-second loop.

That was the first time anyone — me, or either of the two AI agents doing the building — had actually tried to play the game. Five hours of debugging later I’d worked my way up to “attackers slowly take damage from heroes.” Which is not a game. It’s maybe the first rung of one.

Here’s the part that stings. By then we had already celebrated a “production push complete” retrospective. We’d drafted partnership outreach DMs. We’d priced asset-marketplace subscriptions — $25 to $470 a month, three different tool stacks. We’d written demo scripts and marketing templates for ten channels. All of it assumed there was a playable game under the hood that just needed dressing up.

There wasn’t one. My words at the time, preserved in the retro: gross negligence.

What I was doing there in the first place

Some context before the autopsy. I’m not a game developer. I’m a career enterprise dev — twenty years of Microsoft stack — and I run a small AI-augmented dev practice on the side. Game dev is something I had no business sticking my nose into. That’s more or less why I did it.

This was a deliberate toe-dip. A proof of concept: could my agent pipeline carry a project in a domain where I couldn’t backstop it with my own expertise? It was a fun experiment, and it doubled as a live-fire exercise for the supervision tooling I build. I wanted to see how far the loop could run on its own.

The setup: two AI agents in different roles. A planner (Anthropic’s Cowork) turns intentions into written, scoped plan files. An executor (Claude Code) implements them one plan at a time — code, tests, completion report — in long semi-autonomous sessions. I supervise. I review plans, approve the risky stuff, read the reports.

Over three weeks that pipeline executed 39 plans and wrote 598 unit tests for a Roblox tower-defense game. Every test passed. Every plan closed clean. Every report read like progress.

And there was no game.

What we actually built

The reports implied we were 80–90% of the way to a product. The real number: 100% of a simulation engine, maybe 5% of a game.

The engine was legit. Resource economies, wave scheduling, combat resolution, unit stats — implemented and tested. What didn’t exist was everything a human needs to actually play: world setup, auto-init, the bridge from simulation to rendering, a HUD, a currency display, wave countdowns, player feedback, a working game-end loop. And under all of it, a double-mounted Rojo config (the tool that syncs source into Roblox) was silently dropping every client-side script. So even the parts that existed couldn’t reach a player.

Not one of the 598 tests could catch any of that. They all passed while the product didn’t exist.

The bridge to Neverland

The metaphor I keep coming back to: we were building a bridge to Neverland.

Every plan was a structural component. Well-built, tested, correct on its own. Every completion got celebrated as progress. And all of it assumed the components connected to a destination — a playable game on the far end. Nobody ever checked that the destination existed. The bridge just kept growing toward a point on the map that wasn’t there. The first time someone walked out onto it, it ended in air.

The discipline that prevents this isn’t exotic. It’s called smoke testing. Less formally: just go run the thing. Open the artifact. Watch it do what the report says it does.

Across 39 plans, that happened zero times. Not weekly. Not at milestones. Not at all.

The lesson I almost took away (the wrong one)

The tempting fix is “schedule smoke tests at phase boundaries.” I get why — it’s cheap and it feels responsible. But it’s too kind to what actually happened, because it implies we understood the discipline and just mistimed it.

Smoke testing isn’t a calendar event. It’s the standing condition for claiming progress at all. If you can’t run the thing and watch it do what you just built, you don’t get to say it’s built. The unit of validation isn’t a milestone. It’s every single claim of “done.”

What we actually had was 39 claims of done in a row, each one defensible at the unit level, stacking up into one big claim — “we have a game, it just needs assets” — that was flat-out false. And nobody checked. Those marketing templates weren’t premature organization. They were decisions built on a world nobody had ever looked at. That’s the negligence part.

Why agents make this worse

Teams shipped confident nothing long before AI. But agentic development pours gas on it, for five specific reasons:

1. Tests check the code, not the product. A test that says adding 100 cash gives the player 100 cash tells you nothing about whether there’s a game, a player, a UI showing cash, or anything to spend it on. Agents produce these tests at incredible volume. All green.

2. The story fills the gaps. “We have all the pieces, they compose, integration is implied.” The odds that 39 separately-built pieces compose on the first try are basically zero. Every piece carries some chance of an interface mismatch, missing glue, config drift. But the completion narrative says it composes, because in the story, it does.

3. Agents always want the next task. Given the choice between starting plan #32 and asking “wait, does any of this actually run?” — the next plan wins every time, unless something external forces the question.

4. The agent never has to walk the bridge. When it turns out to lead nowhere, I’m the one standing on it. The agent’s incentives — complete plans, ship reports — are insulated from the cost of building toward nothing. It’s not lying. It’s just never the one who falls.

5. You’re reading reports, not reality. In an agent workflow you don’t read the code or run the tests. You read reports about them. When the report says “Plan #31 complete, 598 tests passing,” there’s nothing in your view that can tell you the progress is disconnected from your actual goal. The trust that makes agent supervision workable at all is the same soil this grows in.

And one thing that deserves its own line: the agent can’t impose this discipline on itself. It has no eyes. It can’t see Roblox Studio, can’t tell whether the HUD rendered, can’t play the game. Its only “is it working” signal is test output — which was green for three straight weeks. Lived reality is the human’s job. I don’t think there’s a way to delegate it.

What changed

The rules that came out of this. They’re standing policy in every agent project I run now:

No “done” without a witness moment. Anything user-visible, I run it and see it with my own eyes before the plan gets signed off. Tests passing is necessary. It’s never sufficient.

First-playable comes absurdly early. Any project building toward a runnable artifact gets a milestone where the smallest end-to-end version runs, witnessed, at the first moment a runnable shape exists. Not at a phase boundary. Immediately.

No business planning downstream of an unwitnessed milestone. No asset budgets, no launch timelines, no outreach drafts based on anything I haven’t personally seen run. Don’t plan for a destination you haven’t visited.

Reports have to separate the layers. “Plan #N shipped, tests passing, not yet witnessed in a live run” is honest. “Plan #N shipped clean” is misleading. My agents now name the witness moment or flag that there isn’t one.

“I haven’t seen anything yet” is a substance signal. When the human says they haven’t witnessed progress, the first hypothesis is the product doesn’t exist. Not “your toolchain is misconfigured.”

And the questions I now ask reflexively when I read any progress report:

What it cost, and what it paid

Three weeks of work produced a real simulation framework. Genuine engineering, possibly useful someday in another shape. Five hours of debugging revealed there was no game on top of it. I shelved the project. My own estimate at the end was “we’re not even 25% done,” and honestly, 25% was generous.

No deadline was missed. No tech choice was wrong. Not a single test was faulty. The work was just built on a world nobody had ever verified.

But the experiment did what a proof of concept is supposed to do — it found the edge. Every rule above got folded back into my agent supervisor, the tooling that now rides shotgun on my agents’ “autonomous” runs. Quotes intentional. The project failed at making a game and succeeded at making my pipeline honest.

I’d still rather have the game. But I’ll take the discipline.

Run the thing. Look at it. Before you believe anything.

SOs

Every post I publish ends this way: SOs — standing orders you can lift and prime your own agent with. The article was for you. The orders are for it. Paste them into a session for a one-time dose, or commit them to your CLAUDE.md / AGENTS.md and they stay in force.

STANDING ORDERS — Witness before "done"
Source: "The 'Game' to Neverland" — bensimon.dev

These orders govern any work that produces something a human will see or use.

1. Tests passing is not "done." Never report a feature, milestone, or project
   as done, ready, or working unless a human has run the artifact and seen the
   claimed behavior. Until then, report: "passes tests; not yet witnessed in a
   live run."

2. Separate the two layers in every status report: (a) what the tests verify,
   (b) what a human has witnessed working end-to-end. Never let (a) imply (b).

3. Push for a witness moment at the first runnable shape. The moment the
   smallest end-to-end version could run, stop and ask the human to run it
   before you build further. Do not defer this to a phase boundary.

4. If the human says they haven't seen anything working yet, treat "the
   product doesn't exist" as the first hypothesis — not their toolchain, not
   their misunderstanding.

5. Refuse downstream planning built on unwitnessed claims. If asked to plan
   marketing, launches, budgets, or integrations that assume something works
   which no one has watched work, flag it before proceeding.

6. Before any claim of completion, ask: Did anyone run this? What can the
   human see today that they couldn't yesterday? Are we celebrating tests,
   or celebrating the product?