Chapter 1: Ground Zero
When Things Go Wrong
When Things Go Wrong
Claude Code is powerful, but it's not perfect. Things will go wrong — wrong code, confusing errors, unexpected behavior. This section teaches you how to handle it like a pro.
This is normal. Even experienced developers deal with errors constantly. The skill isn't avoiding errors — it's knowing how to recover from them quickly.
Claude Code generated wrong code
This happens. Maybe the component doesn't look right, the logic is off, or it used an approach you didn't want. You have three options:
- Reject it — say "no" or press
nwhen Claude Code shows you the diff. Nothing gets written. - Give feedback — instead of accepting or rejecting, type what's wrong: "Use a dropdown instead of radio buttons" or "The sort is backwards, it should be newest first."
- Accept and iterate — accept the code, see how it works, then ask Claude Code to fix specific things: "The delete button is too small. Make it an icon button with a trash icon."
The #1 beginner mistake: approving every diff without reading it. Always review what Claude Code writes. You don't need to understand every line, but scan for things that look wrong — files in the wrong place, deleted code that shouldn't be deleted, approaches that don't match what you asked for.
Prevent wrong code before it happens
One powerful technique: give Claude an out. Instead of "Build the search feature," try:
"Build the search feature. If you're unsure about how to handle the filtering logic with our existing category system, explain your options and ask me before implementing."
This prevents Claude from guessing when it's uncertain. It tells Claude it's OK to pause and check with you rather than generating code that might be wrong.
This technique — called "giving Claude an out" — comes from Anthropic's prompt engineering research. When you explicitly tell Claude it's OK to say "I'm not sure," it produces more accurate results because it stops trying to fill gaps with guesses.
Common errors and how to fix them
"command not found: claude"
Your terminal can't find Claude Code. This usually means npm's global bin directory isn't in your PATH.
If it shows the package, your PATH needs fixing. Try running it with npx instead:
"EACCES: permission denied"
npm doesn't have permission to install globally. On macOS/Linux:
"Port 3000 is already in use"
Another process is using that port. Either kill it or use a different port:
Dev server errors
If the dev server crashes or shows errors, try the basics:
- Stop the server with
Ctrl+C - Ask Claude Code: "I got this error: [paste the error]. What's wrong?"
- Let Claude Code fix it
- Restart the dev server
Context window filling up
Claude Code has a limited context window — it can only hold so much conversation in memory. Signs it's filling up:
- Responses get shorter or less detailed
- Claude Code forgets decisions from earlier in the conversation
- It starts repeating itself or contradicting earlier choices
What to do:
This summarizes the conversation and frees up space. If things are really degraded, start a fresh session — your CLAUDE.md gives Claude Code all the project context it needs.
When to start fresh vs. keep going
| Situation | Action |
|---|---|
| Small fix or follow-up | Keep going |
| Switching to a different feature | Start fresh |
| Context seems degraded | /compact first, then fresh if it doesn't help |
| Something went badly wrong | Start fresh — clean slate |
| Long session (20+ back-and-forths) | /compact or start fresh |
The error-paste trick
When you hit an error you don't understand, paste it directly into Claude Code:
"I got this error:
[paste the full error message] What went wrong and how do I fix it?"
Wrapping the error in <error> tags helps Claude distinguish your instructions from the error text. Claude is specifically trained to recognize XML tags as boundaries between different types of content. This is called separating data from instructions — a core prompting technique.
Claude Code is excellent at diagnosing errors — it can read stack traces, identify the root cause, and fix the code. This alone makes it worth using.
Don't try to fix errors yourself by Googling first. Paste the error into Claude Code. It's faster and it learns your project context, so it gives better fixes than a generic Stack Overflow answer.
Try it: debug a real error
Let's practice the error-paste trick with a real bug. In your todo-app project, try this:
- Open Claude Code in your
todo-appfolder - Ask: "Add a console.log to page.tsx that logs
window.innerWidthat the top of the component function, outside any useEffect" - Accept the change and check your browser — you'll see an error about
window is not defined - Copy the full error from the terminal or browser
- Paste it into Claude Code: "I got this error:
[paste the error] What went wrong and how do I fix it?" - Claude Code will explain that
windowdoesn't exist during server-side rendering and fix it by wrapping it in auseEffector adding atypeof windowcheck
You just debugged a real Next.js error — one of the most common ones beginners hit. The pattern is always the same: encounter error, paste it into Claude Code, let it explain and fix. You'll use this workflow hundreds of times.