01 · The workflow
How Claude Code edits work
Claude Code doesn't push changes blindly. Every file edit follows a confirm-before-write pattern that keeps you in control.
01
You describe the change
Use the prompting skills from Day 04. Be specific: name the file, the function, what should change, and any guardrails. Claude reads the relevant files to understand context.
02
Claude proposes a diff
Before writing anything, Claude shows you exactly what it intends to change: added lines in green, removed lines in red. This is your moment to review. Read it carefully.
03
You accept, reject, or redirect
Say "looks good, apply it" to proceed. Say "stop" or "don't do that" to cancel. Say "that's right but also fix X" to refine before writing. You never lose control of what lands in your files.
04
Claude writes and verifies
After applying, Claude often runs a sanity check: linting, compiling, or searching for related code that needs updating. It tells you what it did and flags anything still outstanding.
The risk ladder: calibrate your review effort
Low
Comments, docs, formatting: Quick scan. If it reads right, apply it. Undo is trivial.
Low
New functions in isolation: Read the logic. Verify inputs and return values match what callers expect.
Medium
Editing existing behavior: Check every line that changed. Ask: what could the previous version do that this one can't?
Medium
Touching shared utilities: Run the impact check from Day 04 before accepting. Multiple callers means multiple ways to break.
High
Auth, payments, data migrations: Treat Claude's output as a draft. Review as if a junior wrote it. Test manually. Don't rush.
01 / 05
02 · Reviewing changes
How to read a diff
A diff is the most important document in the edit workflow. Here's how to read one quickly and catch problems before they land in your codebase.
Example diff: Claude proposes
src/auth/validateToken.js
@@ -12,8 +12,10 @@ function validateToken(token) {
if (!token) {
- return undefined;
+ return false;
}
const decoded = jwt.verify(token, process.env.JWT_SECRET);
- return decoded.exp > Date.now();
+ if (!decoded || !decoded.exp) return false;
+ return decoded.exp > Date.now() / 1000;
}
−
Red lines (removals): what's leaving
Every red line is something that currently exists and will be gone. Ask: is anything that relied on this behavior going to break? Is this removal intentional or a side effect?
+
Green lines (additions): what's arriving
Every green line is new code. Read it for correctness: does the logic work? Are there edge cases? Does the new behavior match what you asked for?
⋯
Context lines: your anchor
Unchanged lines shown for orientation. Use them to verify Claude changed the right place and didn't accidentally shift a block into incorrect scope.
Catch this Scope drift in the diff above
Notice the diff above fixes two things: the
undefined vs false return bug AND a Date.now() / 1000 unit bug. If you only asked for the first fix, this is scope drift. Not necessarily bad, but you need to see it and decide. Always ask: did Claude fix more than I asked for?💡 When a diff is long and you're not sure about a section, ask: "In that diff, explain the change on line [N]. What was wrong with the original and why is this better?" You can interrogate individual lines before accepting.
02 / 05
03 · Your safety net
Git is your undo button
The single habit that makes Claude Code sessions fearless: commit before every significant AI-assisted change. Git turns "Claude broke something" into a five-second recovery.
"I don't fear Claude making a mistake. I fear not having a commit to roll back to."
Common wisdom from experienced Claude Code users①
Commit before you start
Before a Claude session where you'll make real edits, commit your current work. A clean working tree means any Claude change is isolated and fully reversible.
②
Work on a branch
Create a dedicated branch for Claude-assisted work. If anything goes wrong, you abandon the branch. Main stays clean.
git checkout -b claude/fix-token-validation③
Commit incrementally
After each accepted edit that works, commit. Small commits = small rollbacks. Don't let a two-hour session accumulate uncommitted changes.
Git commands to know during Claude sessions
git status
See what Claude changed before staging anything
git diff
Full diff of all unstaged changes, your second review layer
git checkout -- [file]
Discard Claude's changes to a specific file instantly
git stash
Temporarily shelve all changes if the session goes sideways
git reset --hard HEAD
Nuclear reset: discard everything back to last commit
⚠ git reset --hard is permanent. It deletes all uncommitted changes, including changes Claude just made that you haven't reviewed. Only use it when you want to start completely over. For single-file rollback, use
git checkout -- filename instead.
Let Claude manage Git too
Trust but verify
"After applying those changes, create a git commit for them. Write a conventional commit message: type(scope): description. Show me the message before committing. Don't commit yet."
03 / 05
04 · Recovery
When Claude gets it wrong
It will happen. Claude misunderstands scope, misses context, or produces code that passes your review but fails at runtime. Here's how to handle it cleanly.
🔄
Redirect, don't restart
If the result is close but wrong, correct it in the same conversation. Claude holds context: "that changed the wrong function" or "you missed the edge case where X is null" works better than starting over.
↩
Use /undo for the last write
If Claude just applied a bad change, type
/undo. This reverts the most recent file write. It's the fastest recovery for a change you haven't committed yet.🌿
Abandon the branch for major misses
If an entire session went in the wrong direction:
git checkout main and delete the branch. Your main branch is untouched. Start fresh with a sharper prompt.🔍
Add context and try again
Most Claude misses are context gaps, not model failures. Before retrying, add the missing piece: the exact file and function name, a constraint that was implied but not stated, or an example of what the correct output looks like.
Pro move Ask Claude to explain before it writes
Add "Explain your approach first, then I'll tell you to proceed" to any complex edit prompt. This surface-level reasoning review catches misunderstandings before a single line is written. It takes 30 extra seconds and saves 20 minutes of cleanup.
Know this pattern The confident wrong answer
Claude Code can produce code that looks correct, sounds correct, and is wrong. It doesn't always know what it doesn't know. For high-stakes changes, test manually. For logic you're unsure about, ask "what would break this?" before accepting. Your skepticism is a feature, not a sign of distrust.
04 / 05
05 · Your outcome
Make your first real edit today
Pick something real, not a toy project. A bug, a missing feature, a function that needs a test. Work through the full workflow: branch → prompt → diff review → accept → commit.
Edit prompt template
Fill in the blanks
"In [file], the [function] currently [what it does wrong]. Fix it so that [what it should do]. Don't change the function signature or any behavior outside this specific case. Show me the diff before writing."
Git setup before you start
Run in terminal first
"Create a new branch called claude/day05-edit for today's session. Commit my current changes so we have a clean baseline to work from."
Wrap-up prompt
End of session
"Summarize what we changed in this session: files touched, what each change does, and anything I should verify manually before merging. Then write a commit message for all of it."
What did you edit today?
What would you do differently next time?
Day 05 checklist
- Created a feature branch before starting the session
- Reviewed the full diff before accepting any change
- Identified at least one case of scope drift or unexpected change in the diff
- Successfully applied a change and committed it
- Used /undo or git checkout to roll back at least once (practice it)
- Asked Claude to explain its approach before a complex edit
- Ended the session with a clean commit and a one-paragraph summary of what changed
05 / 05
Week 01 complete
You've covered the full foundation: mental model, installation, code reading, prompting technique, and real edits. Week 02 starts with writing tests, the skill that amplifies everything else you've built this week.
Take the weekend. Use Claude Code on a real task. Notice what feels natural and what still feels awkward. That gap is your Week 02 curriculum.