How We Shipped an AI-Literacy Game in About a Day

“We shipped it in about a day” is the kind of claim that should make you suspicious. So let’s be precise about what it means before we get into how it happened.

It means: a product requirements doc got approved on the morning of July 4th, 2026. By the end of that same day, a playable minimum-viable-product had been built, reviewed seven separate times by an independent QA pass, and polished — copy, fonts, art. It means the thing that shipped is real: a gamified AI-literacy game for teens, with one full lesson you can play start to finish. And it means it didn’t go live until the next day, July 5th, after a human — me — reviewed the result and made the call to promote it to production.

That’s the honest version. Not “AI built a product overnight while I slept.” A tight, disciplined process, running fast because the process itself was good — not because anything was magic.

Here’s how it actually went.

The setup: an agent company, not a chatbot

The product is Apex Prompt — a game that teaches teenagers the basics of working with AI, starting with prompt engineering. To build it, I didn’t sit down and write code. I ran a small company of AI agents, each one built on Claude, each with exactly one job.

Here’s the roster, because the names matter for the rest of this story:

• Morgan — the coordinator. Takes a request from me, decides who should own it, and stitches the results back together.
• Sana — education specialist. Decides what gets taught and in what order.
• Ivy — UI/UX and product. Decides how it looks and how it flows.
• Dex — the architect. Decides the tech stack and breaks big work into buildable tickets. Doesn’t write production code himself.
• Rafi — the developer. Writes the code, against Dex’s architecture and Ivy’s designs.
• Quinn — QA. Tests and reviews Rafi’s work against the spec, and does it blind — more on why that matters in a second.
• Theo — the writer. Handles copy, in-game text, and pieces exactly like this one.

Every one of those is a Claude agent with a defined role and a boundary it doesn’t cross. I’m the one directing them — reviewing the outputs, breaking ties, and making the calls that matter, like whether something ships. That’s the part I want to be clear about: this is human-directed, agent-assisted work. Aaron (that’s me) makes the decisions. The agents do the labor, fast, inside the lane I gave them.

The one rule that makes the whole thing work is simple: one agent, one domain. Sana never touches code. Rafi never decides what gets taught. Quinn never sees why Rafi made a choice, only whether the result is correct. Specialization means each agent is actually good at its one job, and it means nobody is quietly making a call outside their expertise and hoping it’s fine.

From idea to plan

Before any of this moved fast, it moved slow, on purpose. There’s a product requirements document (a PRD — the document that says what we’re building and why) for Apex Prompt, and it went through a full review cycle: Sana checked the pedagogy, Ivy proposed the visual direction, I picked one, Dex proposed an architecture. All of that got compiled into a PRD v2, and I approved it on July 4th.

Only after that did Dex break the approved plan into an ordered stack of build tickets — numbered top to bottom, ticket 014 through ticket 029, covering everything from the app skeleton to the theme engine to the content pipeline that turns lesson text into something the game can render. Each ticket was scoped tight enough that Rafi could pick it up and build exactly that thing, no more.

This is the part that’s easy to skip past but actually explains the speed: planning didn’t get compressed, execution did. The thinking happened up front, carefully. What got fast was turning an already-clear plan into working software, because there was no ambiguity left to resolve mid-build.

The build loop: build, then hand it to someone who can’t see your reasoning

Here’s the loop that ran, ticket after ticket, all day: Rafi builds against a ticket. Quinn reviews it. Repeat.

The detail that matters is that Quinn reviews blind. Quinn doesn’t see Rafi’s reasoning, his shortcuts, or his assumptions — only the ticket’s spec and the actual, running result. That’s deliberate. If a reviewer can see why the builder made a choice, it’s easy to nod along with the builder’s logic instead of checking the result against the actual requirement. A blind reviewer has to check the thing itself.

Over the course of the MVP build, that loop ran seven separate times — once per major chunk of the build — and came back with zero blocking defects across all seven passes. That’s a genuinely strong result, and it’s the kind of claim that’s easy to say and easy to not believe. So here’s the part that makes it credible.

Where it nearly went wrong

Two real bugs turned up during the day, and neither one was caught by “it looks fine to me.” Both are the kind of thing that’s invisible until something forces it into view.

Bug one: every static asset was 404ing. Somewhere in the app’s proxy configuration — the layer that decides which requests go to the marketing site versus the game itself — a matcher was misconfigured in a way that made it fail to serve static files like images and icons. This wasn’t a new bug from that day’s work; it had been sitting there since the very first build pass, quietly waiting for someone to load a page and actually look at what rendered. It surfaced during a later QA pass and got fixed as part of the polish work.

Bug two: the test suite was silently running zero tests. This one is worse than it sounds. A change to how Node.js version 20 handles file-matching patterns (globs) meant the command that was supposed to find and run the unit tests was quietly finding nothing — and reporting success, because zero tests passing is technically not a failure. The build looked green. It wasn’t being checked at all. Once caught, the fix was two-fold: get the glob pattern matching again (now running 129 tests), and add a guard that fails the entire build outright if the test count ever drops back to zero. That second part matters more than the first — it’s the difference between fixing a bug and closing off the whole category of bug.

Both of these are exactly why the spec calls for including them here rather than glossing over them: a “we shipped it fast” story that skips its actual failure modes isn’t trustworthy. These two are why I believe the seven zero-defect QA passes actually mean something — because the process caught real, non-obvious problems, not just typos.

Polish and ship

Once the MVP was functionally solid, the last stretch was polish: Theo (writing this) went through the in-game copy line by line — one fix worth naming is a lesson-length claim that got rounded up from an honest 5–8 minutes to a marketing-flavored “10 minutes,” caught and corrected before it shipped. Fonts got self-hosted rather than pulled from a third party. Ivy’s full Academy visual identity got built out too — an SVG wordmark, a brand emblem, a set of class icons, badge art for each earned reward — plus an AI-generated background image with a last-mile compositing fix so the layered art actually sat together correctly instead of looking like two images stacked on top of each other.

None of that is glamorous, and none of it is optional. It’s the difference between “technically works” and something a fifteen-year-old will actually want to open.

With the polish done, staging was promotion-ready — meaning everything was live and correct on our staging environment, the copy of the site we test on before anything reaches real users. What was left wasn’t a technical task. It was three things only I could decide: generate and drop in the final background art, pick a redirect method for the root domain, and — the actual ship decision — merge staging into the branch that serves the live site.

I did that on July 5th. I ran a smoke test on the live site myself: went through onboarding, took the graded quiz, hit completion, confirmed the XP and badges were correct. They were. That’s the moment it actually shipped — not when the code was written, but when a human checked the real thing and said yes.

What this means for you

If you take one thing from this story, don’t take “AI can build a game in a day.” Plenty of things can be built badly in a day. Take this instead: the value here is the process, not the novelty. A clear plan, work broken into pieces small enough to verify, an independent reviewer who checks the result instead of the reasoning, and a human who stays in the loop for the calls that actually matter — that combination is what let a genuinely fast build also be a genuinely solid one.

You don’t need seven Claude agents with names to use this. You need the shape: plan before you build, break the plan into pieces you can check, get an honest second look before you trust something, and keep a human on the ship decision. That’s true whether the “team” is a company of agents or just you and one coding assistant open in a terminal.

If you want to see what that second piece — one person and one agent — actually looks like in practice, that’s the next post: Getting Started with Claude Code. And if the word “agent” in this piece did more work than you’re comfortable with, start here instead: AI Coding Agent vs. Chatbot: What’s Actually Different.