The Harness, Not the Prompt: What Actually Gets an AI-Built Game Shipped
Synergised Consulting Ltd
Last Updated: 12 October 2026
Yes, AI coding agents can now build and ship a complete consumer product, and the independently documented reason is not better prompting. A working 3D game for dog owners went live this week at peemail.app [5]. Across every first-hand build log of this kind, the same mechanism separates a demo from something shippable: tools that let the agent see its own output, test it, and fix what the tests catch, before a human ever plays it.
An AI-built game just shipped, and that part is no longer the news
Software built largely by an AI agent is reaching the point where it ships to real users and keeps working. This week a three-dimensional game called Peemail went live at peemail.app, pitched as a postal service for dogs: owners post a "peemail" every time their dog marks a spot, and can see which other dogs marked the same pole before them [5]. It is an installable web app, it runs in a phone browser, and it is a finished consumer product rather than a prototype.
The interesting question is not whether an agent wrote the code. According to Anthropic's own engineering write-up of its multi-agent research system [1], a system where a lead agent spawns parallel subagents outperformed a single agent by 90.2% on its internal research evaluation, and that orchestration capability is exactly what coding agents now apply to building software. The capability to write the code has largely stopped being the bottleneck. What the build logs of the past few months document, consistently, is a different bottleneck entirely.
What actually made these builds work: the agent could see its own work
The single pattern that recurs across independent first-hand accounts is a feedback harness: automated tools that let the agent observe the thing it is building, run it, and check its own work against a definition of "working".
The screenshot-and-playtest loop
Caleb Leak, who documented a much-shared experiment in which his dog's keyboard mashing was turned into playable games, is explicit that the input was never the point. A typical game reached a playable build in one to two hours [2], but he found the games would build and run while still being broken in ways invisible to the code: no sound, no player character, controls that were nearly unusable. The fix was not a better prompt. It was two small tools: one letting the agent screenshot the running game, and one letting it send input sequences and read the screenshots back. With those in place, the agent became its own play-tester. Leak describes watching it play through all six stages of a game purely to verify that the final boss fight worked, find a health bar that was not updating, fix the code, relaunch and confirm the fix [2].
A definition of "done", checked mechanically
The same build log documents a cheaper fix with the same shape. Early games were repetitive and often missing basics until Leak added a checklist of minimum requirements: working audio, WASD or arrow-key controls, at least one enemy or obstacle, a visible player character. Results improved noticeably once the agent had something mechanical to verify against [2]. David Quintanilla, who built a Nintendogs-style 3D dog in a day across 14 commits with Claude as co-author [3], used the same loop at a finer grain: the agent took screenshots of its own work and compared them against photographs, iterating until the render matched.
This is the step most attempts skip. An illustration of the difference: two owners ask an agent to build an internal booking tool. The first gets code that compiles, a form that renders, and a demo that works right up until two people book the same slot. The second writes down four things that must be true, gives the agent a way to try each one, and receives a tool where those four checks have already been run and passed. The agent in each case is the same. What changed is that the second owner made "working" checkable, so the defect surfaced in an hour on the agent's screen instead of a week later on a customer's.
Where the harness idea comes from
None of this is improvised by the agents. According to Anthropic's engineering account of its own multi-agent system [1], the lead agent is given explicit scaling rules, because agents are poor at judging their own effort: a simple fact-finding task takes one agent with 3 to 10 tool calls, a comparison takes 2 to 4 subagents with 10 to 15 calls each, and only genuinely complex work justifies more than 10. Early versions without those rules spawned 50 subagents for simple queries. The lesson generalises directly to coding harnesses: structure and verification have to be designed in by the person commissioning the work, and the agent then executes inside that structure.
What the harness pattern costs
The economics are unflattering and worth stating plainly. According to the same Anthropic engineering write-up [1], multi-agent systems consume roughly 15 times more tokens than ordinary chat interactions, which is why that team concludes the architecture only makes sense where the value of the outcome justifies the spend. Parallel agents cut research time by up to 90% on complex queries [1], so the trade is money and coordination for speed and coverage.
In our own delivery work we use Claude Code mainly for the testing and verification side of a build rather than the writing side, and the pattern in the published build logs matches what that feels like in practice: the writing is the quick part, and the iterations that matter are each one a screenshot, a test run and a diff.
For a small business commissioning this kind of work, the cost question is therefore not really about tokens. It is about who designs the harness. The harness is one-off, reusable work, and once it exists, each subsequent build inherits it. That is why the cost profile improves with the second and third build even though the model doing the building has not changed.
Where one-day builds still break
Honest build logs are as useful for their failures as their successes, and all of them record limits.
Quintanilla states the ceiling of his build precisely: "where it got stuck was the face", which he puts down to the limit of what is possible without a hand-made 3D model [3]. The dev.to build log of a full game built in a day from a three-sentence prompt reports bugs found and fixed the same day, including a boss that returned at full health and a beam that could be walked through while invulnerable, and the builder's own verdict is "I will not call the build bug-free" [4]. Leak found the agent's own memory could become a liability: it kept producing the same glowing neon aesthetic until he wiped its persistent project notes before each new game [2].
None of these are reasons to dismiss the approach. They are the reason the pattern requires a person at the checkpoints. The agent tests mechanically and tests well, but only against the checks it was given, and "does this actually delight a player" is not yet a mechanical check.
What an owner can usefully take from it
In discovery workshops, owners routinely arrive assuming the valuable part of a build is the writing of the software, and are surprised that the reliable part is the verification. The transferable move from these build logs costs nothing and applies to any internal tool, AI-built or not: before commissioning work, write down the four or five things that must be true for it to count as working, and make sure something, agent or person, actually runs those checks before you are shown a demo. The build logs that shipped are the ones where somebody did that.
Sources
- [1] Anthropic, "How we built our multi-agent research system", 13 June 2025,
- [2] Caleb Leak, "I Taught My Dog to Vibe Code Games", 23 February 2026,
- [3] David Quintanilla, "A 3D dog in Three.js with no models, just code", 7 October 2026,
- [4] Tiago Vilas Boas, "I Built a Full PWA Game in One Day with Claude Opus 5.5 and Claude Code", 4 October 2026,
- [5] Peemail, live site, verified 12 October 2026,
