Seeing and undoing what Claude changed

There is one moment in the whole experience that decides whether working this way feels sane or reckless, and it is smaller than people expect. Claude finishes thinking, proposes an edit, and hands it to you. What happens in the next few seconds — whether you read it or wave it through — is the entire difference between supervising a capable assistant and hoping for the best. Claude proposes; you dispose. Everything on this page is about making that seam easy to stand at.

What you actually see is a visual diff: the file as it was and the file as Claude wants it to be, laid out together, with removed text marked one way and added text another. If you have never read one before, the trick is that you are not proofreading character by character. You are checking three things, quickly. Is this touching the files you expected it to touch? Does the shape of the change match what you asked for? And is there anything in here you didn’t ask for at all — a “helpful” extra, a renamed thing, a deleted block you didn’t mention? That third question catches most of what goes wrong, and it takes about as long as skimming an email.

Crucially, accepting is not all-or-nothing. Each proposed change carries its own accept and reject, so the normal outcome of a review is mixed: you take the three edits that are right, turn down the one that isn’t, and say what you actually wanted instead. Rejecting is cheap — nothing was written, nothing has to be unwound, and Claude has just learned something concrete about the target. People new to this tend to accept a flawed change and then ask for a correction on top, which leaves both the mistake and the fix sitting in the conversation. Rejecting and re-asking is almost always the shorter path.

It is worth being precise about what “before it’s saved” means, because the word saved is doing real work. Until you accept, the proposed version exists only as a proposal — the file on your disk is untouched. Accepting is the act that writes it. That is why the review pane is the cheapest checkpoint in the whole system: everything downstream of it, every undo and rewind, is recovery from a decision you already made, whereas rejecting is just… not making it. The habit that pays off is spending your attention here rather than saving it for later.

Which brings us to the second net, for the changes that get through. Every time Claude edits your files it quietly records where things stood just before — a checkpoint — with nothing for you to configure. When a change turns out to be wrong two steps after you accepted it, you say so in plain language (“that broke the layout, rewind to before it”) and the files snap back to the last good moment. The part people find surprising is that rewinding restores your files without discarding the conversation. You keep everything you and Claude have worked out; you only undo the edits. That is what makes it reasonable to experiment boldly on something hard — the way back doesn’t cost you the context you built up getting there.

So there are really three layers of undo, doing three different jobs, and knowing which one you want saves a lot of flailing. Reject is for a change that hasn’t happened yet — free, instant, no trace. Undo and rewind are session-level: fast, in-the-moment recovery for a change you accepted and regretted, good for “try it and see” work. And git is the durable, shareable layer — the one that survives closing the app, that a colleague can read, that lets you record a change once it’s genuinely good. Checkpoints and git are not competitors; use both, for what each is for.

Two kinds of “done”

Reviewing each edit keeps individual changes honest. There’s a second check worth running before you call the whole thing finished, because build sessions drift and the drift is easy to miss from inside.

There’s shipped done: it works, you can read it, you can say in one sentence why this change exists, and the diff is no bigger than the task required. And there’s stuck done: it works — technically — the diff is twice the size you expected, there’s a piece you can’t quite explain, and you’re going to keep it anyway because you don’t want to start over. Stuck done is how a ten-line fix becomes a two-hundred-line surprise next month.

Three questions separate them, and they take a minute:

1. Does it actually work? Run it. Don’t trust “the diff looks fine.”
2. Can I read it? Open the file and read the whole edited region, not just the highlighted lines.
3. Can I explain, in one sentence, why this change exists? If you can’t, it’s probably doing something you didn’t intend.

Yes to all three: keep it. No to any: it isn’t done — and the fix is usually to stop and restart clean rather than push through, which is when to stop and start over.

If you take one working habit from this page, make it the boring one: read the diff before you accept it. Not thoroughly — quickly, and every time. The point isn’t distrust. It’s that reviewing at the moment of change is where a mistake costs the least, and it is the same instinct that makes code review valuable between two humans. Everything else here is a safety net for the times you don’t.