AI Debugging Workflow
The order that actually finds bugs instead of guessing at them — so you end with a verified fix, not a plausible one that quietly returns next week.
The problem
Pasting an error message and asking an AI to fix it usually produces a confident guess that treats the symptom. Real debugging has an order to it. You reproduce the failure so you can tell when it's actually gone. You trace it back to the real cause instead of the first suspicious line. You make sure you understand the code you're about to change. And you fix it behind a test, so the same bug can't quietly return three commits later. This workflow runs those steps with the coding tools you already have.
Recommended workflow
Each step uses an existing NewPrompt tool, pre-filled by a matching resource. Open the resource to read it, or jump straight into the tool with the inputs ready.
-
Reproduce the failure first
Before any fixing, get a reliable repro — the smallest sequence that triggers the bug every time. A reproduction is what tells you later whether the fix actually worked, and it stops the AI from theorizing about a problem it can't see.
Goal A consistent, minimal reproduction you can re-run after the fix.
Open this step in Debugging Prompt Generator -
Trace it to a root cause
Give the AI the stack trace, the repro, and the surrounding code, and push it past the first plausible line to the cause underneath. You're after the why, not the where.
Goal A specific root cause backed by evidence, not a symptom-level guess.
Open this step in Debugging Prompt GeneratorResource Root Cause Analysis Prompt -
Understand the code you're about to change
If the faulty code isn't obvious, get a plain explanation of what it really does before you touch it. A good share of bad fixes come from changing code the author misread.
Goal Enough understanding to fix the cause without breaking a neighbor.
Open this step in Code Explanation Prompt -
Fix it behind a failing test
Write the test that fails because of the bug, then change code until it passes. Now the fix is provable, and the bug can't slip back in unnoticed later.
Goal A regression test that fails before the fix and passes after.
Open this step in Test Case Prompt Generator -
Tidy the fix if it left a scar
Quick fixes often leave an awkward conditional or a duplicated branch behind. If yours did, clean just that one spot — no broader rewrite in the middle of a bugfix.
Goal A fix that reads as if it were always meant to be there.
Open this step in Refactor Prompt Builder
Expected outcome
The bug is reproduced, traced to its real cause, fixed, and locked behind a test that fails without the fix. You're left with a change you can defend in review — not a guess that happened to make the error message disappear.
Best for
- Bugs where the obvious fix didn't hold
- Intermittent or hard-to-reproduce failures
- Code you didn't write and don't fully trust yet
Not for
- A typo or one-line fix you can already see
- A live production outage where triage comes first — use the AI Production Incident Workflow
FAQ
How is this different from a debugging prompt?
A debugging prompt analyzes one error in isolation. This workflow is the sequence around it — reproduce, find the root cause, understand the code, then fix behind a test — so you land on the real problem instead of the first plausible one.
When should I use the Production Incident Workflow instead?
Use that one when something is broken in production right now and the first job is to stop the bleeding and communicate. This workflow is for fixing a bug properly once you have the time to do it right.
Do I need every step?
Steps 1, 2, and 4 are the backbone. Step 3 only matters when the code is unfamiliar, and step 5 only when the fix left the code messier than it found it.