Run build, send screenshot, describe chaos
I had never used the Godot editor before this project. During one late-night stress test, the model stopped behaving like an autocomplete tool and began acting like a debugging partner: proposing triage paths, tracing likely causes, building small debug instruments, and organizing the fix loop.
The triage ladder
- Reproduce: write the shortest sequence that causes the bug.
- Observe: collect screenshot, console output, scene name, character state, and expected behavior.
- Classify: camera, collision, spawn, state machine, navigation, asset, or timing.
- Instrument: add temporary labels, collision shapes, coordinates, state names, and event logs.
- Form one hypothesis: name the likely cause and what evidence would disprove it.
- Make the smallest change: avoid refactoring while the cause is uncertain.
- Retest the original path and a nearby path.
Examples from the project
Camera occlusion needed visibility into collision layers and camera targets. Characters spawning inside walls needed spawn-point visualization and a clearance check. Encounter softlocks needed state-transition logs and a way to reset the encounter without restarting the entire game.
Give the model artifacts
“It is broken” invites guessing. A useful report includes the expected result, actual result, exact steps, screenshot, relevant log lines, scene path, recent changes, and what you already tried. AI initiative grows when the environment makes cause and effect visible.
Do not confuse speed with certainty
The model can propose a convincing wrong cause. Keep changes small, preserve a working commit, run the game yourself, and require evidence that the original bug and likely regression paths both pass.
Software, links, and setup
- Godot Engine
- Godot debugging tools
- Git for safe checkpoints.
- Codex or another workspace-aware coding agent.
Prompt pack
Bug report
Help diagnose this Godot bug. Expected: [result]. Actual: [result]. Reproduction: [steps]. Scene: [path]. Recent changes: [list]. Evidence: [logs and screenshot description]. First classify the failure, then give at most three hypotheses ranked by evidence. For the top hypothesis, specify one observation that would confirm it and one that would disprove it. Do not edit yet.
Instrumentation task
Add the smallest temporary debug surface that exposes [camera target / collision layer / spawn position / encounter state]. It must be easy to remove, must not change game logic, and must produce a screenshot or log that distinguishes the leading hypotheses.
Fix and regression proof
Implement the smallest validated fix. Re-run the original reproduction steps and these nearby paths: [list]. Provide changed files, test evidence, remaining uncertainty, and instructions for removing temporary instrumentation.
What to remember
- Make the failure reproducible before changing code.
- Instrument invisible state.
- Ask for hypotheses and disconfirming evidence.
- Keep the fix small and retest neighboring behavior.
Then test it, document it, and make the next version easier for someone else to reproduce.