---
title: "1 Game. 1 Prototype. 0 Publishable."
url: "https://blog.qcentic.com/post/one-game-one-prototype-zero-publishable"
description: "One spec, two builds: a frontier agent alone, and a small model directed by a human who actually played. Delivery isn't the job — the loop is."
updated: 2026-09-08T10:46:19+00:00
---

*I gave Fable 5.1 — a frontier agent — a full game design document and left the room. Then I directed GLM-5.3-Flash, a much smaller model, through the same document, one playtest at a time. The question was whether a human in the loop could close the size gap. What I found instead matters more: the big model delivered the plan perfectly — and never once arrived at the conclusion that the plan itself has to change as you play. If a model can't get there on its own, it doesn't matter how good it looks in a Minecraft-alike demo or a benchmark.*

*Setup: one spec, two isolated workspaces · Frontier run: Claude Code, Claude Max · Orchestrated run: pi harness, GLM-5.3-Flash via Ollama + cloud · Shared tooling: Blender, Roblox Studio, Rojo, ElevenLabs, Tavily · ~8 h of my involvement — and I stopped on purpose*

---

| Run A — Fable 5.1 | Run B — me + GLM-5.3-Flash |
| --- | --- |
| ![Fable 5.1 build, mid-combat: the player ship low in frame, magenta enemy bolts incoming, a purple raider centred under the crosshair](https://assets-blog-qcentic.b-cdn.net/5/10-combat-incoming-fire.png) | ![GLM-5.3-Flash build, mid-combat: the player ship banking past an enemy carrier hulk, magenta bolts and darts in wireframe silhouette](https://assets-blog-qcentic.b-cdn.net/6/02-glm-combat-carrier.png) |

*Both builds, mid-combat, on my screen. Left: the delivered game. Right: the prototype I stopped on purpose. This is the "before you judge me" shot — they both actually run.*



## 1. The demos that started it

The videos that pushed me into this all look the same. A frontier agent opens an empty project. Minutes later there's a Minecraft-*alike* running — blocks, a hotbar, trees, a day/night cycle — one autonomous session, no human in the frame. The replies under those videos write themselves: *game development is over.*

I'm a technical consultant and software project engineer — but games are the reason I got into programming in the first place. I've loved them since I was a kid, I've built some myself, and over the years I had the opportunity to work with a few real game directors. So every time I watch one of those videos, the same question forms and never gets answered. Not "can a model build a game" — I'll concede that sentence. The question nobody in the demos asks is:

**What, exactly, was the human for?**

In the demo videos the human is a narrator. In every game I've ever seen shipped, the human is the instrument the game gets tuned against. So I stopped collecting demos and started an experiment the demos never show: the control condition. Run one spec through two completely different shapes of intelligence — a frontier model with no supervision, and a small model with a human director — and then count, honestly, what each one is missing.

I wasn't looking to replicate anything. I was looking for the part of the story those videos always cut — and the experiment I built had one clean question: **can a human in the loop make a small model compete with a frontier model running solo?**

That was the question. The experiment's answer turned out to be a different discovery — and it took me stopping early to see it.

## 2. The moment of truth

The spec came first, and it had to be real — but I didn't write it. The genre I was aiming at — Galaga, Star Fox, the whole rail-shooter lineage — is made of *popular* games, and my assumption was simple: popular games have had a lot written about them over the decades, so the internet should hold more than enough material for a model to draft a competent GDD from, with my own additions — the incremental game logic — layered in. So I had an AI draft the entire thing under my direction: **STARLANE**, a behind-the-ship rail shooter with roguelite meta-progression (*Galaga's formations, Star Fox's rail camera, a roguelite's hangar*). You fly a lane through hostile space, enemy squadrons pour in on scripted flight paths, wiping out a whole squadron hands you a new weapon, you die, you go back to the Drydock, you buy your way further next run. What came out of that drafting session: a full game design document — 65,000 characters of waves, weapons, formations, bosses, economy, tuning philosophy — plus a runnable Python economy model that reproduces the game's income and threat curves, so every progression number in the document is derived, not vibes.

