Why Does AI-Written Unity Code Compile and Still Break in Play Mode?

The October 16 devlog lists three invented names as its example: GameObject.FindByTag, Rigidbody.AddVelocity, and transform.GetChildByName. The devlog states plainly that they do not exist, and its fix is a rule rather than a code patch: tell the agent to use only documented APIs, and to say it is not sure instead of guessing. This failure is annoying rather than dangerous, because it breaks the build where you can see it. The danger is the workflow around it: if you accept AI output without compiling, an invented name can sit in a file you believe is finished, and if you paste a fix from the same assistant without checking the docs, you can trade one invented name for another.

The silent failures work the other way: they compile, and the game runs until the exact wrong moment. The first is fake null. Unity documentation for UnityEngine.Object explains that an instance whose native counterpart was destroyed before the managed object was garbage collected can sit in a detached state. In that state the object still compares equal to null through Unity custom equality operators, yet it is not truly null: Object.ReferenceEquals against null returns false, and the object cannot be used to call methods or access properties. The same docs page states that the null-conditional operator and the null-coalescing operator are not supported with Unity objects, because they cannot be overridden to treat detached objects the same as null, and are only safe when the checked objects are guaranteed never to be detached.

The October 25 devlog gives the rename example in full. The AI is asked to clean up a script and renames a serialized speed field to moveSpeed. Unity stores inspector values by field name, so the devlog says every prefab and scene that had speed tuned to 7.5 quietly goes back to the default of

5. Nothing errors, and the developer finds out days later, when the game feels off. Treat the 7.5-to-5 numbers as the author example, not as a Unity documentation claim: the documented part is the mechanism and the fix. The FormerlySerializedAsAttribute documentation states its purpose in one line: use this attribute to rename a field without losing its serialized value. It is an editor-only attribute, it takes the old field name, and the docs example renames hitpoints to health while keeping the value. Public variables serialize by default, and private variables need the SerializeField attribute.

The devlog also names the third silent pattern in the same post, subscribing to events without unsubscribing, but this article keeps its scope to the three checks in the title and leaves that pattern for another day. The shared lesson across all three is about review order. Compile errors are reviewed by the compiler for free. Silent bugs are reviewed only if you look for them, so the checklist below is ordered by silence: fake null first, renames second, invented names third, because the third one at least shouts.

None of the steps below are presented as the devlog author fix for a shipped game, because no shipped game is named. They are the review rules that follow from the documentation and the devlog examples, written so they can be applied to your own project on Monday morning without touching anyone else code.