Give the agent an outcome and a boundary
A useful task explains the behaviour to change, the constraints to preserve and the checks that will establish success. “Fix the interaction” leaves too much undefined. “Make this control release cleanly when tracking is lost, preserving normal press and scroll behaviour” gives both implementation and review a concrete target.
Keep the first change small enough to inspect as a whole. Separate investigation from mutation when ownership is unclear. An agent should be able to report that the assumed cause was wrong without feeling obliged to produce a patch anyway. Decide in advance which changes require another discussion, particularly public contracts and unrelated refactors.
Curate repository context
Repository instructions are useful for stable conventions: where production code lives, how to run checks, which assets are vendor-owned and which project patterns are authoritative. Task-specific context should add the relevant entry points, consumers and known failure, not a dump of every document.
This is a practical form of context engineering: deliberately selecting the information an agent sees. Keep instructions current and remove contradictory rules. More text is not automatically more control.
In Unity, context must include authored configuration. A field may be assigned through a prefab rather than a constructor. A change to a base prefab can affect variants and scene instances. Ask the agent to trace those relationships instead of assuming that a code search describes the whole application.
Make validation accessible without broad authority
Document a reproducible route to compilation, relevant tests and Editor inspection. An agent with no feedback loop is likely to stop at plausible code. When several Unity projects or worktrees are open, explicitly target the correct checkout and Editor before running automation.
Grant only the access needed for the work. Do not place credentials or client material into tools that are not approved for that project. Tool availability is not permission to publish, migrate data or modify unrelated repositories. A clear stop condition is as important as a clear success condition.
Review assumptions, not just syntax
My review starts with the proposed ownership. Did the change reuse a suitable Unity or package capability? Did it introduce another copy of state? Who cancels pending work and removes subscriptions? Does a scene reload leave generated objects or altered settings behind?
Then inspect assets and scope. Prefab overrides, serialized references and import changes can be more consequential than a short C# diff. Reject unexplained generated files and unrelated edits rather than treating them as harmless because compilation passed.
Automated or agent-assisted review can help identify issues, but it is not independent proof of correctness. GitHub's guidance on reviewing AI-generated code likewise places human review alongside automated checks. A second agent can repeat the first agent's assumptions.
Finish with evidence at the right level
Use checks that match the risk. Pure logic may be covered by focused automated tests. Scene lifecycle needs runtime checks. A spatial interaction or rendering change needs the target device; an Editor-only result is incomplete evidence for a headset feature.
- Confirm the intended diff and absence of unrelated changes.
- Compile and run the relevant automated checks.
- Exercise normal use, interruption, repeated activation and teardown.
- Inspect affected prefab instances and serialized references.
- Validate hardware-dependent behaviour on the actual target.
- Record what passed, what was not tested and what remains uncertain.
Keep a human-readable explanation of the final design. If I cannot explain why the change works and what could invalidate it, it is not ready simply because the agent reports success.
I assess this workflow through review effort, escaped regressions and completed behaviour, not generated line counts. Coding agents are most useful when they shorten implementation and investigation while leaving the codebase understandable to the next engineer.