Day 6: How Claude Code Reads and Writes Files — And How To Review Changes

Hey, it's G.

Day 6 of the Claude Code series.

Today's the reality check that keeps you safe while moving fast.

Claude Code doesn't just suggest code changes and wait for you to apply them.

It writes directly to your files. Immediately. On disk.

That's what makes it powerful. That's also what makes git absolutely non-negotiable.

Let me show you how file editing actually works and the habits that keep you safe.

What Actually Happens When Claude Edits Files

Here's what people think happens:

Claude Code shows you a preview of changes → You approve → Changes apply to your files.

Here's what actually happens:

Claude Code edits the file → File is updated on disk → Claude tells you it's done.

No preview. No approval gate. Direct modification.

Example:

> Add input validation to /components/ContactForm.tsx

Claude: I've added email format validation and phone number validation to ContactForm.tsx. The changes are complete.

At that moment, your file has already been modified.

The code is on disk. Not in a preview. Not waiting for confirmation. Done.

Why This Design Makes Sense (And Why It's Risky)

Why It Makes Sense

Speed: No copy-paste. No manual application. Claude writes, you review, you move on.

Real execution: Claude can make changes and immediately run builds to verify they work.

Agent behavior: This is what separates an agent from a code suggester. It acts, not just advises.

Why It's Risky

Bad prompts land directly in your codebase. If Claude misunderstands your instruction, the wrong code is now in your file.

No automatic preview. You have to actively check what changed. It doesn't show you by default.

Multi-file changes can cascade. Claude might edit 5 files based on one prompt. If file 3 is wrong, you need to catch it.

The solution: Git. Always git.

The Three Ways Claude Code Interacts With Files

1. Reading

Claude Code opens and reads files to understand context before making changes.

It does this silently as needed. You don't see "Reading file..." messages.

Example:

> Fix the auth bug in the login flow

What Claude does:

• Reads /components/LoginForm.tsx
• Reads /lib/auth.ts
• Reads /app/api/auth/route.ts
• Understands the flow
• Makes the fix

You only see the result, not the reading process.

2. Editing

Claude modifies an existing file directly on disk.

Sometimes it shows you a diff. Sometimes it just tells you it's done.

Example:

> Add error handling to /lib/supabase.ts

What happens:

• Claude opens /lib/supabase.ts
• Adds try/catch blocks to database calls
• Saves the file
• Tells you "Error handling added to supabase.ts"

Your file is now modified on disk.

3. Creating

Claude creates a brand new file from scratch at the path you specify (or at a path it decides is appropriate).

Example:

> Create a utility file at /utils/formatCurrency.ts with 
> a function that formats numbers as Philippine Peso

What happens:

• Claude creates /utils/formatCurrency.ts
• Writes the function
• Saves the file
• Tells you "Created formatCurrency.ts"

New file now exists in your project.

The Safety Net: Git is Non-Negotiable

Running Claude Code without git initialized is like working without a seatbelt.

Here's why:

Without git:

• Claude makes a bad change → Your code is broken → You have to manually undo it → You might not remember what the original code was

With git:

• Claude makes a bad change → You run git checkout . → Original code restored instantly

Git is your undo button for everything Claude does.

The Workflow That Keeps You Safe

This is what I do every single Claude Code session.

Before Starting Claude

# Make sure everything is committed
git add .
git commit -m "before claude session"

Why: Creates a clean baseline. Every change after this point is Claude's work.

After Claude Makes Changes

# Open a second terminal tab
git diff

What you see:

• Lines added (green with +)
• Lines removed (red with -)
• Exactly which files changed

This shows you everything Claude did.

If Changes Look Good

git add .
git commit -m "add input validation to ContactForm"

Why: Locks in the changes. Creates a checkpoint you can return to.

If Something Looks Wrong

# Revert everything Claude just did
git checkout .

Result: Instant return to your "before claude session" state.

No damage. No manual undo. Just gone.

Real Example (How I Actually Use This)

Scenario: I need to add Zod validation to Resiboko's expense form.

Step 1: Create Clean Baseline

git add .
git commit -m "before adding zod validation"

Step 2: Give Claude the Task

claude

> Add Zod validation to /components/ExpenseForm.tsx
> Validate: amount must be positive number, category required, 
> date must be valid. Use existing UI error components.

Claude responds:

I've added Zod validation to ExpenseForm.tsx. 
Validation is complete with error display.

Step 3: Review Changes Immediately

# Second terminal tab
git diff components/ExpenseForm.tsx

What I see:

+ import { z } from 'zod'
+ 
+ const expenseSchema = z.object({
+   amount: z.number().positive(),
+   category: z.string().min(1),
+   date: z.date()
+ })

- const handleSubmit = (data) => {
+ const handleSubmit = (data) => {
+   const result = expenseSchema.safeParse(data)
+   if (!result.success) {
+     setErrors(result.error.flatten())
+     return
+   }

I check:

• ✅ Imports look right
• ✅ Schema validates what I asked for
• ✅ Error handling is clean
• ✅ Existing code preserved

Looks good.

Step 4: Commit or Revert

If I like it:

git add .
git commit -m "add zod validation to expense form"

If I don't:

git checkout .

Either way, takes 30 seconds to decide.

Advanced Pattern: Ask for the Plan First

For big changes that touch multiple files, I don't let Claude dive straight in.

Instead:

> Before editing anything, tell me exactly what changes 
> you plan to make and which files you'll touch

Claude responds:

I'll make the following changes:

1. /components/ExpenseForm.tsx
   - Add Zod schema at top
   - Modify handleSubmit to validate
   - Add error state display

2. /lib/validation.ts
   - Create shared validation helpers
   
3. package.json
   - Add zod dependency

Does this plan look good?

Now I can:

• Review the plan before any code is written
• Catch scope creep ("wait, why are you creating a new file?")
• Approve or redirect before files are modified

Then:

> Approved. Proceed with those changes.

What To Check in git diff

After every Claude session, I specifically look for:

1. Files That Shouldn't Have Changed

Example:

diff --git a/lib/supabase.ts

My thought: "Wait, I didn't ask Claude to touch that file. What did it change?"

Action: Review carefully. Might be a mistake.

2. Deleted Code That Should Stay

Example:

- export function formatDate(date: Date) {
-   return date.toLocaleDateString()
- }

My thought: "Why did Claude delete my formatDate function?"

Action: Check if it was replaced with something better or accidentally removed.

3. New Dependencies Added

Example:

diff --git a/package.json
+ "zod": "^3.22.0"

My thought: "Claude installed zod. Did I approve that?"

Action: Verify the dependency is necessary and safe.

4. Configuration Changes

Example:

diff --git a/next.config.js

My thought: "Claude changed my Next.js config. Is this intentional?"

Action: Review config changes carefully. These can break your build.

Common Mistakes (What Not to Do)

Mistake 1: Not Using Git At All

Problem: Claude makes changes → Something breaks → You have no way to undo it → Manual reconstruction nightmare.

Solution: Initialize git before using Claude Code. Always.

Mistake 2: Not Reviewing Changes Before Committing

Problem: Claude makes 10 file changes → You commit without checking → Later discover bugs → Can't tell what Claude did wrong.

Solution: git diff after every Claude session. Always.

Mistake 3: Letting Claude Make Big Changes Without Seeing the Plan

Problem: Claude touches 8 files based on a vague prompt → Half the changes are wrong → Untangling is painful.

Solution: For multi-file changes, ask for the plan first. Review before execution.

Mistake 4: Working in Main Branch Without Backups

Problem: Claude breaks something critical → You need to revert → But you've already pushed to production.

Solution: Use feature branches for Claude Code work. Or at minimum, commit before and after every session.

Best Practices (What Actually Works)

1. Commit Before Every Claude Session

git add .
git commit -m "before claude: adding validation"

Creates a clean diff point.

2. Review Immediately After Changes

git diff

Don't wait. Check while the context is fresh.

3. Commit Good Changes Quickly

git add .
git commit -m "claude: add zod validation to forms"

Lock in wins. Creates restore points.

4. Use Descriptive Commit Messages

❌ Bad:

git commit -m "claude changes"

✅ Good:

git commit -m "claude: refactor auth error handling in supabase.ts"

Why: Future you needs to know what Claude did and why.

5. Keep a Claude Session Log

I maintain a simple log:

# Claude Code Sessions

## 2026-02-24 - Add Zod Validation
- Files touched: ExpenseForm.tsx, package.json
- Changes: Added zod schema, form validation, error display
- Commit: abc123f
- Result: ✅ Works perfectly

## 2026-02-23 - Refactor Auth
- Files touched: lib/auth.ts, lib/supabase.ts
- Changes: Added error handling, retry logic
- Commit: def456g
- Result: ⚠️ Had to manually fix retry timing

Helps me track what Claude did and what worked.

My Raw Notes (Unfiltered)

Git is non-negotiable when using Claude Code. Always always always.

It writes directly to disk so if it messes something up you need to be able to revert fast.

I use git diff constantly now — after every Claude session before I do anything else.

Also got into the habit of committing before starting a Claude session so I have a clean baseline to diff against.

Ask it to plan before editing when the change is big or touches multiple files.

The workflow is simple: commit before, diff after, commit good changes, revert bad ones.

Tomorrow (Day 7 Preview)

Topic: Understanding Claude Code's context window — how much of your project it can "see" at once, and how to work within that limitation.

What I'm testing: How context limits affect large codebases, what happens when you hit the limit, and strategies for working with huge projects.

Following This Series

Daily updates for 30 days. Each day builds on the last.

So far:

• Day 1: Setup and installation
• Day 2: Prompting that actually works
• Day 3: CLAUDE.md permanent briefing
• Day 4: What Claude can see in your project
• Day 5: Running terminal commands
• Day 6: Reading and writing files (today)
• Day 7: Context window limitations (tomorrow)

G

P.S. - Four commands that keep you safe: git commit before, git diff after, git add . if good, git checkout . if bad. That's it.

P.P.S. - If you're not using git with Claude Code, you're flying without instruments. Initialize it today.

P.P.P.S. - The "plan first, then execute" pattern for multi-file changes has saved me from so many bad edits. Highly recommend.