Two abandoned games and the one-shot prompt
Here for the TL;DR? The games are finished and playable; scroll down and play them. The rest of this is why that took a year.
On the evening of October 2, 2026, curiosity was ignited by an email that landed in my inbox from a higher-ed career platform, offering prize money to eligible students for prompting a full multiplayer game, via ChatGPT, into existence. I opened two terminal sessions and typed almost the same paragraph into each one.
This is an abandoned, human-architected, AI-engineered web-based game… It was abandoned due to issues with playability, difficulty, … game pacing, menu issues, and several other tiny and large problems. See if you can fix it up, improve it, and genuinely finish off the game end-to-end. You may ask clarifying questions on gameplay goals if you need to, but the documentation should be sufficient enough at this point.
The first went to a game I'd left roughly twelve months earlier. The second went four minutes later to another one I'd left about ten months earlier. I've omitted some specifics intended for the separate games via the ellipses above, but you get the idea. The two prompts added one extra sentence — "you have the freedom to improve upon the concept, graphics, etc." — and that difference turned out to matter.
I expected the familiar loop. Every previous encounter with these games had been iterative: prompt, watch, review, correct, repeat, and eventually get tired. What actually happened is that the model asked me nothing. It read what was in the repository, decided the documentation was sufficient, and finished both games in a single pass each. The two final commits landed four minutes apart.
As noted on this website, I've been working in technology for over twenty years now, often managing and participating in software development projects. I did not expect that, and I would have been suspicious of anyone who told me a year earlier that it was coming. This essay is my attempt to say precisely what that evening did and did not accomplish — because the honest answer is that it solved the problem I had been fighting, and made the problem I had never named impossible to ignore.
What I was actually doing in 2025
I want to start where the repositories start, because the story is not "AI got better at writing games." It is narrower and more interesting than that.
In September 2025 I committed 3,262 lines of design documentation to Bit Bop Bytes — art direction, a technical specification, an implementation guide, and a set of workspace rules — before writing a single line of game code. The documents were addressed, quite literally, to a machine. They contained sections titled "AI Prompt Templates for Windsurf/Cascade" and phase-by-phase implementation prompts. Fail the AI followed the same doctrine a month later: 2,768 lines across twenty-six files in its first commit, four design documents and a scaffold, and its technical guide named Codex and Claude Code as the intended implementers.
This was not naivety about what the tools could do. It was a reaction to what happened when I didn't do it. My early attempts at agentic development were, in my own notes, "wild and crazy and all over the place." Agents got lost on tangents, developed one area and forgot it, built redundancies and forgot those too, and occasionally removed something that shouldn't have been removed (and sometimes, not so occasionally). I learned to front-load architecture and constraints so the model had a place to color inside the lines. Time and again I learned that what I considered inferrable was, in fact, not at all.
Behind those committed design docs was a phase no repository records: weeks of iterative planning with the then-current Claude Opus — rejections, divergences, suggestions, modifications — until I was satisfied enough to begin. The specs were the output of that. So when I say the games were "human-architected," I mean it quite literally, like I had spent weeks deliberating product and project specifications before waltzing over to my team with the final specifications, ready to begin the first sprint. The architecture, the mechanics, the art direction, and the definition of done were mine. The implementation was handed to a sequence of tools.
And the tools were good. In Bit Bop Bytes, September 8, 2025 produced sixty-one commits in a single day. I set the architecture, the agents filled it in, and I merged. I thought of myself as the director and the agents as an implementation team, and the analogy held.
It held until it didn't. On September 11 the game stopped rendering — not a subtle bug, just a border where a game should have been. The recovery commit is titled "restore fully functional game," and I created a file called LAST_KNOWN_WORKING.md as an emergency reference, which is exactly as ominous as it sounds. The cause was not a bad model. It was that a model could satisfy each request in front of it while losing the coherence of the whole. Six months later, a pause-menu settings path could still strand a player with no way to resume, and the entire suite still passed: type-checking, linting, the tests, the production build, a security audit. Everything was green and the game was broken in a way no agent-devised test was looking for.
Fail the AI failed differently and more honestly. Its concept was genuinely good — the AI plays a falling-block game, you are the hacker sabotaging it — and its implementation taught the wrong role. I had left the player direct control of the pieces, so the obvious activity on screen was "play a falling-block game and occasionally press an attack button," while the intended fantasy — observe an AI, corrupt its perception, cause a fault — was invisible. Sabotage had no readable cause and effect. You could not tell whether you were winning. The falling blocks moved too fast to plan against, instantly dropping into place. More importantly, the entire cyberpunk spirit I had devised - the AI trying to trace the player, chatting allowed in a fake terminal session in wonder as to what is going wrong, was never executed correctly in any way, shape, or form. The project ended with a passing test suite and a successful build, and the game still wasn't fun. Its own postmortem, written later, contains the sentence I still find the most useful thing either project produced:
Fail the AI sounded better as a game than it felt as a game.
That is not a story about incompetent tools. It is a story about tools operating at a particular point on a rapidly moving curve. They could implement a system; they could not hold a whole product in mind. The projects stalled at that wall, and then they sat.
The year they sat, and the false summit
Both repositories go quiet for roughly ten months. The gap was not a plan to wait for better models. It was time and token cost, prioritized — correctly, I think — toward work that paid, and away from these hobby projects. The games were finally officially archived in early August 2026, both on the same day, both described as complete. Bit Bop Bytes got an archival retrospective. Fail the AI got a 355-line postmortem.
Of course, "archived as complete" is the most misleading phrase in this whole story. It means the creative goal had been honored, not that the game was finished. Both were declared done and both were not done. Completion, in that moment, was a decision I made about how much more of my life a hobby project deserved.
I also want to record the false summit, because it is easy to narrate a clean victory and this wasn't one. Before the postmortems, I ran a maintenance pass on Bit Bop Bytes with GPT 5.6 in Goose Desktop — a "modernized pass," the only commit in either repository that names a model. I was frustrated and disappointed with it. Even after it completed, I wasn't sold on using it or writing about it, which is why it still sits unmerged on a branch. That branch, chore/upgrade-build-toolchain, never reached main. The later, successful repair did not descend from it.
That fact matters for the story I'm telling. The popular version of we hear about agentic development — each smarter model handed the project up to the next, like a relay — is false, and the git graph proves it. What changed was not a smooth hand-off. What changed was the size and quality of the artifact a model could hold at once, and the method for reading it.
What the model actually had to work with
If the October evening reads as magic, it shouldn't. The model did not invent either game, and it did not start from nothing. It inherited a great deal, and naming that inheritance is the point of this section.
It inherited my architecture, which had survived. Bit Bop Bytes' entity-component structure, object pooling, spatial collision, and twenty-wave campaign were unchanged by the final repair. The repair filled in reserved-but-empty slots — the config file had almost no tuning parameters; the repair added player and combat constants — upgraded collision from a bounding-box test to a swept, sprite-aware one, and converted the pause menu from canvas-drawn to native DOM so that keyboard and accessibility behavior worked. The architecture was fulfilled, not revised.
It also inherited the accumulated work of the earlier agents: fifteen systems, eight UI components, and a test suite to build on. And it inherited documentation that had been written for agents — AGENTS.md, CLAUDE.md, a GEMINI.md in the other project — which had evolved from a novelty into the actual operating manual of the codebase.
But the single most decisive artifact in either repository is smaller than the specs and easier to miss. It is the Fail the AI postmortem. That document does not merely describe a failed game; it prescribes the fix, point by point:
| The postmortem said | The rebuild did |
|---|---|
| The player cannot control the falling piece | Removed direct piece controls |
| The AI announces its intended move before placing it | Added visible AI plans and landing outlines |
| Bitflip should visibly highlight a cell and change the preview | Added corrupted-glyph previews |
| A successful disruption needs a large, unambiguous fault | Added confirmed sabotage outcomes |
| Prefer deterministic teaching outcomes over random ones | Added seeded RNG; faults compare intention to reality |
The rebuild went further and removed the player's ability to move the pieces at all, which is the conceptual fix the original game never made. That is the single strongest piece of evidence in the whole corpus, and it is not about model names. It is that a human diagnosis, written as an admission of failure, became the specification a later model implemented. The postmortem compressed the learning curve. The model did the work.
So the real capability change, stated plainly, is this. In 2025 the unit of human input was a per-feature prompt and the agent's scope was one file or one task. By 2026 the unit of input was one whole-repository directive and the agent's scope was the entire codebase, its history, and its accumulated intent. The context a model could hold grew from a paragraph to a project. That — not a mysterious leap in cleverness — is what made the evening possible, and it only worked because a year of human architecture, agent implementation, and human diagnosis was sitting there to be read.
What it could not do
The games work. Both are playable end-to-end in a browser. Bit Bop Bytes ships a twenty-wave campaign, four bosses (that, despite extensive design documentation, all look and function identical), challenge modes, and an Endless mode, validated by 137 unit tests, 19 browser checks, and two production smoke tests. Fail the AI was rebuilt around its premise with deterministic simulation, three difficulties, and a proper feedback loop, validated by 39 simulation tests, 10 real-browser tests, and what the commit calls 240 seeded full-round scenarios.
The implementation problem was largely solved. That should be said clearly, because it is a genuine threshold and a year ago it wasn't crossed.
And then I played them, and they were too easy. Not unfair, not broken — the opposite of the problem I'd had before, where I couldn't get past wave four or five. The pendulum had swung until there was no challenge left at all. Fail the AI: I beat the easy and medium difficulties in seconds. Bit Bop Bytes: I never ran out of bullets, power-ups dropped like candy, and waves fell in seconds.
That is a felt judgement. What makes it worth writing down is that the repositories contain the proof, and the proof is structural rather than a matter of taste.
Fail the AI' own balance test hard-codes the most naive possible strategy — cycle the three attacks so the AI never sees the same payload twice, purge your trace on a timer, repeat — and then asserts, across thirty seeds and three difficulties, that this strategy wins. It always does. The "240 seeded scenarios" the commit advertises decompose into ninety scripted wins and one hundred fifty demonstrations that doing nothing loses. The test is not measuring difficulty. It is certifying that the game is solved. The reason is mechanical: the AI's only adaptation is to resist the attack you just used, so cycling defeats it permanently, and every attack you don't repeat lands a guaranteed fault. There is no skill gradient left because there is no decision left.
Bit Bop Bytes is easier to diagnose from its constants. Normal fire costs slightly less energy per second than it regenerates, so the resource that was supposed to constrain you never binds. Enemy health and fire rate never scale with the wave; only their count does, and that caps out early. Meanwhile the player accumulates extra lives from five independent sources and a "difficulty balancer" that only ever helps — it increases power-up drops when you're struggling and has no branch that makes anything harder. The game's own design spec had promised a balance harness and a tuning module. Neither was ever built. The tuning constants are scattered across three files with nothing connecting them to an intended experience.
Remember I wrote about the inability to infer? The one-shot prompt named "difficulty" as one of the problems to fix. It never said what good difficulty was. So the model did the reasonable thing with an unspecified target: it removed the symptom it had been handed — a game that was too hard to progress — and produced its mirror image. It fixed the word and missed the meaning. There was no win-rate, no session length, no skill ceiling anywhere in either repository for it to aim at, and no human playtest in the loop to notice the overshoot.
Part of that is on me. I specified a balance harness in 2025 that turned out to be the one piece of the architecture that would have caught this, and it is the one piece I never built, preferring to experiment and iterate the difficulty based on feeling alone. The planning that saved these projects and the planning that failed them are the same document.
Where the finish line actually is
I have spent the last few months on this blog documenting the same boundary from a dozen angles — that an instruction is not enforcement, that text that resembles execution is not execution, that a model can produce a plausible version of almost anything but cannot guarantee a specific one. The two game outcomes teach that same lesson, albeit one level up.
A model can prove a ruleset works. It can guarantee an invariant — every valid attack produces a fault, every purge costs twenty-five and removes thirty. It can make a system deterministic, legible, and reproducible, and it can pass every check you write. What it cannot do, without a human-supplied target, is decide whether the working thing is good. "Works" and "well-tuned" are different predicates. Only the first is machine-checkable without someone first saying what the experience should feel like.
Watch how the definition of done moved across these two projects, because it moved every time:
- Done = it compiles. Until a feature-complete game renders only a border.
- Done = the features exist. Until breadth accumulates into incoherence.
- Done = the checks pass. Until a green pipeline ships an unfinishable pause menu, and a passing test proves the game is trivial.
- Done = the player understands. This is the upgrade the 2026 rebuilds actually delivered — subtraction, legibility, determinism. It is real and it is not small.
- Done = the player is challenged. The ultimate, ever shifting, ever-changing question of game design - and utterly subjective.
I treated the models as my development team while I was the project manager, architect, designer, and QA lead. The residual human work moved up the stack, to deciding what belongs, what to delete, what "finished" means — and then, above that, to the one judgement no commit can contain: whether the finished thing is any good. The economics of this are not the problem. I built both games for barely the price of a couple of coffees a month, and the cost keeps falling. The cost was never the constraint. The constraint is the target.
I can tell you exactly how Fail the AI failed the second time, and the diagnosis is a test file. The game's own proof of correctness is also its proof of triviality, shipped in the same commit, written by a model that finally had the capacity to finish the whole project. The model crossed the finish line and stopped at the edge of the thing that actually mattered, unable to know that it mattered.
The last mile is the player. It was the player in 2025, when the tools couldn't hold the project together. It is the player now, when they can. That is a narrower claim than "AI can build games," and I think it is the true one. The frontier did not disappear when the models got good enough to finish my abandoned work. It moved. It is standing somewhere no amount of repository context can reach, holding a controller, waiting to find out whether the game is fun.
It isn't.
Both games are released and playable in the browser: Bit Bop Bytes · Fail the AI. The code is not public. Play them and decide for yourself whether I'm right about the balance.