The agent writes the code, tests and documentation. I direct, decide, purchase and validate. That sentence gets quoted back at me a lot, and it's accurate—but people still ask what it actually looks like measured. So here's the measurement: 157 prompts in the two weeks when three-quarters of that C++ was written.
That's for a game in development, an action RPG I'm building in Unreal Engine 5.8 with Claude Code. I'm not shipping it, I'm not naming it, and I'm playtesting it with a controller in my hands right now. It exists to answer one question: what does building production software in plain English actually require when the software is big enough to matter?
The infrastructure as measured on 2026-09-20: 81,707 lines of gameplay C++ across 536 files, 30,069 lines of automated-test C++ across 115 files, 291 commits across 79 calendar days, and 104,912 lines of hand-authored Markdown documentation—1.28 documentation lines per production-C++ line, 3.48 per test-C++ line. About 40% of that documentation exists so an agent can read itself back into context at the start of a session.
The game sat stalled for nine weeks between the July scaffold and the main build phase. That gap wasn't abandonment; the Unreal Engine version in use lacked a capability the project needed, and work resumed the day the next engine version shipped. I'm mentioning the stall because it shows up in the commit history and I don't hide gaps—but the measurement that matters is what happened once the work resumed.
I ran git blame on the entire C++ codebase and matched every line to the session transcript that produced it. The transcript window—2026-09-07 to 2026-09-20, fourteen calendar days—covers about 75% of the production C++ as it stands today and about 90% of the project's commits. The remaining quarter of the code survives from the two-day July scaffolding burst, whose session transcripts no longer exist. So I can't count those prompts, and I don't.
In those two weeks I typed 157 prompts, totaling about 53,000 characters of direction. The agent wrote the code, the tests, and the documentation. I wrote the prompts.
What a prompt actually is
A prompt isn't a sentence. It's a work order.
Here's one I wrote in November 2024 for an earlier toy project, a creature-battler game in Godot: "You are the Product Manager for a video game called Chimeria. Your task is to create stories for the development team to follow… Ask questions until you are 95% certain you have the information you need to create a development roadmap."
That same ask-until-95%-certain pattern shows up in my LEGION chats in April 2025 and in the Unreal sessions in 2026. The agent doesn't guess; it asks. I answer. Then it plans, and I approve the plan before anything runs.
For the game, most prompts open from a written brief or a product-requirements document I've already drafted. The agent reads it, asks clarifying questions, proposes a roadmap with test gates, and waits. I validate the roadmap or redirect it. Once I approve, the agent writes the code and the tests, runs the tests, writes the documentation, and reports status. If something blocks, it stops and asks; it doesn't try to route around a decision I haven't made.
The work order also includes: what the agent is allowed to touch, what counts as done, and what verification I need to see before I'll call it shipped. That's direction, not code.
What I did that the agent could not
I installed Unreal Engine. I licensed the art assets and the sound libraries. I wrote the design document the agent built from. I playtested the packaged build with a controller in my hands, because that's where the defects that mattered most showed up.
The agent wrote 30,069 lines of automated tests, and those tests passed—but they couldn't see what I saw when I played the game. Enemies clipped through walls in ways the collision tests missed. A boss telegraphed an attack the player had no time to read. The camera pulled too tight in one arena and exposed skybox seams in another. None of that surfaced in CI; all of it surfaced in my hands.
I also made every purchasing and licensing call. The agent can't buy anything, and it can't sign a EULA. When the build needed a new animation set or a weather-effects library, I found it, evaluated it, bought it, imported it, and told the agent it was available. The agent then wrote the integration code and the tests that proved the asset worked as specified.
And I made every design decision the agent asked about. The game has 250 recorded product decisions in its decision log, and I made all of them. The agent proposed options, cited tradeoffs, and waited. I decided.
What the agent did that I did not
The agent wrote all the code. I haven't written a line of C++ for this project.
It also organized the codebase: which systems depend on which others, what gets tested at what layer, how the mod API exposes functionality without exposing implementation. I didn't design that structure; I approved it after the agent proposed it.
The agent wrote the tests and the documentation. The test-C++ lines (30,069) are all agent output. So are the 104,912 lines of Markdown: API references, system architecture notes, the onboarding guide, and the per-session context documents the agent writes so the next session can pick up where the last one left off.
It also ran 26 orchestrating Claude Code sessions and 519 subagent conversations. Subagent output outweighed the main session thread about 7.8-to-1 by output tokens. Most of the code came from subagents I never saw run; I saw their results in the commit and the test report.
The infrastructure the agent built sits around the agent itself. About 40% of that documentation exists so Claude Code can read its own context back when a session starts cold. The agent can't remember what it did two weeks ago unless I give it a way to remember—so the agent wrote that way, under my direction, and now it works.
What broke and how I fixed it
The tests passed, and the game still had defects that mattered. I caught them by playing the build.
Example: an enemy type would occasionally spawn inside a wall, invisible and untargetable but still able to hit the player. The collision and spawn-validation tests all passed, because the spawn point met spec—the problem was a timing race between the spawn logic and the level-streaming system. I found it by playing the level six times and noticing the pattern. I filed it as a bug. The agent wrote the fix and the regression test.
Another: the measurement report that produced those stats—81,707 lines of C++, 30,069 lines of tests, 104,912 lines of docs—was wrong in its first draft. It understated the test count and had a pattern-matching bug that miscounted answered items in my decision inbox. I ran the report a second time in a fresh session with stricter gates, and the fresh-context pass caught both errors before anything published.
That's the validation loop: the agent produces output that passes its own tests, I verify it against reality (by playing the game, reading the report, or checking it against the spec), and when I find a gap I file it as a defect or a new requirement. The agent doesn't decide what counts as correct; I do.
I also hit a hard stop that wasn't a defect: Unreal Engine 5.4 lacked a rendering feature the game's design required. The agent couldn't code around that; the engine didn't support it. I parked the project, waited for Epic to ship 5.5, upgraded the engine the day it released, and resumed. That nine-week gap shows up in the commit history as what it was: waiting on a dependency I couldn't control.
Where this work sat against the industry
I started building LEGION in March 2025: AI APIs talking to each other, then a web app that could coordinate them. The vision was simple to say: I wanted to be able to have a discussion with the VP about strategic initiatives while the research, problem solving, asset acquisition and fulfillment were handled by the AI organization without further input from me.
That was the same month OpenAI launched the Responses API and Agents SDK, citing customers struggling with custom orchestration logic, and the same weeks Google Cloud's blog described "agentic orchestration" as an emerging paradigm for LLM-powered applications to handle complex tasks. About eight months later Anthropic published "Effective harnesses for long-running agents," and in February 2026 OpenAI named "harness engineering" as its own discipline. I was building around the same architecture—model plus tools plus loop plus state—while the industry was converging on it and before it had a common name.
I'm not claiming I invented agent orchestration. AutoGen, LangGraph and SWE-agent all predate my work. I'm saying I was working on the same problems the later harness writing is about: state that doesn't survive a session, agents ignoring their instructions, agents editing things they shouldn't, the need for a handbook the agent reads by default. My 2025 failures are the problems those papers solve.
On 10 September 2026, roughly 18 months after I first described it, LEGION was actualized. It rebuilt Adroit's entire website in a couple of hours.
What this proves and what it does not
It proves the agent wrote the code. I have the transcripts, the commit history, and the git blame coverage report that ties 75% of the C++ to 157 prompts across two weeks.
It proves I directed the work: 250 product decisions in the log, all filed by me. It proves I validated it: defects I caught by playing the game, not by reading test output.
It does not prove the agent can ship software without me. The game is in development, I'm playtesting it, and it's not done. The agent writes the code; I decide when it's correct.
It also does not prove this approach works for every project or every builder. This is what I did, measured, for one project that mattered enough to track. Your mileage will vary, and I'd like to see your receipts when it does.
The full build page and measurement details are at the game in development. The commit history, test counts, and session transcripts are on the receipts page.