You can install a coding agent in two minutes and make your first change in ten, which the quickstart walks you through. The skill that decides whether all that speed helps you is the one nobody teaches: how to review what the agent proposes and keep it easy to undo. This guide is that skill.
The two failure modes are equally common. One reader approves every diff without reading it and ships a subtle bug. The other rejects everything out of fear and ends up slower than typing the code by hand. The middle path is a real review, done fast, with a safety net underneath so a mistake costs you a minute, not a day.
Why does the agent ask before it changes code?
A coding agent can read your whole project, edit several files, and run commands. Because it has that much reach, Claude Code asks for your approval before it writes a file or runs anything that changes state. That prompt is the control point. Everything in this guide is about using it well.
The prompt shows you a diff: the exact lines it wants to remove and add. You get to say yes, no, or "no, do it this way instead" before a single character lands on disk.
What should I check in every diff?
A good review is fast because you are checking for specific things, not reading the code like a novel. Run each diff through three questions.
1. Does it do what you asked? Match the change against your request, not against "is this reasonable code". An agent will happily write clean, correct code that solves a slightly different problem than the one you have.
2. Does it touch only what it should? Scope creep is the most common issue. You asked it to fix one function and the diff also reformats an unrelated file, renames a variable across the project, or "helpfully" deletes a comment. Edits outside the blast radius of your request deserve a closer look or a rejection.
3. Would you have written it this way? You do not need it to match your style exactly, but watch for the patterns that bite later: a swallowed error, a hard coded value that should be config, a new dependency added for a one-line job, a test that asserts nothing.
If a diff passes all three, approve it. If it fails one, reject and redirect.
What happens when I reject a diff?
Saying no to a diff does not throw away the work. You reject it and tell the agent what was wrong, in plain English, and it tries again with that feedback in context. This is the single most useful habit a beginner can build: treat a bad diff as the start of a quick back-and-forth.
no, keep the public function signature the same and only change the internals
that touches the config loader too. leave it alone and only edit the parser
good, but you swallowed the error. let it propagate and add a test for the failure case
Specific feedback beats a vague "try again". You are reviewing a junior teammate who is fast and eager and will do exactly what you steer them toward.
Which permission mode should I use?
Claude Code has a few permission modes that change how often it stops to ask.
Cycle through them with Shift+Tab. The mistake is leaving it on one setting
forever instead of matching the mode to the risk in front of you.
| Mode | When to use it |
|---|---|
| Ask every time | While you are learning the tool, or on unfamiliar or risky code |
| Accept edits | A well-scoped task on a clean branch you can easily undo |
| Plan mode | You want a written plan approved before any edits at all |
The honest rule of thumb: the cost of an unwanted change is what sets the mode. On a fresh branch with everything committed, accept-edits is fine because undo is one command away.Common gotchaAccept-edits only saves time if you still read the diffs after the fact.Walk away and let a long task run, and edits stack up faster than you can check them, so scope the task small enough to review in one sitting. On code you do not understand yet, stay on ask-every-time and read each step. For anything large, start in plan mode so you approve the approach before the edits, which the workflows guide covers in depth.
How do I undo an AI change?
Even a careful reviewer misses things. The fix is not to review harder, it is to make every mistake cheap to reverse. Three habits do almost all the work.
Start on a clean branch. Before you hand the agent a task, commit or stash your current work so the only changes on the branch are the ones it makes. Now the diff between you and the last commit IS the agent's work, and you can throw all of it away with one command if you need to.
git switch -c try/agent-refactorCommit in small steps. After each chunk of approved work, commit it with a clear message. Small commits give you fine-grained undo: if the third change was wrong, you drop just that commit instead of losing the first two as well.
commit what we have so far with a clear message before you start the next part
Know your two escape hatches. When something slips through, you have a fast way back.
# Throw away uncommitted changes in a file the agent broke
git restore path/to/file.ts
# Undo the last commit but keep the changes staged, so you can fix and redo
git reset --soft HEAD~1You rarely type these yourself. Ask for the outcome and let the agent run the git for you: "undo the last change, it broke the build." But knowing they exist is what lets you approve confidently instead of nervously.
Let the agent help you review
The reviewer does not have to be only you. Before you push a branch, ask Claude Code to review its own work with fresh eyes:
review the changes on this branch for bugs and anything that looks risky
It will read the diff and flag likely bugs, missed edge cases, and changes that drifted out of scope. It is not a replacement for your judgement, since it is reviewing its own output, but it is a strong second pass that catches the obvious things before a human ever sees them. Run your normal tests and type checks too: a green test suite is the cheapest reviewer you have.Common gotchaIt is tempting to treat the agent's self-review as the review and skip your own pass. The trap is that an agent reviewing its own diff shares the same blind spot that produced the bug, so it will confidently bless code it just got wrong.Use the self-review as a first filter, then still read the diff yourself before you approve or push.
Putting it together
Here is the whole loop, the way it runs once the habits are in place.
None of this slows you down once it is muscle memory. A diff review takes seconds when you know the three questions. A clean branch costs one command. And the payoff is the thing that makes a coding agent worth using at all: you move at the agent's speed while staying the person who decides what lands.
Where to go next
- Set Up Claude Code the Right Way covers the day-one configuration that makes every review easier.
- Claude Code Workflows goes deep on plan mode and using the agent to review its own work.
- How Claude Code memory works explains how to record a convention once so the agent stops repeating a mistake you keep rejecting.