Context Engineering for Unity: How to Make AI Useful on Real Projects A developer with 16 years of game development experience describes context engineering for Unity projects, emphasizing that AI coding tools fail when they lack project context. The developer, who shipped Eagle Flight Arcade at Ubisoft Montreal, argues that providing a project brief with file paths, versions, architecture, and constraints is more effective than refining prompts. AI coding tools are impressive in a clean demo and much less impressive inside a Unity project that has been shipping for years. The difference is usually not the prompt. It is the context surrounding the prompt. After 16 years in game development, I have learned that production work depends on assumptions scattered across scenes, prefabs, packages, build settings, naming conventions, and platform requirements. An AI assistant cannot respect information it cannot see. This article is not about adding a chatbot to an NPC or sending player text to a model. It is about context engineering: organizing a real Unity project so an AI assistant can make useful, reviewable changes without turning your repository into an experiment. Most AI coding failures I see are not failures of syntax. The generated C compiles, the class names look sensible, and the explanation sounds confident. The failure appears one level deeper. The code assumes the wrong input system, modifies a prefab that should be treated as a template, calls an API unavailable in the installed package version, or creates a second architecture beside the one already in production. These are context failures disguised as implementation failures. Unity makes this problem especially visible because the project is larger than its scripts. Important behavior can live in scenes, prefabs, ScriptableObjects, animation controllers, physics layers, tags, package manifests, quality settings, and platform-specific configuration. A model shown three C files may produce a reasonable answer for those files while remaining completely unaware that a serialized event in a prefab depends on the method it wants to rename. I learned to respect hidden dependencies long before modern coding assistants appeared. Eagle Flight Arcade, which I shipped as a Gameplay Programmer at Ubisoft Montreal in 2016, targeted PSVR, Oculus Rift, and HTC Vive. Even without discussing its internal architecture, that platform matrix illustrates the point. A change that appears local can interact with input, performance, comfort, hardware behavior, and build configuration. Production knowledge rarely fits inside one source file. My first question for an AI task is therefore not whether the model can write the code. I ask whether it has enough evidence to understand the job. If the answer is no, I improve the evidence before refining the prompt. I provide relevant file paths, Unity and package versions, architectural boundaries, expected behavior, and known risks. A shorter request with the right project map is more valuable than a clever paragraph full of motivational instructions. Context engineering begins by making the invisible parts of the project visible. A useful project brief should explain the repository the way I would explain it to a developer joining for a focused task. It does not need to document every class. It needs to identify the decisions that must not be reinvented. I usually begin with the Unity 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. The next layer describes architecture in plain language. Which system owns game state? How do scenes transition? Are services found through dependency injection, explicit references, static access, or another established pattern? Which ScriptableObjects are configuration assets, and which hold runtime state? Are asynchronous operations based on coroutines, tasks, or a project-specific abstraction? This is not an invitation for the AI to redesign those choices. It is a contract telling the assistant which choices already exist. I also document prohibited changes. An asset package, for example, should not silently add a new dependency, modify global project settings, or require customers to restructure their scenes. That matters to products such as Touch Camera PRO and Touch Camera LITE because reusable Asset Store code lives in projects I do not control. The safest implementation is usually the one with the smallest integration footprint. The project brief should state that requirement directly instead of expecting a model to infer it. Finally, I include a definition of done that can be observed. The code must compile without new warnings. Existing public APIs must remain compatible unless the task explicitly authorizes a breaking change. Edit Mode and Play Mode tests must pass. Any new serialized field needs a safe default and a migration plan if existing assets are affected. Files outside the approved scope should remain untouched. I keep this brief in the repository, review it like code, and update it when architecture changes. That gives humans and AI assistants the same baseline instead of allowing each conversation to invent a different version of the project. Broad requests encourage broad guesses. Asking an assistant to improve the camera system gives it permission to reinterpret input, smoothing, collision, framing, serialization, and public APIs at the same time. Asking it to add an optional maximum zoom constraint to one component, preserve existing defaults, update one test file, and avoid allocation in the per-frame path creates a task that can be reviewed. The second request is smaller, but it contains more useful engineering information. I divide work according to verification boundaries. A good task has one behavioral objective, a limited file set, known constraints, and a result I can test without finishing three other features first. Investigation is a separate task from implementation. I may first ask the assistant to trace where a value originates, list every serialized reference to a method, or compare two possible extension points. Only after validating that map do I request a patch. This prevents an uncertain analysis from being buried inside a large code change. I also ask for a plan before code when a task crosses systems. The plan should name the files to modify, explain why each file is involved, identify compatibility risks, and propose tests. I reject plans that introduce unnecessary managers, wrappers, service locators, or generic frameworks. AI assistants often solve ambiguity by creating abstractions. Mature projects frequently need the opposite: a narrow change that respects the abstractions already present. The final request should include stop conditions. If a required class is missing, a package API is uncertain, or a scene reference cannot be inspected, the assistant should report the uncertainty rather than fabricate an answer. This matters in 2026 because models are increasingly capable of completing a task-shaped conversation even when the repository evidence is incomplete. Fluency can hide uncertainty. Small task slices expose it. They also make commits easier to review, revert, benchmark, and assign. My preferred AI unit of work is not a feature. It is the smallest coherent change that can prove its own correctness. The Unity version is the first detail I make explicit. APIs, package compatibility, serialization behavior, and build tooling change over time. A model trained on years of Unity examples may combine an older tutorial, a newer package API, and a deprecated workflow into code that looks entirely plausible. I provide the exact editor version and relevant package versions, then require the assistant to flag any API it cannot verify against that environment. Scene and prefab ownership must also be clear. I do not let an assistant assume that editing a prefab instance is equivalent to editing its source, or that a scene object is always present at runtime. The task should state how references are assigned, whether objects are loaded additively, what survives scene transitions, and whether a prefab belongs to the project or an imported package. If the assistant cannot inspect serialized YAML safely, I provide a human-readable summary instead of pretending the script files tell the whole story. Execution order is another dangerous guessing area. Unity lifecycle methods, script execution settings, domain reload options, Enter Play Mode configuration, and asynchronous loading can all change when initialization occurs. An assistant may fix a null reference by adding a convenient lookup in Update , but that can replace a visible lifecycle bug with a permanent performance cost. I want the initialization contract explained and tested, not patched through repeated searching. Platform behavior belongs on the same list. Touch, mouse, controller, VR input, safe areas, file permissions, and graphics capabilities are not interchangeable. My experience with Eagle Flight Arcade reinforced how seriously platform constraints must be treated, while maintaining camera assets reinforces the variety of customer configurations a reusable package can encounter. I tell the model which platforms matter and which ones are outside scope. I also identify code that runs per frame, in physics steps, in editor callbacks, or during builds. These details determine whether an allocation, reflection call, asset lookup, or conditional compilation symbol is acceptable. When context is unavailable, the correct AI response is a question, not a confident guess. Generated code should enter the repository through the same evidence pipeline as human code. Compilation is only the first gate. I want tests that describe the intended behavior before I accept an implementation, especially when the assistant proposes a refactor. If a method is supposed to clamp zoom, preserve an old default, or reject invalid configuration, those expectations should be executable. Otherwise, the review becomes a debate about whether the code looks reasonable. Tests are also a compact form of context. A well-named test tells the assistant what the system promises, which edge cases matter, and what compatibility means. For Unity work, I separate pure C logic from engine-dependent behavior when practical. Pure calculations can often be covered quickly with Edit Mode tests. Frame timing, coroutines, scene loading, and component lifecycle behavior may require Play Mode tests. I do not force everything into an engine-free layer, but I avoid making simple rules impossible to test. I sometimes version a small task brief as a ScriptableObject so constraints and acceptance checks remain inspectable by the team. The following is intentionally simple. It creates a consistent summary that can be copied into an approved AI tool or exported by an editor utility: using System; using System.Text; using UnityEngine; CreateAssetMenu menuName = "AI/Task Context" public sealed class AiTaskContext : ScriptableObject { SerializeField private string objective; TextArea 3, 8 SerializeField private string constraints; SerializeField private string unityVersion; SerializeField private string packageVersions = Array.Empty