Backing out

Sometimes you accept a change and immediately regret it. That’s not failure — that’s normal. The skill is knowing your way back before you press accept, not after.

Before you accept a change you’re unsure about, know how you’d undo it.

This is one of those habits that feels paranoid until the day it isn’t. Then it’s the only habit you trust.

Three undo routes, smallest to biggest

1. Ask Claude to revert.

For small, recent edits, the fastest move is to say so:

undo the last change

or

revert what you just did in src/auth.ts

Claude reads the conversation, knows what it changed, and proposes the inverse. Quick. Conversational. Works best when the change is fresh and small.

2. Use your editor’s undo history.

Your editor (VS Code, Cursor, whatever) tracks every save. Cmd + Z (Mac) or Ctrl + Z (Windows/Linux) still works after a Claude edit — the change went through the editor’s file-change pipeline like any other edit. You can step backward through saves.

This catches the case where you’ve moved on to other prompts and “the last change” has become ambiguous.

3. git restore.

For files tracked in git, git restore <file> brings the file back to its last committed state — wiping out every change since, Claude’s or yours. This is the nuclear option. It’s fast, it’s surgical, and it works no matter how many turns ago the change was made.

Full git workflow is its own level (Level 8 — Git the Claude way). For now, two commands are enough:

• git status — see which files have changed since the last commit.
• git restore <file> — throw out the changes in that file. Use carefully.

Picking the right route

The trade-off, roughly:

You don’t have to memorize this. Just notice the pattern: the smaller and more recent, the cheaper the undo. The bigger and older, the more you’ll lean on git.

The discipline that saves you

There’s one habit that turns “back out” from a panic into a one-liner: commit your work before big changes.

When Claude is about to do something with real blast radius — a cross-file rename, a refactor, anything touching more than a few files — make sure your current state is committed first. Then if the change goes wrong, git restore . undoes everything Claude did and leaves your prior work intact.

You’ll see this advice again in Level 6 (where it’s about safety) and Level 8 (where it’s about the full git workflow). It earns the repetition.

What’s next

You know how to back out. The closing skill in this level is the inverse: knowing when not to keep iterating, when not to back out, when to recognize that the change is done and walk away.