How I Stopped My AI From Guessing Fixes

Table of contents

• The session that made me change things
• What I built after that
• Rules that got added because things went wrong
• The command, if you want to try it

Recently I was debugging a redirect issue. After successful authentication, users ended up on the wrong page. I described the symptom to Cursor, and within seconds it had a theory and a code change ready. The fix didn't work, so it tried another one. Then another. It never stopped to ask "do I actually understand what's going on?"

The worst one was a component rewrite. A delete action on a UI element wasn't working. The AI tried a fix. Didn't work. Tried another approach. That one broke the layout. A third attempt introduced a type error somewhere else entirely.

After several rounds of this, I typed: "You keep guessing and nothing gets fixed."

So we stopped writing code and added console.log statements instead. The logs showed the problem in about ten seconds: an event handler was only being called on blur, but the user interaction that triggered the delete didn't cause blur to fire. The AI had been guessing for six messages. One round of logs solved it.

That session taught me something obvious in hindsight: the AI is good at generating code, but it has no instinct to stop and investigate. If you don't force it, it will keep throwing fixes at the wall. Later in that same session I needed to vent and it got philosophical. I told it: "Writing less code is better than writing more code. You're throwing random fixes at the wall and trying to see what sticks. Be systematic."

I wrote a /debug command — a prompt that runs at the start of any debugging session. The key constraint: no fix code allowed. The AI can read files and add logs.

It breaks down like this:

This command is for DIAGNOSIS ONLY.
Do NOT write any fix code. Only logs and reading are allowed.

Phase 1: Understand what changed
- Run git log and git diff on the relevant files

Phase 2: Trace the code path from the diff
- List the files and functions involved
- Read the actual logic

Phase 3: Add console.log at each step
- User reproduces and shares output

Phase 4: Write a structured diagnosis
- Symptom | Expected | Root cause | Confidence | Evidence

It's not clever. It just removes the AI's ability to do the thing it does too eagerly — jump to code.

The command started bare. Each rule in it now traces back to a specific session where that rule didn't exist yet.

Keep logs until the fix is verified. During one session, the AI found the root cause, wrote the fix, and removed all the debug logs in the same change. My response: "Why did you remove the logs? We don't know if your fix works." The fix happened to be correct that time, but the logs were the only way to know. Now the command says: do not remove instrumentation until the issue is fully resolved.

After a failed fix, add more logs — don't try another fix. The AI's default is to try a different approach when something fails. The better move is to add more logging and look at what's actually happening. Evidence first, code second.

State confidence before acting. Before any proposed change, the AI has to say whether it's HIGH, MEDIUM, or LOW confidence and why. LOW means stop and ask questions instead of writing code. This one came from a session where the AI assumed an API endpoint used PATCH with a JSON body. It was actually DELETE with no body. A confidence check would have surfaced the uncertainty before any code was written.

The command doesn't always get followed. Sometimes the AI quietly shifts from adding logs to writing code without being asked. And sometimes I'm the one who breaks it — mid-diagnosis I'll say "just try your fix" because I'm impatient. Debugging with AI requires discipline from both sides. The prompt constrains the AI, but you have to constrain yourself too.

The AI also doesn't remember anything across sessions. If we figured out last week that a library renders elements lazily, that knowledge is gone next week. Each insight has to be written into the command or the project rules, because it can't live in memory.

That's the whole system. Something goes wrong, you figure out why, and you add a line to the prompt so it doesn't happen again.

Here's a simplified version of what it looks like today:

This command is for DIAGNOSIS ONLY.
Do NOT write any fix code. Only logs and reading are allowed.

Phase 1: Understand what changed
- Run git log and git diff on the relevant files
- Do NOT proceed until you have either a diff or confirmation there is no known change

Phase 2: Identify the code path FROM the diff
- List the files, components, and functions involved
- Read the actual logic — do not skim

Phase 3: Add console.log at each traced step
- User reproduces and shares output

Phase 4: Structured diagnosis
- Symptom | Expected | Root cause | Confidence (HIGH/MED/LOW) | Evidence

Rules:
- Do NOT remove logs until the issue is fully fixed
- After a failed fix, add more logs before trying again
- LOW confidence → ask, don't guess
- No back-to-back code changes without new evidence

Save it as a text file, reference it when debugging starts. Add your own rules when something goes wrong. That's all there is to it.