Lesson 9: Making Your First Edit

Day 9 of 50 · ~7 min read · Phase 2: Core Workflows

The Opening Question

You've watched Claude read your code. You've seen it navigate files. You've understood how it reasons about what you're asking.

Now comes the moment that changes everything.

Claude wants to change something. Maybe add a feature, fix a bug, refactor some code. It's asking for permission to edit a file.

Here's the real question: What does it mean to let an AI change your code?

That's not a technical question. It's a decision question. A trust question.

Discovery

Let's think through this carefully.

Question 1: Why would you let Claude edit your code instead of doing it yourself?

Before we get into how Claude edits, let's ask why.

You could always:

• Read Claude's suggestion and make the change manually
• Copy code from Claude and paste it yourself
• Ask Claude to explain, then code it yourself

So what's the benefit of letting Claude actually change the files?

Pause and think: What changes if Claude does the work versus just telling you what to do?

Here's the key difference: speed and confidence at scale.

If Claude suggests one small edit, doing it yourself is fine. But if Claude is adding 15 lines across 3 files, reviewing the diffs, running tests, and fixing issues it finds — you'd spend an hour doing manually what Claude can do in seconds.

More importantly: Claude can iterate. It can make a change, run tests, discover a problem, and fix it. All while you watch. But you have to grant Claude that permission first.

Question 2: How does Claude actually edit code?

There are two tools for making changes: Edit and Write.

Write is simpler but blunter. It says: "Create a new file with this content" or "Replace the entire contents of this file." Useful for new files, but risky for existing code because one mistake replaces everything.

Edit is more precise. Claude provides three things:

1. The file path
2. old_string — the exact text it wants to replace
3. new_string — what it should become

For example:

Edit: /src/auth.js
Old: function login(user, password) {
  return authenticate(user, password);
}

New: async function login(user, password) {
  try {
    return await authenticate(user, password);
  } catch (error) {
    console.error('Login failed:', error);
    throw error;
  }
}

Claude shows you exactly what's being replaced and what it becomes. If the old_string doesn't match what's actually in the file, the edit fails. That's a safety feature — it prevents Claude from accidentally editing the wrong line.

Question 3: What should you check before accepting an edit?

When Claude shows you an edit, you're not just watching. You're approving.

What should you think about before saying "yes"?

Pause and think: If a junior developer showed you a code change, what would you check before accepting it?

Here are some key things:

1. Does it match the request? Did Claude do what you asked, or did it go off on a tangent?
2. Does it follow your style? Does the code look like it belongs in your project? (indentation, naming, patterns, etc.)
3. Are there any obvious bugs? Does the logic look right?
4. Does it break anything? Will this cause tests to fail or other code to break?

For the last one, you don't need to mentally run the entire test suite. But if the change is in a critical path or affects other files, you should at least think about whether it could cause problems.

Here's the good news: Claude usually checks #4 itself. It'll run your tests or compile your code to verify the change works. It'll show you the results.

Question 4: What if Claude's edit goes wrong?

Let's be realistic. Claude will sometimes make mistakes.

Maybe Claude edits the wrong function. Maybe it introduces a subtle bug. Maybe it creates invalid syntax.

What happens then?

If you notice before accepting the change, you can just reject it. "No, that doesn't look right." Claude will re-read the code and try again.

If you accept it and then find a problem (like the tests fail), Claude is usually still in the conversation. You say: "The tests are failing because of your change. Here's the error." Claude sees the error, diagnoses the problem, and edits again to fix it.

This is the agentic loop at work:

1. Claude edits code (act)
2. You or Claude checks the tests (check)
3. If tests fail, Claude reads the error, reasons about the problem, and edits again (loop back)

The key is: you're never locked into a bad state. You can always reject a change, revert a commit, or ask Claude to fix something.

The Insight

Here's what's really happening when you let Claude edit:

Making your first edit is a trust decision. You're saying: "I trust Claude to read my code, understand what I want, make changes that match my project's style, and iterate if something goes wrong." That trust is earned by watching Claude work, seeing it be precise with the Edit tool, checking its work before accepting changes, and catching it if it makes mistakes.

The mental model: Letting Claude edit is like code review. A colleague proposes a change. You review it (watch the diff), ask questions if something seems off, run tests, and either approve it or ask them to revise. Claude is the colleague. You're the reviewer. And you stay in control the whole time.

Try It

Let's make your first Claude-edited change.

1. Start a conversation in a project you're comfortable with: claude

2. Ask Claude to make a small edit:

   • "In the main app file, add a comment at the top explaining what the app does"
   • "In the utils.js file, add a simple helper function that trims whitespace"
   • "In the config file, add a new configuration option for debug mode"

3. When Claude shows you the edit:

   • Read the diff. Does the old_string match what's really in the file?
   • Does the new_string look right? Does it follow your project's style?
   • Is there anything that concerns you?

4. If it looks good, approve it. You might type: "Yes, that looks right" or "Approve" (exact phrasing depends on Claude's prompt).

5. If something seems off, reject it. You can say: "No, that doesn't match the code" or "Let me see the context around that edit" or just "No, please try again."

6. Watch Claude iterate if needed. If you reject it or if tests fail, watch Claude read the error, reason about it, and propose a new edit.

Key Concepts Introduced

Bridge to Lesson 10

You've now edited code. You've experienced the decision of trusting Claude with your files.

But here's a question: when Claude reads your code and reasons about what to do, it can only "remember" a certain amount of information at once.

This is the concept of context window — essentially, Claude's working memory.

Next lesson's question: What happens when your project is bigger than Claude's memory?

We'll explore context window management and learn strategies for working with large codebases.

← Back to Curriculum · Lesson 10 →