Define the intention
Describe the player-facing outcome and the constraints before implementation.
Build faster.
Judge harder.
I direct two specialised AI agents inside one Unreal Engine project. My responsibility is to define intent, review outputs, catch false assumptions and decide what earns approval.
AI EVALUATIONGAMEPLAY VALIDATIONHUMAN DIRECTION
00 / DESIGN AUTHORITYHuman directionIntent · Briefs · Play · Approval
↙ CONTROLLED LANES ↘
01 / CLAUDE CODESystemsC++ · Blueprint behaviour · Probes
02 / ASTRA / CODEXVisual productionAnimation · Materials · Review assets
↓ EVIDENCE & HANDOFFS ↓
03 / PLAYED AND VERIFIEDHuman approvalImplemented ≠ tested ≠ approved
THE CORE PROBLEM
AI output can look finished long before it works.
Agents can implement quickly. They can also rely on stale defaults, misread project constraints or report success from a flawed test. The pipeline exists to narrow that gap.
01 / RESPONSIBILITYOwnership before
Ownership before
execution.
Claude handles gameplay and system implementation. Astra handles materials, character work and animation. Shared assets require explicit handoffs and defined ownership.
I set the design direction, write briefs, review the outputs and personally play-test what goes into the game. The agents implement much of the code and asset work; I don't present that authorship as my own.
THE CONTRACT
One task at a time. Evidence before claims. No silent asset promotion. No creative approval by the implementation agent.
Bound the work
Assign the responsible lane and keep shared resources under explicit control.
Find what is real
Use probes, source inspection and live-value checks to challenge confident claims.
Approve by experience
A working build is not approved until it survives an actual play session.
02 / EVALUATION
Proof before claims.
I started by reading generated C++ in Visual Studio, compiling and checking behaviour directly. As the project expanded, I built a more systematic review workflow with probes, measured tests and staged approvals.
The dead card
A game card appeared implemented, but its live Blueprint parameter was zero. The header value looked correct; inspecting runtime configuration revealed the difference.
CHECK THE LIVE VALUE, NOT JUST THE SOURCE DEFAULT.The faulty audit
A scripted audit reported features missing that were present. The audit's own matching logic was wrong, so we corrected the checker rather than inventing missing work.
VALIDATE THE TEST HARNESS ITSELF.03 / VISUAL REVIEWControlled
Controlled
iteration.
Visual redesigns pass through staged reviews: values, regions, lines, highlights and detail. Each stage has defined constraints and a named approval before proceeding.
A preview that looks right isn't necessarily ready for production. I use fixed-camera comparisons, isolated trials, dependency checks and documented promotions.
01ProposeBounded brief
02CompareMatched evidence
03ValidateBehaviour + assets
04ApproveNamed decision
04 / COORDINATIONLess context.
Less context.
Better decisions.
Short status files, lane rules and handoff notes replaced an oversized running log. The project records not only what was built, but also what still needs to be played and what the designer has explicitly approved.
Further orchestration is being explored; it is not yet a deployed autonomous system.
SEE THE GAME THIS PIPELINE SUPPORTS ↗