Yes — even the spec was written by an AI. And not just any AI: the GDD and the economy model were drafted with **Fable 5.1 itself** — the same model that would later build Run A. At the time, I didn't consider that a problem. These were popular games, and my assumption was that everything written about them over the decades should be in the training data; my contribution was the genre, the references, the incremental game logic, the demands and the editing decisions — the taste. What I only discovered halfway through building the *other* game was that this choice was the experiment's biggest hidden flaw. Hold that thought — §8 is about it.

Then two folders, with a rule I enforced harder than any other rule in the project: **the spec is read-only.** Neither build may edit `gdd.md` or `economy_model.py`. If a build disagrees with the spec, the spec wins, and the correct move is to ask me — never to silently reinterpret.


|                     | Run A — Fable 5.1                                                     | Run B — me + GLM-5.3-Flash             |
| ------------------- | --------------------------------------------------------------------- | -------------------------------------- |
| Model tier          | Frontier                                                              | Small                                  |
| Harness             | Claude Code (Claude Max)                                              | pi (Ollama + cloud)                    |
| Who directs         | the model                                                             | me                                     |
| Who plays the game  | the model, autonomously                                               | me, constantly                         |
| Model cost          | considerably more                                                     | Ollama is free; cloud runs are pennies |
| Shared tooling      | Blender (headless + MCP), Roblox Studio MCP, Rojo, ElevenLabs, Tavily | same                                   |
| Cross-contamination | none — isolated folders, zero shared assets                           | none                                   |


Fable had frontier weights, full autonomy, and its own playtests. I had a smaller model, the Studio seat, and whatever evenings I was actually willing to give it — which turned out to be about eight hours, and not one of them wasted.

I asked the smaller question: **what breaks first when nobody plays the game?**

## 3. The rig (for the replicators)

The models were the cheap part. The plumbing is the expensive part — and it's the part you can actually copy, because all of it is public in the repo this article links to. Both workspaces got identical tooling, so the only variable left was the shape of intelligence using it. Three layers:

