How to Debug and Review Code with Claude

Claude is useful for debugging when you give it the evidence: the error message, the relevant code, what you expected, and what happened instead. Without evidence, debugging turns into guessing — and guessing wastes both your time and Claude's context.

The debugging brief

Every debugging prompt should include four things: the error or symptom, the relevant code, what you expected, and what you have already tried. This structure stops Claude from suggesting things you already ruled out.

Bad

My API is returning 500 errors. Help.

Better

My Next.js API route at /api/users returns 500 on POST requests.
The error in the server log is: "Cannot read properties of undefined (reading 'email')".
Here is the route handler:
[PASTE CODE]

Best

Stack: Next.js 14 App Router, TypeScript, Prisma.
Endpoint: POST /api/users

Error: "Cannot read properties of undefined (reading 'email')"
This happens on every POST request, including valid payloads.
GET requests to the same route work fine.

Expected: Parse the request body and create a user record.
Actual: 500 error before reaching the Prisma call.

Already tried:
- Confirmed the request body is valid JSON with email field
- Checked that the Content-Type header is application/json
- Added console.log at the top of the handler — it fires, so the route is matched

Route handler code:
[PASTE CODE]

Request body I am sending:
[PASTE EXAMPLE REQUEST]

Diagnose the root cause. Explain why before suggesting a fix.

The best version gives Claude all the evidence and rules out common suggestions. 'Explain why before suggesting a fix' prevents a blind patch that hides the real issue.

Code review with Claude

You can ask Claude to review code for specific concerns rather than a vague 'review this.'

Review the code below for:
1. Security issues (injection, XSS, exposed secrets)
2. Error handling gaps (unhandled promise rejections, missing try/catch)
3. Performance concerns (N+1 queries, unnecessary re-renders)

For each issue found:
- Quote the specific line or block
- Explain the risk
- Suggest a fix

If no issues are found for a category, say so explicitly.

[PASTE CODE]

Narrowing down the root cause

If Claude's first suggestion does not fix the issue, do not just say 'that did not work.' Provide the new evidence.

Your suggestion was to add await to the body parsing call.
I made that change. The error is now different:
"PrismaClientKnownRequestError: Unique constraint violation on field email"

This means the body parsing is fixed, but now there is a duplicate entry issue.
Here is the updated code and the database state:
[PASTE UPDATED CODE AND RELEVANT DB STATE]

Review checklist for Claude-suggested fixes

• Does the fix address the root cause or just suppress the symptom?
• Does it introduce any new behavior that was not in the original spec?
• Have you verified the fix with the same reproduction steps?
• Does the fix need a corresponding test?

Common debugging mistakes

• Describing the symptom without pasting the actual error message
• Pasting 500 lines of code when only 20 lines are relevant
• Not mentioning what you already tried — Claude suggests the same thing
• Applying a fix without understanding why it works

Related reading: /blog/how-to-use-claude-for-coding for the basic coding brief and /blog/how-to-get-better-code-from-claude for writing specs that prevent bugs.