How to Use Acceptance Criteria Before Letting AI Modify a Game Mechanic
Define the mechanic as observable examples before implementation: starting state, action, expected state transition, edge cases, and behaviors that must not change. The agent should implement against those criteria and run them again after the edit.
Define the mechanic as observable examples before implementation: starting state, action, expected state transition, edge cases, and behaviors that must not change. The agent should implement against those criteria and run them again after the edit.
Acceptance criteria convert intent into a contract
Vibe coding research consistently describes iterative generation and evaluation rather than reliable one-shot development. The strongest way to evaluate is to decide what success means before the model writes the patch.
Use examples, not slogans
“Make dash feel responsive” is a design goal. Acceptance criteria might include: dash begins within one frame of valid input, lasts 0.18 seconds, ignores repeated input until cooldown, preserves vertical velocity, and cannot trigger while stunned.
Include non-regression criteria
If changing dash, list movement behaviors that must remain unchanged. This prevents the agent from satisfying the new requirement by breaking an old one.
Keep taste-sensitive criteria separate
Numbers can create a baseline, but final feel still needs playtesting. Mark which criteria are hard pass/fail and which are human review so the agent does not pretend subjective design has been mathematically proven.
Working template
MECHANIC: [...] START STATE: [...] ACTION: [...] EXPECTED TRANSITION: [...] EDGE CASES: [...] MUST NOT CHANGE: [...] AUTOMATED PASS/FAIL: [...] HUMAN FEEL REVIEW: [...].
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.