- **MCP** — one `.mcp.json` at the project root gives both harnesses the same two live bridges ([modelcontextprotocol.io](https://modelcontextprotocol.io) is the glue standard): [blender-mcp](https://github.com/ahujasid/blender-mcp) into an open Blender, [@chrrxs/robloxstudio-mcp](https://www.npmjs.com/package/@chrrxs/robloxstudio-mcp) into a live Roblox Studio — edit instances, run Luau, drive playtests. Around them, plain professional tooling: [Rojo](https://rojo.space) 7.6.1 pinned via [aftman](https://github.com/LPGhatBoy/aftman), so both builds sync from the filesystem into Studio like real projects — because they *are* real projects.
- **Skills** — every external service got a markdown **skill file** in `skills/`: the security rule first — **never read, `cat`, or echo the `.env`** — then the verified command, then the Roblox import path. I wrote each command once, smoke-tested it once, recorded the behavior. From then on, every agent on every run provoked the same recipe, and never held a key. A small model with verified recipes beats a small model with an API reference — the second one writes you a 401 story at hour nine.
- **Research** — [Tavily](https://www.tavily.com) as a standing pipeline, not a search box: Luau style and type-system docs distilled into a research file with the source URL on every claim, lint gates and Rojo layout worked out before either build started, and a flight-model dossier (No Man's Sky patch notes, Elite Dangerous flight pages) when the feel went wrong. A small model is only as good as the context you hand it. This layer is where that context gets made.

Every command, config, gotcha and scar — the `.mcp.json` server block, the exact skill invocations, the mesh-export laws (1 Blender unit = 1 stud), the Studio HTTP-permission trap — is written up in the repo's README. I won't reproduce the manual here.

## 4. Run A — Fable 5.1: zero runtime errors is not a review score

Fable read the GDD and the economy model, wrote a plan, and got to work. The machinery it built for itself was genuinely impressive: it scaffolded a full Rojo project, an architecture document, an offline test runner — then spawned **ten parallel builder agents with file-disjoint scopes**. Roughly **32,000 lines of Luau** landed in one integrated wave, alongside **67 meshes, 66 UI images and 70 audio files** that it generated and uploaded to Roblox's CDN by itself. Its test suite went green — **242 tests** — lint clean, and it ran its own playtests: a god-mode run reaching the sector-2 boss with zero runtime errors, then a polish wave, then a deeper full-loop playtest, still at zero runtime errors.

Empty folder → full game loop, with almost no me in the loop. Genuinely. Credit where due.

But look at *how* it played its game. Fable's playtests were driven through `eval_client_runtime` — calling controller APIs from *inside* the running process — because its screenshot tooling needed a Studio window that isn't minimized. Read that again. **The model never once played the game. It read the game from inside it, the way an auditor reads a balance sheet.** Health values moved. Waves spawned. Zero errors. Nothing in that loop ever felt the darts come at it.

The results showed exactly where that method tops out. The UI architecture was the more ambitious of the two builds — and it shipped with wrong offsets: elements drifting off their anchors, layouts correct in the editor and wrong on screen. The UX had moments that were outright confusing to a fresh player, and no loop existed to catch them, because the entity that could notice *this is confusing* was the entity that wrote the confusion. 242 green tests, zero runtime errors, and it still wasn't fun.

There is no test for fun.

And one more thing, which I only learned to see from the other side of the experiment — I'll say it here and let it sit until §8 pays it off: Fable treated the plan as the objective, and met the objective. It had every capability in the world, and it used all of it delivering the document. It had no reason to doubt the plan. It *wrote* the plan.

![Fable's Drydock Hangar: every BUY and NEED button renders its cyan fill up and left of the dark frame behind it; the RANK 1 TIER header is clipped by the panel border; a tutorial tip renders on top of the tab row](https://assets-blog-qcentic.b-cdn.net/8/03-fable-hangar-after-run.png)

*The offset, in the shipped build. Every `BUY` / `NEED` pill — and `LAUNCH`, bottom left — draws its cyan fill up-and-left of the dark frame it belongs in. The fill is the half that's clickable; the frame is a mis-anchored backdrop. `RANK 1 TIER` is clipped by the panel border, and the tutorial tip is painted over the tab row. Every one of these passed 242 tests and produced zero runtime errors.*

| | |
| --- | --- |
| ![Fable build in the lane: the player ship, crosshair, drifting debris and a wreck silhouette against a planet limb](https://assets-blog-qcentic.b-cdn.net/11/04-fable-lane-flight.png) | ![Fable's Shipyard tab: four ship cards — Sparrow, Bulwark, Wraith, Comet — with stat lines and unlock costs](https://assets-blog-qcentic.b-cdn.net/12/05-fable-shipyard.png) |

*And the fair half: Fable's lane reads well, and its Drydock has a Shipyard, a Loadout, daily Missions and a leaderboard behind those tabs. Its visuals were genuinely the better of the two builds. Credit where due.*

![Fable's Emergency Warp prompt: a three-second countdown offering a full-shield revive for R$ 29](https://assets-blog-qcentic.b-cdn.net/13/06-fable-emergency-warp-revive.png)

*It also built the monetization layer, unasked and unsupervised: die once, and a three-second countdown offers you your run back for R$ 29. The plan said so.*



## 5. The disclaimer (and the irony)

Full disclosure, same as always: I'm the biased instrument here — I built the other build, and while game development was never my trade, I've made games myself and worked alongside a few real game directors on projects; I know what it looks like when one feels wrong. So let me say the fair things first.

Fable's codebase is better structured than mine, and it earned the difference: a real server with nine services where my prototype has a 121-line script, twenty-three client controllers behind a written contract, and an architecture document written before its ten builders produced a line of game code. That document I'd happily steal; my own — eight ADRs, a style guide, a BestPractice folder — accumulated the opposite way, mid-run, by my choice. Its Blender meshes are better than mine: sixty-seven of them to my six. Its speed is not a rounding error — nothing to a running game in one afternoon, against my several days of evenings and about eight hours of me, because *I* was the bottleneck: halting the build so the model could do its own research into best practices and pick its own approach, demanding a playtest scene so I could eyeball sizes, waiting on myself to decide things. Our code even fails differently, and I side with mine — Fable guards every sibling module so the game never crashes, the right philosophy for a build nobody watches; mine fails loud, because the one watching is me.

And one asymmetry belongs in the scoreboard, not in a footnote: Run A ran its plan end to end — empty folder to hand-off, one afternoon. Mine I stopped on purpose, mid-build, at the exact moment the learning stopped — §8 is that story, and the deferred-milestones list sitting in my own PLAN.md is its receipt. So the structure, the meshes, the completeness I just conceded were measured between a run that finished and a run that stopped itself by design. If the metric is "working game, fastest," Run A wins and it isn't close — and that verdict stands. It just isn't the verdict this experiment was after. The stopping was.

And here is the detail I can't stop thinking about. My launch instructions to Fable were precise: *don't ask me anything — build everything on your own.* It obeyed, to the letter. Not one question the entire run. And still, in its hand-off notes, it left one line: *"Boss HP distribution is a design call for the owner."*

It never asked for me. It just wrote down, in the paperwork, where my job started.

## 6. Run B, bug #1: left and right
![GLM build title screen: STARLANE in cyan over a nebula, a low-poly ship above a PLAY button](https://assets-blog-qcentic.b-cdn.net/9/07-glm-launch.png)

*The build I flew, cycle after cycle. Every fix below came out of that.*

My run was a different shape of work entirely. GLM-5.3-Flash executed reliably under instruction — it was never the bottleneck. I was. And the reason I was the bottleneck is that the game kept telling me things no log line can say. Two bugs, out of the dozen-ish we caught this way, tell the whole story.

First: I added crosshair aiming — camera ray to an aim plane, nose tilting slightly toward the cursor, twin shots converging on the point. The model implemented it as a pure math module with 13 pinned test cases, all green. I flew the ship, moved the mouse right, and **the nose tilted left.**

Two seconds. That's how long a human who is *playing* needs to catch a sign error that a 13-case suite waved through with perfect confidence — the tests asserted what the model thought to assert, and "the sign of a yaw feels mirrored when you flinch" was not one of the cases. The fix was one negation and a new pinned case. The *diagnosis* was me, flying.

## 7. Run B, bug #2: the explosions that missed

Enemy darts are the kamikaze class in STARLANE: they hold their stance, then dive at you and detonate. In the build they dove, they exploded, they dealt damage — all correct, all logged, all tested. And on my screen they **visibly never touched the ship.** Airburst, a ship-length short of my hull, every time.

The arithmetic of that bug is beautiful, in the way only a human-watching bug can be beautiful: the contact check added my ship's hit radius (0.9, freshly halved the day before when I decided the ship was too big) to a stale hit radius (11) left over from an old placeholder cube. **11.9 studs of forgiveness**, silently, because two numbers that had each made sense on their own had never been looked at together by anyone who was watching the screen.

The fix was to stop hard-coding sizes entirely: hit radii now derive from the *placed* mesh template — the one I had resized **by hand, in Studio, with my own eyes** until the proportions felt right, then declared canonical. That workflow — human hands set the feel, code consumes it as-is — became a law of the project. It exists because of this bug.

And it wasn't one bug, it was a *texture* of them, all caught the same way: everything parking 85 studs out because a doc number was never a feel number ("everything at 85 is very far away" — my words, now a per-enemy-type distance table); darts wobbling in their hover because their parking spot inherited formation sway ("stay at that location"); the ship too big (halved it, flew it, agreed). Every one of these was a post-playtest fix. None of them was a test failure. All of them were *the game being wrong in ways only a player can see.*

![GLM build: a squadron holding formation above an enemy carrier, scrap pickups drifting toward the ship, 27 kills banked](https://assets-blog-qcentic.b-cdn.net/10/08-glm-formation-and-pickups.png)

*A formation holding at a distance I picked by flying at it, not by reading it. The GDD's number put this group 85 studs out — far enough that the screen read as empty. Every hold distance in the build is now a per-enemy-type value I set with my eyes.*

Here's the part I want the demo videos to hear: my run also had a flight-feel side quest — a procedural cockpit interior, even a speculative genre pivot — and I killed it, reverted the entire workspace to a clean checkpoint, and refocused on the rail build. A solo agent would never have taken that detour, and never needed to. The detour cost me hours and made the game feel like *mine*, because flight feel is the kind of thing you can only iterate by flying.

The bottleneck was never the model. It was me not having played yet.

## 8. The result that isn't a game

Halfway through my run I noticed I was fighting two things at once: the model's implementation — the normal, expected fight — and the **document's direction**, which I had not expected at all. I'd keep correcting the build toward the games I actually played when I was younger — on Sega consoles, on the PS1, on an Atari — and feel the GDD quietly pulling back the other way. The hold distances, the pacing, the read-the-sky of it: the document knew the genre the way a Wikipedia page knows a city it has never visited. Slowly it became clear the obstacle wasn't (only) the model. The spec was wrong — wrong in the specific way a thing is wrong when it was written by someone who has read every review of a film but never sat in the cinema. Remember who wrote it: Fable 5.1. The referee had been wearing one team's jersey the whole time — and, tellingly, that advantage didn't help that team either. An interpretation of your childhood is not your childhood. You can generate the document. Somebody still has to have played the games.

And then I did the thing no demo video will ever show you. **I stopped.**

Not because GLM ran out of capability — it would happily have built all night, and it was never the bottleneck. I stopped because my involvement had done what involvement does: it showed me the actual state of the plan. Playing the game, cycle after cycle, had surfaced a considerable number of flaws in an AI-written document — flaws no reading of the GDD would ever have found, because they lived in the gap between the document and the game it described. And my work experience said the rest, with a voice I've learned to trust over the years: **nothing goes as plan. Ever. But a plan is needed** — without one there's nothing to steer against. The conclusion is not "write better plans." The conclusion is that the plan is a living thing: it changes as you play, as you test, as you interact with the software. You test, you prototype, you pivot, you test again, you brainstorm, you cycle. That cycle — not any single artifact it produces — is what makes a game, an app, any engineering product a reliable and useful tool. This isn't a game-development insight. It's the whole job, in every kind of software there is.

So I dropped my run at roughly **eight hours** of real involvement — six or seven if you only count honest work — deliberately unfinished. What I had at that moment: a prototype I could actually play. Dodge mechanics, working bullets, flight I could steer, formations I could read on screen; a codebase I could imagine scaling, understandable end to end. And a notes file that documented every change and every decision my playing had forced: **the plan, bending under play, in writing.** That notes file is the key takeaway of this experiment. Not the prototype. The trail.

Now look back at Run A through that lens, because this is where the experiment's real result lives. Fable did not run out of capability. It used *all* of its capability to deliver the plan, because it saw the plan as the objective. And remember what I had told it: *don't ask me anything — build everything on your own.* Full authority, full permission to decide. What would a real engineer do with that authority? Decide, test, change the thing. What did Fable do? It never once flagged the plan itself as the problem — no "this hold distance will read as empty," no "this pacing is wrong." The single design call it hesitated on, you've already met in §5: filed as someone else's job in the hand-off notes. It executed a hypothesis as if it were a contract, and it executed it beautifully.

If a big model, on its own, does not arrive at the conclusion that the plan changes as you interact with the software — if it cannot run that cycle unprompted — then it doesn't matter how good it is at Minecraft-alikes or benchmarks. Delivery isn't the job. The loop is.

## 9. Results — the honest numbers

First, the disclaimer I owe you: **by no definition is either build publishable.** I can open the GDD and the economy model right now and list complaints against each build for hours — pacing, readability, reward feel, UI polish, dozens of places where each game quietly disagrees with its own spec. I've made games myself and worked with real game directors on projects; I know what "this is mid" sounds like in a review meeting, and both of these would get it.

But "both are mid" is not the finding, and framing it that way would be the dishonest version of this article. The two rows of this experiment aren't even fully comparable, because **only one of the runs was trying to finish** — mine stopped on purpose, at the exact moment the learning stopped. So read this table as *what each process actually produced*:


|                 | **Fable 5.1 (solo)**                            | **Me + GLM-5.3-Flash**                                      |
| --------------- | ----------------------------------------------- | ----------------------------------------------------------- |
| What came out   | A delivered plan: full game, every GDD feature  | A prototype, stopped on purpose: playable, dodge + bullets  |
| Code            | ~32k lines · 242 tests green · 0 runtime errors | Smaller, scarred by iteration · custom suite 271 green      |
| The plan itself | Executed as a contract — never challenged       | Bent by play — every pivot written down                     |
| My hours        | ≈ 0 during the run                              | ~8 — and I chose where they ended                           |
| Wall-clock      | An afternoon                                    | Several days of evenings                                    |
| Model spend     | Considerably more                               | Pennies                                                     |
| What it proved  | Frontier models can deliver plans               | Small model + human runs the loop — the loop is the product |


Fable shipped the *implementation* of a game — and a good one. My run never shipped a game; it produced something you can't see in a repo listing: a playable prototype **plus the trail of every decision that changed the plan underneath it.** Fable's build is the one that would need weeks of me before I'd put my name on it. Mine is the one that already knows what's wrong with the plan — because it's written down.




| Run A — Fable 5.1 | Run B — me + GLM-5.3-Flash |
| --- | --- |
| ![Fable's RUN OVER screen: waves cleared, kills, bosses, best chain, time, ship, and a banked scrap / XP / parts column](https://assets-blog-qcentic.b-cdn.net/14/09-fable-run-over-summary.png) | ![GLM's RUN SUMMARY screen: kills, scrap banked, distance, and FLY AGAIN / MENU buttons](https://assets-blog-qcentic.b-cdn.net/15/10-glm-run-summary-death.png) |

*The same moment in both builds — the screen you see when you die. Left: every field the GDD specifies, delivered. Right: the three numbers I actually wanted to read while playing. A finished delivery next to a stopped-on-purpose prototype.*



## 10. The money math nobody does

"Model cost" is the wrong denominator, and the demo videos quietly rely on you never doing this arithmetic:

**shippable cost ≈ model spend + (human hours after the model stops) × your rate**

Fable's run was cheap in *my* hours — and produced a project that needs weeks of a human who plays before it's something I'd put my name on. Those hours are real money; they're just billed later, in the long unpaid tail after the demo video ends. (I never spent them. The run ended the way demo runs end.) My run spent about **eight hours** of real work — direction, playtests, fixes, the decision trail — against pennies of model spend, and then I *stopped spending*, because the learning was done and the next hour would have gone into polishing a plan I already knew was flawed.

So: is the frontier model "cheaper"? No — its invoice just arrives after the demo ends. Is the small model cheaper? Only if your time is free — but price both runs honestly, and my eight hours bought the most valuable artifact this experiment produced: the knowledge of where the plan was wrong. The frontier subscription bought a flawless execution of that same flawed plan.

Which means the headline result is uncomfortable in a specific way: **I cannot justify the price of Fable 5.1 for this class of work.** Not because it isn't impressive. Because "delivers the plan perfectly" is the wrong product — and paying more for it doesn't make it the right one.

## 11. The Minecraft question

None of this changes what Fable 5.1 is: an impressive machine, and the demos are real. But a Minecraft-*alike* is not Minecraft, and the gap between them is exactly the part I don't think anyone has shown an agent crossing:

- **Redstone** — a physical logic system inside which players build *computers*, and which the design must carry without collapsing.
- **A real mod system** — an API surface third parties build ecosystems on, which means a design stable enough to be depended on.
- The ten thousand invisible decisions that make the sandbox feel alive after hour 100, not minute 40.

Here's what my experiment adds to that list: Minecraft itself was never *delivered* — it was **iterated into existence**. Mojang shipped the 2011 artifact as something far smaller than any demo-video clone, then spent years playing it with millions of people: test, prototype, pivot, cycle. The Minecraft everyone wants cloned is the residue of that loop, not the output of a plan.

So yes — I still want to see whether a frontier model can clone Minecraft proper: redstone, mods, the works. But the deeper question is whether it can make *the next* Minecraft — a game that doesn't exist to be cloned yet, which means running the loop against a plan nobody has validated. My experiment says: not alone, not yet. And the missing ingredient isn't model size.

## 12. What I actually believe

Here's my assumption, and this experiment is the strongest evidence I have for it: no matter the model — Astra, Fable 5.1, GLM-5.3-Flash, Kimi K3, whatever ships next year — they will need humans who play, share comments, know what they're doing and what they're seeing. People's touch and dedication are what give projects value. Take that away and we slowly force ourselves to accept the mediocrity of models that, despite being strong at implementation and coordination, lack our vision and perception. A model can land 32,000 lines of working code and zero runtime errors. It cannot tell you whether a dive attack *feels* fair — and it will not on its own decide that the plan it was handed is wrong and start the cycle again. That's not a missing feature. That's the job.

At the same time, I disagree — emphatically — with the people who just despise AI. It is a sophisticated piece of technology, and its proper use is going to change the world for the better. But we've trained them enough. They are powerful enough. **We don't need more. We don't need stronger. We don't need better. We need to improve ourselves and our work with them.**

I won't hand you a rulebook for building games with AI — I'm not the most qualified person to write one, and the honest version is short anyway. What I'm carrying into my next project with a model is five sentences:

- **Playtests belong to the human.** In my workspace this became literal law — the agent never touches a playtest; it tells me what to test, I fly it. Every control-feel fix in my run traces to that rule.
- **There is no test for fun.** Budget the hours for a human who plays, or budget for a worse game; there is no third option.
- **Audit a model-written spec like a build.** It's a draft with confidence — review it the way you'd review code, or it quietly becomes the ceiling of both builds.
- **The plan is law for the model, and a draft for you.** Play, change it, write the change down. My run's real deliverable wasn't the prototype. It was the decision log.
- **Stop when you stop learning.** I dropped my run at ~8 hours, mid-build — and it was the most correct engineering decision in the whole experiment.

The bottleneck in this experiment was never the model. In one run it was the absence of a human. In the other, it was me — and that was the point: the plan changed because I played, and I stopped when the plan had nothing more to teach me. Both runs together are the best proof I've seen that the future of game development isn't *AI replaces developers*. It's **games made by people who play, with models that type very, very fast.**

## The code

The whole experiment — the spec, both isolated builds, the skills, the research files, and the decision log — is public in one repo: [Github Repo for Blender Roblox Experiment](https://github.com/mrfqcentic/blender-roblox-experiment)

Clone it, play both — and before you judge mine for being unfinished, read the notes file. The games were never the deliverable. The loop was.