The two halves of a Unity project
A Unity project has a code half and an editor half. The code half is C# scripts, assembly definitions, packages and tests. It behaves like any software project: text files, diffs and reviews work as expected.
The editor half is scenes, prefabs, ScriptableObjects and project settings. These are serialized files with object references by identifier. They are technically text, but they are not meant to be written by hand. A small mistake produces missing references that only surface when someone opens the scene.
Any approach to AI Unity development has to treat these halves differently. Code can be edited directly and reviewed as a diff. Editor state should be changed through Unity's own serialization and undo APIs, from inside the editor.
How agents can work on Unity code
For C# work an agent needs context and a boundary. Context means knowing the editor version, the render pipeline, the installed packages, the scene list and where tests live. The boundary is a branch, a set of allowed tools and a definition of done.
With those in place, typical tasks are well within reach: implement a gameplay system against stated acceptance criteria, fix a bug with a regression test, refactor a manager class, or add edit-mode tests for logic that does not need a running scene.
The limit is verification. Without a Unity editor on the machine doing the work, the agent cannot compile the project or run the Unity Test Framework. Its output is a reviewed diff that your own CI or a developer still has to build.
Scene and prefab changes need the editor
The safe route for scene work is an editor-side bridge: a small server inside the Unity editor that exposes specific operations such as reading the hierarchy, setting a serialized property, adding a component, instantiating a prefab and saving the scene. Each write goes through the editor's serialization and undo system, and paths are restricted to the project's asset folders.
This also gives a clean permission model. Read operations and write operations are separate tools with declared risk levels, so an administrator can grant inspection without granting modification.
Running this requires an engine worker: a machine with the exact editor version the project declares and a valid license. That is a real cost in setup and start-up time, and it is the reason in-editor automation arrives later than code automation.
Where PWR stands on Unity
PWR discovers Unity projects from their project files. It records the editor version, packages, render pipeline, the build scene list, asset counts and test assemblies, and suggests validation settings. Serialized files are read, never rewritten.
Agents can change C# source through the standard PWR workflow: a task branch, a pull request with evidence, an independent review and a human approval. PWR does not compile or test that code in Unity.
The Unity bridge package and its protocol are written, and the PWR side is tested against a simulated bridge. The package itself has never been compiled in a Unity editor. Scene edits, test runs, player builds and screenshots through Unity are therefore upcoming, not available.
- Today: discovery, validation profile, C# changes as reviewed pull requests, design review and planning
- Upcoming: editor bridge, Unity test runs, player builds, in-editor capture