First, the calming fact
Your project is a folder of text files on your own computer. It cannot be broken forever. There is no state it can get into that can't be fixed, rebuilt, or — worst case — redone in an afternoon with the skills you now have. Professional developers break things daily; they've just stopped finding it scary. Today you stop too. Four moves, in the order you should reach for them.
Move 1 — paste the error, ask why
Something fails and produces an angry red wall of text. Do not read it like prose, and do not panic at words like "fatal." Copy the whole thing, paste it to Claude Code, and ask:
I got this error: [paste the whole thing]. Explain what went wrong in plain English first, then fix it.
The "explain first" half matters. You'll understand more than you expect, you build a mental map over time, and you can catch it when the diagnosis sounds off. Error messages are written for machines to parse — which is exactly why the machine is better at reading them than you are. Pasting an error isn't cheating. It's the workflow.
If the page just looks broken with no error to paste — blank screen, missing section, chaos where the layout used to be — describe the symptom instead: "The page loads but everything below the pricing section is gone." Symptoms are evidence too.
Move 2 — make it explain itself
Sometimes nothing's technically broken; you've just lost the plot on what's in your own project. Fix that directly:
Walk me through what's in this folder and what each file does, in plain English, like I'm not a programmer. Then tell me which part controls the contact section — that's the part I want to change.
Understanding-on-demand is one of the genuinely new things about this era. The builder is also the documentation. Ask it anything about its own work, any time, as many times as you want.
Move 3 — the undo button (this is git, and you need 10% of it)
Git is a tool programmers use to save snapshots of a project. It has a fearsome reputation and roughly four hundred commands. You need two sentences of it, spoken in English:
After anything works, tell Claude Code:
This is working — set up git if you haven't already and commit everything with a sensible message.
When an experiment goes sideways and you want out:
This isn't working. Take everything back to the last commit.
That's it. That's the video-game save system, operated in English:
Make the save-point prompt a reflex — after the headline works, commit; after pricing works, commit. Cheap insurance, and it turns "I broke it" from a crisis into a shrug.
Move 4 — the fresh start
Occasionally a session goes muddy: you've corrected it five times, changes contradict each other, and it seems increasingly confused about what you want. The conversation itself has become the problem — too much tangled history.
Exit (/exit), run claude again, and open with a clean summary:
Look at the project in this folder to see where things stand. The pricing cards are the part that's broken — they should be three side-by-side cards but they're stacking weirdly and overlapping the section below. Fix just that.
Your files survive across sessions; only the muddled conversation is gone. A fresh session with a clear brief regularly one-shots a problem the old session had been circling for twenty minutes. Knowing when to fold the conversation is a skill; folding early is usually right.
The escalation ladder
Top to bottom, that ladder gets you out of essentially everything a one-page project can throw at you.
You can now…
- Read an error by pasting it, not panicking
- Make the agent explain its own work
- Save and load progress with git, in plain English
- Know when to fold a session and start fresh