Brightory
Brightory / AI Game Creation
Vibe Coding · Recovery

How to Debug an AI-Built Game When Every Fix Creates Two New Bugs

Stop adding fixes. Return to the last known-good checkpoint, reproduce one bug, map the state it touches, and constrain the next patch to the smallest layer. If you cannot name a known-good checkpoint, create one before continuing feature work.

7 min read · Updated Sep 5, 2026
Game controller and keyboard used for development and testing.
AI Game Creation · field notes
Direct answer

Stop adding fixes. Return to the last known-good checkpoint, reproduce one bug, map the state it touches, and constrain the next patch to the smallest layer. If you cannot name a known-good checkpoint, create one before continuing feature work.

The error-expansion pattern is a process failure

Recent developer discussions repeatedly describe AI-created code becoming harder to reason about as fixes pile up. Research on vibe coding also finds debugging remains hybrid and trust must be earned through iterative verification. Once every fix creates regressions, the priority is to reduce uncertainty, not increase output.

Freeze feature work and build a failure ledger

List current bugs separately with reproduction steps and severity. Do not ask the agent to solve all of them. Choose the earliest or most foundational failure and ignore downstream symptoms until it is stable.

Rebuild a known-good chain

  1. Checkout or restore the last version that passed core tests.
  2. Reproduce one bug.
  3. Identify the minimum state and dependency path.
  4. Patch once.
  5. Run the target test plus neighbor regressions.
  6. Commit before touching the next bug.

If there is no known-good version, stop pretending the code is stable

Create characterization tests for the behavior you still want to preserve. Only after those tests exist should you refactor or recover the most tangled area. Otherwise the AI has no reliable definition of what “do not break anything else” means.

Working template

RECOVERY MODE
NO NEW FEATURES.
BUG LEDGER: [one bug per repro]
LAST KNOWN GOOD: [...]
TARGET BUG: [...]
PATCH LIMIT: [one layer/file set]
PASS: target test + neighbor regressions
COMMIT before next bug.

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.