Now that the last chapter covered the read-only tools, it's time for the two most important tools that actually write: Edit and Write. Both genuinely change something in your project - which is why Claude Code treats them differently from pure read tools, as you'll see in the next chapter.

Edit: a targeted change to an existing file

Edit changes an existing section of an already-existing file, without touching the rest of the file. In principle it works like "find and replace": a specific, uniquely identifiable piece of text is replaced with a new one. That makes Edit the right tool for targeted changes: fixing a bug in a single function, consistently renaming a variable, adjusting a single line of configuration.

Because Edit only touches the affected section, the rest of the file - comments, formatting, other functions - stays untouched. That also makes changes easier to follow later, for example in a git diff (more on that in block 5).

Write: writing a file from scratch

Write writes a file from the ground up - either a completely new file, or fully replacing the content of an already-existing file. Write is the right tool when a file doesn't exist yet (for example a new component or a new test module), or when an existing file needs such a fundamental overhaul that a series of individual Edit changes would be messier than a complete rewrite.

Which tool makes sense when

• Edit for targeted, localised changes to existing files - the normal case for bug fixes and smaller adjustments.
• Write for new files, or for overhauls of an existing file so extensive that a full rewrite is clearer than many individual edits.

In practice you usually don't make this decision yourself - Claude Code picks the right tool based on your request. But it helps to know the difference so you can better judge proposed changes: an Edit change typically touches only a few lines, a Write change can cover the entire file.

Reviewing changes before they happen

Before an Edit or Write change is actually saved, Claude Code usually shows you exactly what's about to change - typically as a before/after comparison, similar to a git diff. That gives you the chance to review the change before it takes effect. Exactly how that confirmation works and how you configure it is the topic of the next two chapters.