How to Set Up Unity With AI Coding Agents and the CLI

Give the agent three things: the project's scripts to edit, a way to compile and run tests from the command line using Unity's batch mode, and optionally an MCP server that bridges into the open editor for scene and asset operations. Then index Unity's conventions and your project's architecture so the agent writes code that fits.

Why Unity is harder for agents than a web app

A coding agent works by reading files, changing them, and checking results. In a web project the check is a test command or a dev server. In Unity, most of the truth lives in the editor: compile errors in the console, component wiring in the Inspector, and behaviour that only shows up in play mode.

An agent that can only edit C# files is working blind. It writes scripts that look right, then you discover in the editor that a serialized field name changed and broke every prefab using it. The setup below closes that gap.

Step 1: a command-line feedback loop

Unity can run without the editor window using batch mode. The pattern is to invoke the Unity executable with flags for batch mode, the project path, and a log file, then either run tests or call a static method you control.

  • Compile check. Run a batch-mode invocation that opens the project and quits. Compile errors land in the log, and the agent can read them.
  • Tests. Use the test runner's command-line options to run edit mode and play mode tests and write results to a file. Now the agent has a pass or fail signal.
  • Custom build steps. Expose a static method for anything else the agent needs, such as validating scenes or checking asset references, and call it from batch mode.

Wrap these in a small script with a short name, and put it in your instruction file. The agent should run it after every meaningful change.

Step 2: an editor bridge through MCP

Several community MCP servers connect a running Unity editor to an agent. They typically expose tools for reading the console, listing scene objects, inspecting or changing components, and creating assets.

This is useful because scene and prefab files are serialized data that is easy to corrupt by hand. Letting the agent act through editor operations keeps references intact.

Treat the bridge as a privileged integration. It can change your project in ways a code review will not show. Use version control, commit before agent sessions, and start with read-only tools until you trust the setup.

Step 3: give it Unity context and your context

Models have seen plenty of Unity code, much of it from old tutorials. Without guidance the agent reaches for patterns your project does not use: a different input system, a singleton where you use dependency injection, or Find calls in hot paths.

Keep a short instruction file with the Unity version, render pipeline, input system, and the commands from step 1. Then index the heavier material: your architecture notes, coding conventions, package documentation, and the codebase itself. The agent searches that index before writing, and retrieves the relevant chunks instead of guessing from training data.

A first session, end to end

A good first task is a small gameplay script with a test. Describe the behaviour, for example a component that tracks a cooldown and exposes whether an ability is ready. Ask the agent to write an edit mode test first, then the component, then run the batch-mode test script and report the result.

Watch three things. Does it follow your instruction file on the input system and namespaces? Does it run the compile and test commands without being reminded? Does it read the log when something fails, or guess?

If the answers are good, widen the scope gradually: a refactor across several scripts, then editor tooling, then bridge operations on a test scene. If the agent keeps reaching for patterns your project does not use, that is a context gap, not a model gap. Add the convention to the index and ask it to search before writing.

What to let the agent do

  • Good fits. Gameplay scripts with tests, editor tooling, refactors across many scripts, data validation, build automation, and explaining unfamiliar code.
  • Keep a human on. Scene composition, visual tuning, performance profiling on target hardware, and anything that needs you to look at the game running.
  • Avoid. Hand-editing scene or prefab files through text. Use the editor or a bridge operation instead.

Frequently asked questions

Can an AI agent use the Unity editor directly?
Not by itself. A coding agent reads and writes files and runs commands. To act inside the editor it needs a bridge, typically an MCP server running alongside the open editor that exposes tools for the console, scene hierarchy, components, and assets. Without a bridge, rely on batch-mode compile and test runs for feedback.
How does the agent know if its Unity code compiles?
Run Unity in batch mode against the project with a log file, and have the agent read the log for compile errors. Wrap the invocation in a short script so the agent runs the same command every time. Add the test runner's command-line options to get pass or fail results for edit mode and play mode tests.
Is it safe to let an agent edit scenes and prefabs?
Only through editor operations, and only with version control. Scene and prefab files are serialized data with internal references, so text edits can break things silently. An editor bridge keeps references intact. Commit before each session, review the changes in your version control tool, and start with read-only tools.