Debugging with AI
The debugging loop as a learnable protocol: read the actual error, locate the place, paste with context, apply one fix at a time — and the tools that show you what's really happening.
You've been debugging all course; this lesson turns instinct into protocol, because from here on (hardening, deploying, and life after the course) the bugs get less scripted. The loop that works:
- Read the error before pasting it. Errors name a file and a line more often than beginners believe; thirty seconds of actually reading routes half of them without help. The three-place question first, always: is this a browser error (red in the browser console), a server error (in the terminal running
npm run dev), or a database error (mentions SQL or a table)? Location is half of diagnosis. - Paste with context, not alone. The error + what you were doing + the relevant code + what you already tried. 'I clicked Send on the thread page and got this: [error]. Here's the route and the component: […]. It worked before I added the status update.' That last sentence — what changed — is the highest-value clue you own, and
git logremembers when you don't. - One fix at a time, then re-test. Assistants sometimes offer three possible fixes; applying all three teaches you nothing and occasionally trades one bug for two. Apply the most likely, test, iterate. And when a fix works, ask why — 'explain what was wrong in one paragraph' — because a bug understood is a bug category retired.
The two windows that show the truth
Beyond errors, two browser tools turn 'it's being weird' into evidence — both live in DevTools (F12, or Cmd-Option-I on a Mac): the Console (where frontend errors and your own console.log breadcrumbs appear — logging a value before and after a suspect line is the oldest debugging move and still the best) and the Network tab (every API call your app makes: the request, the payload, the status code, the response). The Network tab is the API-line arbiter: click Send, watch /api/replies — a red 400 with your validation message means the frontend sent something bad; a 200 with the row missing from the screen means a state bug. You built the app in three places; DevTools is how you watch the three places talk.
For the bug that survives three loop iterations, change modes: 'I'm going to describe this bug end to end; ask me clarifying questions before proposing anything.' Explaining forces ordering, the questions expose the assumption you didn't know you were making, and roughly a third of the time you'll solve it mid-description — the oldest phenomenon in programming, now with a duck that talks back.