When Things Go Wrong
Claude isn’t perfect. Here’s how to recognize problems and recover from them.
Code That Doesn’t Work
This happens. You’ll ask Claude to build something, it writes the code, and then you see an error message in the terminal or a blank screen in the browser.
Don’t panic. Claude is good at fixing its own mistakes — you just need to show it what went wrong.
Copy the error message and tell Claude exactly what you see:
I’m getting an error that says [paste the error here]
Or if there’s no error but something looks off:
The page is blank. It should be showing a list of projects.
Be specific about what you expected vs what actually happened. That’s all Claude needs to diagnose and fix it.
Changes to the Wrong Files
Sometimes Claude edits a file you didn’t want it to touch, or creates new files in the wrong place. This is why the approval step matters — read what Claude is about to do before you approve it.
If it already happened, be direct:
You edited the wrong file. Undo the changes to [file] and make the changes to [correct file] instead.
As you work with Claude more, you’ll develop a feel for which files it should be touching. If Claude is modifying something that sounds unrelated to what you asked for, pause and ask why before approving.
Lost Context in Long Sessions
After a long conversation, Claude may forget decisions you made earlier. The signs are obvious once you know what to look for: it re-asks questions you already answered, reverses design choices you agreed on, or undoes changes from earlier in the session.
Two fixes:
- Use
/compactto have Claude summarize the conversation and free up context space - Start a fresh session with a clear description of where you left off
This is exactly why your CLAUDE.md file matters. It preserves important decisions between sessions so Claude doesn’t have to remember them — it reads them every time.
Going in Circles on the Same Bug
Sometimes Claude tries the same fix repeatedly, or keeps breaking one thing while fixing another. You’ll feel it — the same files keep changing, the same error keeps coming back, and nothing is actually improving.
When this happens, stop. Don’t keep approving attempts. Instead, step back and reframe the problem from scratch:
Let’s step back. The issue is [X]. Here’s what should happen: [expected behavior]. Here’s what’s actually happening: [current behavior].
Give Claude a clean description without all the baggage of failed attempts. Sometimes starting a new session with this fresh problem statement works better than continuing a stuck one.
Using Git to Recover
Git is your safety net. When Claude makes changes that break things, these commands get you back to solid ground:
git status— shows you which files changed. Start here to understand what happened.git diff— shows the exact changes, line by line. Useful when you want to see what Claude actually did.git stash— temporarily hides all your changes. Everything goes back to how it was at your last commit. Rungit stash popto bring the changes back.git checkout -- [file]— undoes changes to one specific file, reverting it to the last commit.git reset --hard— undoes everything back to the last commit. This is the nuclear option. All uncommitted changes are gone.
The most important habit: commit often. Every time something works — even partially — commit it. That way you always have a known good state to return to. You can ask Claude to do this for you:
Commit what we have so far. Things are working.
For a deeper introduction to version control, see Git for Designers.
When to Start Fresh vs Continue
Not every stuck conversation is worth saving. Here’s how to decide:
Continue the session if:
- The problem is clear and Claude understands what’s wrong
- You’re making progress, just slowly
- The conversation is still relatively short
Start a fresh session if:
- Claude keeps going in circles on the same issue
- The conversation has gotten very long
- You’ve changed your mind about the approach entirely
Starting fresh isn’t failure. It’s efficient. A clean conversation with a well-written prompt often solves in minutes what a messy thread couldn’t solve in an hour.
Building a Critical Eye
You don’t need to read code. But you should develop instincts for catching problems early.
After Claude makes changes, test like a user:
- Does it do what you asked? Not what Claude described — what you actually see on screen.
- Does it look right? Spacing, alignment, colors, typography. Trust your designer’s eye here.
- Does it handle edge cases? What happens with no data? With a very long title? With a slow connection?
- Click everything. Every button, every link, every interactive element.
- Try weird inputs. Empty fields, special characters, extremely long text.
- Resize the window. Does it hold up on different screen sizes?
You already have a trained eye for quality. The only difference is you’re applying it to a working product instead of a static mockup. That’s an advantage — use it.