Field journal Entry 05

The Agent Is Only as Good as the Check That Grades It

6 min read
Claude Code AI Agents TDD Verification Blender Unreal Engine

The tooling around the game I am building, the headless Blender exporters and the Unreal import plugin, is written with Claude Code, and most of that code comes from the model. The tools are reliable anyway, and the credit belongs to the loop I put around the model: align on a one page spec, one failing test at a time, and a deterministic build that makes a passing check mean something.

I build tooling for my game: headless Blender exporters, an Unreal import plugin, the validation that rejects a bad asset before it reaches the engine. I write it with Claude Code, and the model writes a lot of the code. The reason the tools are reliable is not the model. It is the loop I put around it.

Diagram of the loop around the model: align on a one page spec, write one failing test, make it pass, verify against a deterministic build, then return for the next slice. Done is a passing check, never "it looks correct".

The work AI is good at here

Pipeline tooling is repetitive, well specified, and testable. That is the sweet spot for an agent. A normal-map channel flip, a scale check, a folder contract between two programs: each one has a right answer you can write down and verify.

The creative work stays with me. The agent does not design the asset or make the look calls. It builds the plumbing that moves an asset from a script in Blender to a correct prop in Unreal, the same way every time. That split is the whole point. Automate the setup and the checks, keep the judgment.

Align before any code gets written

Most of the bad output I have seen from an AI agent came from misalignment rather than bad code. The agent built the wrong thing correctly.

So I do not start with code. I start with a short interview, one question at a time, until the agent and I are describing the same tool. Then a one page spec: the inputs, the output, the edge cases, what done means. Ten minutes of this removes most of the rework.

Build in vertical slices, test first

I never ask for the whole tool at once. One behaviour, one failing test, one implementation, then repeat.

Take the importer’s normal-map fix. Blender writes normals in OpenGL convention, Unreal reads DirectX, so the green channel has to invert or every surface lights wrong. The slice is small: write a test that asserts the green channel flips, watch it fail, then make it pass. Nothing else.

The slice as a single question. Blender bakes tangent space normals in OpenGL convention, where green is plus Y. One check asks whether the file is a normal map. If it is, the green channel inverts for Unreal's DirectX convention, where green is minus Y. If it is not, the texture passes through untouched, base colour and roughness included. A note underneath reads: the bug the test exists to catch is that the old script flipped every texture, and a blanket flip quietly corrupting base colour is the expensive failure, not the wrongly lit surface.

Working test-first is what stops an agent from handing back a wall of plausible code that does not actually run. The test is the spec the agent cannot talk its way around.

Note what the slice is. It is one question, is_normal_map, with a right answer on both branches, rather than the whole of “fix normal maps”. The earlier version of this code flipped every texture it touched, which looks fine on a normal map and quietly wrecks a base colour map. A slice small enough to test is also small enough to be wrong in only one way.

Keep the build deterministic

The Blender side is headless and scripted. Same input, same output, no clicking. Before anything is written to disk, a validation step checks the triangle budget, the dimensions, and that the scale is a clean 1, 1, 1. A fluffed run just re-runs clean.

Determinism is what makes the test loop trustworthy. If the build wandered between runs, a passing test would prove nothing. Because it does not, green means green.

Two panels comparing builds. On top, a deterministic build: three runs all produce hash 9f2c and pass the budget check, with the note that a fluffed run just re-runs clean, and the verdict that red means the code changed and green means green. Below it, a build that wanders: three runs produce hashes 9f2c, 41ab and c07e while nothing in the code changed, and the verdict that green proves only that this run agreed with itself. A band underneath reads: a check is only worth what its inputs are worth, so make the build boring first.

Nothing ships done without evidence

The rule I hold hardest: the agent does not get to decide a task is finished. A passing check does. “It looks correct” is exactly what ships the regression. The build runs, the test passes, I see the output, and only then is the slice done.

The pre-flight report as four checks with their thresholds. Triangle budget of 300 to 1500 tris for props at LOD0. Scale drift, where the longest axis must land between 1 and 100000 unreal units and a 1 metre crate should read about 100. A naming contract requiring the SM underscore prefix so the folder contract between the two programs holds. Normal map compression set to TC_NORMALMAP, the flag the green-channel slice depends on. A line underneath reads: read only, it reports and never mutates, so the report is evidence rather than a repair that hides the fault.

The thresholds are written down, so the check has an answer it can be wrong about. A validator with no numbers in it is a comment.

That sounds strict for solo work. It is the reason I can lean on these tools instead of babysitting them.

What I learned

A capable agent with no feedback loop produces fast, confident, broken work. The same agent inside a loop of align, test, then verify produces tooling I trust in the pipeline.

The loop is also a ceiling. The agent is only ever as good as the check that grades it, so most of my effort goes into making the check sharp, not into prompting. Pointed at the agent’s own steering rather than its code, the same question is the skill decay probe entry.

This is where the tooling layer is heading. Unreal 5.8 shipped an experimental MCP server that lets an agent drive the editor directly. The teams that get value from that will be the ones whose checks are sharp enough to grade what the agent produces. That is the part I work on.

Code is at github.com/marko-builds. The plugin this post describes is public in BlenderBridge; the validator with those thresholds is validate.py and the flip is one line in importer.py.