I'm building an action RPG in Unreal Engine 5.8 with Claude Code. The game stays unnamed in any public account, and it's in development — there's a playable packaged build I'm testing with a controller, but it's not shipped. What's worth showing isn't the game itself. It's the machinery underneath: 81,707 lines of C++, 519 subagent conversations, 250 logged decisions, and 157 prompts of direction.
What it is and why I built it
An action RPG in Unreal Engine 5.8. I direct, decide, purchase and playtest; the agent writes the code, tests and documentation. The current phase is cleanup, truthful tests and validated data rather than new content — the kind of work that surfaces only when you play the thing with a controller in your hand.
I built it because I wanted to see if I could. I've shipped production systems with AI agents — Content Ops, Sadyr, LEGION — and those are business tools with clear outcomes. A game is different: real-time physics, input handling, state machines, combat feedback, and all of it has to feel right when you're holding a controller. If the agent could handle that, the architecture was sound.
The infrastructure, measured
I ran a full measurement pass on 20 September 2026. The numbers:
- 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, from 4 July to 20 September 2026
- 104,912 lines of hand-authored Markdown across 381 files — 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.
- 26 orchestrating Claude Code sessions and 519 subagent conversations, with subagent output outweighing the main thread about 7.8-to-1 by output tokens
- 250 recorded product decisions
Those are measured figures, pulled from the repository on that date.
My own prompts: 157 prompts in the two weeks when three-quarters of that C++ was written. Those 157 prompts totaled about 53,000 typed characters of direction. The window is 7 to 20 September 2026, covering about 75% of the production C++ as it stands and about 90% of the project's commits. The remaining quarter of the code survives from a two-day scaffolding burst in July whose session transcripts no longer exist, so those prompts can't be counted.
The agent could not do four things: purchasing and licensing calls, installing the engine, adopting a design document wholesale, and playtesting with a controller in hand. Everything else — the code, the tests, the documentation — came from those 157 prompts.
What broke and how I fixed it
Nine weeks of nothing. The commit history shows two days of scaffolding in July, then 63 days with zero commits, then a resumption at far higher intensity. The gap wasn't abandonment. The Unreal Engine version in use lacked a capability the project needed, and work resumed once the next engine version shipped. This is a common enough problem in game development: you hit a wall, you wait for the tooling to catch up, you keep going. The project stayed in development the entire time.
Tests that couldn't see the game. 30,069 lines of automated tests existed, and the defects that mattered most still surfaced only when I played the packaged build with a controller. The tests passed; the combat feedback was wrong. The state machines validated; the input handling felt sluggish. Automated tests catch logic errors. They don't catch whether something feels right when you're holding a controller and a creature is charging at you.
I fixed this the way everyone fixes it: by playing the game and filing bugs when something felt off. The agent could write tests for the bugs I found, but it couldn't find them on its own. That's fine. It's not supposed to.
The measurement report drifted, and was caught. The first draft of the 20 September stats report understated several figures and had a pattern-matching bug that miscounted answered items in my decision inbox. A fresh-context check and a second pass caught and corrected both before anything was published. This is a known problem with agent-generated reports: they drift if you don't validate them. I validated it, found the drift, fixed it. The numbers above are the corrected ones.
The agent harness, and where this work sat against the industry
I started building LEGION — the orchestration layer that runs my systems — in March 2025. The vision was simple: I wanted to be able to have a discussion with a VP about strategic initiatives while the research, problem solving, asset acquisition and fulfillment were handled by the AI organization without further input from me.
March 2025 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 blogged that "agentic orchestration has emerged as a new paradigm for LLM-powered applications to handle more complex tasks." The industry was converging on the same architectural insight: the model alone isn't the product. You need an orchestration layer — what would later be called a harness — to make it work reliably.
My 2025 failures line up with what the harness writing is about. In April 2025, I tried Docker + FastAPI + LangChain: agents lost work in wiped containers, edited the UI into black-on-black, refused tasks, and ignored the handbook until a default prompt forced it. In May, I tried LEGION v2.0 in Lovable; the GitHub connection failed. State that doesn't survive a session, agents ignoring their instructions, agents editing things they shouldn't — these are the problems Anthropic's "Effective harnesses for long-running agents" (26 November 2025) and OpenAI's "Harness engineering: leveraging Codex in an agent-first world" (11 February 2026) were written to solve.
On 10 September 2026, roughly 18 months after I first described it, LEGION was actualized. It was powerful enough to rebuild the entire website within a couple of hours. The game came together in the same orchestration layer, using the same harness, with the same basic loop: I direct, the agent writes, tests validate, I playtest.
What's next
More playtesting. More bugs filed. More cleanup. The current phase is truthful tests and validated data, not new content. I'm not rushing it. The infrastructure is sound, the build is playable, and the work is worth showing even if the game itself stays unnamed and in development.
The receipts are on the receipts page. The architecture is reusable. The failure reports are here because they're useful. That's the point.