How to Lock Working Game Systems Before Asking an AI Agent to Add a New Feature
Create a protected-systems manifest with behavior contracts, tests, and a write-scope list. Tell the agent it may inspect protected code but cannot modify it unless it first proves the new feature cannot be implemented at the intended boundary.
Create a protected-systems manifest with behavior contracts, tests, and a write-scope list. Tell the agent it may inspect protected code but cannot modify it unless it first proves the new feature cannot be implemented at the intended boundary.
A lock is behavioral, not only file-based
You may need an agent to read a working movement controller while building stamina. Mark movement as protected by behavior: speed, jump arc, input mapping, public methods, and tests. That prevents a “small helper” change from quietly altering feel.
Use read-many, write-few
Agents need context to integrate features, but context should not imply permission. Give broad read access to understand dependencies and narrow write access for implementation.
Require an exception request
If the agent believes a protected system must change, its next response should stop and explain the exact dependency, the minimal proposed interface change, and the regression tests it will run. Human approval turns hidden coupling into an explicit decision.
Keep the manifest in the repository
Do not rely on chat memory. A short `PROJECT-CONTRACTS.md` or similar file can list protected interfaces, tests, and system ownership so the rule persists across agents and sessions.
Working template
PROTECTED SYSTEM: [...] BEHAVIOR CONTRACT: [...] PUBLIC INTERFACE: [...] REGRESSION TEST: [...] NEW FEATURE WRITE SCOPE: [...] RULE: protected code is read-only unless an exception request is approved.
Source and verification note
This guide was checked against Microsoft Research: Vibe coding and Microsoft Research: Good Vibrations? and Vibe Coding in Software Development: Multivocal Review and updated Sep 5, 2026. The research describes patterns and risks rather than guaranteeing outcomes for every project; validate the workflow in your own codebase.