2.6 — Debugging With AI
Things will break. That’s not failure — that’s building. The skill is diagnosing and fixing efficiently, not avoiding breakage entirely.
The Five-Step Framework
Section titled “The Five-Step Framework”Step 1: Read the Error Message
Section titled “Step 1: Read the Error Message”Seriously — read the whole thing. Error messages usually say exactly what went wrong, and often which file and line number. Most beginners panic at red text. Treat it as diagnostic information, not punishment.
The error message is the system telling you what it knows. Read it before anything else.
Step 2: Reproduce the Problem
Section titled “Step 2: Reproduce the Problem”Can you make it happen again? What steps trigger it? If you can’t reproduce it, you can’t verify a fix. Flaky problems that come and go are harder — but the first step is still finding the reliable reproduction case.
Step 3: Isolate the Cause
Section titled “Step 3: Isolate the Cause”What changed since it last worked? Check your recent changes. Often the bug is in the last thing you touched. Git helps here — compare the current state to your last working commit using git diff.
This is where Separation of Concerns pays off: if each piece does one thing, you know which piece to inspect.
Step 4: Ask AI With Full Context
Section titled “Step 4: Ask AI With Full Context”Copy the entire error message. Describe what you expected vs. what happened. Include the relevant code. The more context the AI has, the better the diagnosis.
Specifically, include:
- The full stack trace
- The code that produced the error
- What you were trying to do
- What you already tried
Partial information produces partial answers. Give the AI everything.
Step 5: Verify the Fix
Section titled “Step 5: Verify the Fix”Don’t just apply what AI suggests and move on. Test it. Make sure the original problem is gone AND nothing new broke — a fix that introduces a new problem is called a regression.
The edge cases are where regressions hide: the weird input, the empty state, the user who does something unexpected. Test those too.
Debugging Vocabulary
Section titled “Debugging Vocabulary”| Term | Definition |
|---|---|
| Error message | Text the system produces when something fails — contains diagnostic information |
| Stack trace | A list showing the chain of function calls that led to the error — read bottom to top |
| Log | Messages a program writes to record what it’s doing — your forensic trail |
| Console | Where log messages and errors appear (browser console, terminal output) |
| Regression | A fix that breaks something that was previously working |
| Edge case | An unusual or extreme input that exposes bugs normal inputs don’t |
Reading a Stack Trace
Section titled “Reading a Stack Trace”Stack traces look intimidating but have a simple structure: they show you the chain of function calls that led to the crash, from most recent (top) to the original trigger (bottom). Read bottom to top to find where the problem started. Look for lines in your code, not framework internals — those are usually where the actual fix lives.
Next: 2.7 — Reading Documentation | Phase overview: Phase 2