Verifying what the camera sees

I build Hollow Ward with Claude Code, and there is no bridge into the Unity editor. The assistant cannot click anything. Scenes, prefabs, materials and builds are produced by editor scripts that run headless, in batch mode, and the assistant works from their logs, test results and rendered images.

That constraint produced the most useful rule on the project: do not say something looks right unless you have checked it at the size it will be seen. Twice in phase one a result was called good from small contact-sheet thumbnails, and I saw at once that it was wrong.

Render it, then look closely

• Capture tests play the real room and save first-person shots, plus outside cameras for debugging.
• Prop sheets render each model from four angles with a blue marker on the +Z axis, where the front should face, and a red one on +X.
• A close-up at full size comes before any conclusion. Contact sheets are for finding problems, not for clearing them.

When it is ambiguous, measure

The orientation of the hands on the first-person rig was misread from renders three times. What settled it in one run was measuring the thickness of the flesh at the knuckles: 2.5 to 4.2 centimetres on the palm side and 1.7 to 2.2 on the back. A number cannot be wrongly eyeballed. The outline of the bedside drawer was read the same way, off an orthographic render with a five-centimetre grid.

Batch-mode traps

• Batch mode never has window focus, and the input system ignores keyboards without it, so tests that simulate a keyboard swap in temporary settings that ignore focus.
• An end-of-frame wait never fires in batch mode, so tests wait a frame instead.
• The first rendered frame can show a magenta material while a shader variant compiles. Later frames are fine.
• Only one thing may use the project at a time, so the editor has to be closed and the lock file checked before every run.

Owning what ships

The assistant writes a lot of this code and I read, run and question all of it. The project has around 166 automated tests and 17 separate assemblies, which exist so that every change has a place to be checked and a boundary it cannot cross. Using AI tools well is mostly about the same discipline as working with a fast junior colleague: clear boundaries, tests that can fail, and the habit of checking the evidence yourself.