Unity's AI problem is not the prompt: the load-bearing context lives in the prefabs

The reason Unity punishes assistants harder than a plain service codebase does is where the behaviour is kept. The article enumerates nine places outside the C# that can carry load: scenes, prefabs, ScriptableObjects, animation controllers, physics layers, tags, package manifests, quality settings and platform-specific configuration ^[5][16]. Against that, its worked example is a model handed three source files ^[6]. The rename it proposes compiles. It is unaware that a serialized event in a prefab depends on the method being renamed ^[6], and the compiler will not raise it.

The brief the author proposes is not documentation in the usual sense. It records the decisions that must not be reinvented: editor version, render pipeline, supported platforms, input solution, major packages, assembly layout, testing approach, and the directory boundaries between runtime code, editor code, samples and third-party dependencies ^[11]. A second layer names in plain language which system owns game state, how scenes transition, how services are located, which ScriptableObjects are configuration and which hold runtime state, and whether asynchronous work runs on coroutines, tasks or a project abstraction ^[12]. He is explicit that this is a contract stating which choices already exist, not an invitation for the assistant to redesign them ^[12]. There is also a prohibited list. An asset package must not silently add a dependency, modify global project settings, or require customers to restructure their scenes ^[13].

The sequencing is the useful part. When a task looks doubtful, the author improves the evidence before he improves the prompt: file paths, Unity and package versions, architectural boundaries, expected behaviour, known risks ^[9][10]. Tasks stay small enough to carry explicit acceptance checks ^[18], and automated tests are what turn a plausible suggestion into evidence ^[19].

What the piece does not carry is a measurement. There is no accept rate before and after, no review hours counted ^[14]. It is a practitioner argument built on sixteen years of game development ^[7], with Eagle Flight Arcade at Ubisoft Montreal in 2016 offered as the illustration: one title, three headsets, meaning a change that reads as local interacts with input, performance, comfort and build configuration ^[8][15].

Read against the brief's own framing, the interesting implication is that none of this apparatus is AI-specific. The author says the brief should explain the repository the way he would explain it to a developer joining for a focused task ^[11]. Version pins, scene ownership, serialization rules and a written boundary between runtime and editor code are what you hand a contractor with two days. A team that cannot produce that document has a repository problem, and the assistant is only the first reader honest enough to fail loudly on it.