Back to Guides
Builders

How to Make Multi-File Changes With Claude Code

When a change touches more than one file, you probably paste each file into a chat separately, apply Claude's suggestion to one, then paste the next and hope you're being consistent across all of them.

Tip

Claude Code holds the whole picture across files at once, so you describe the outcome you want a single time, not once per file.

Describing the change, not the files

Instead of pasting file contents, tell Claude Code what pattern to find and what it should become. It searches your actual project, makes the edits, and can run your test suite to check its own work, all in one task.

  1. 1

    Describe the pattern, not a location

    Say what should change ("every call to the old helper") rather than listing file paths yourself. Claude Code can find them faster and more completely than you can by hand.

  2. 2

    State what should NOT change

    If a similarly-named function elsewhere should be left alone, say so explicitly. This is the detail that prevents an overly broad edit.

  3. 3

    Ask it to verify, not just edit

    Request a test run or a specific check afterward, so you're not manually confirming every affected file yourself.

  4. 4

    Review the diff before committing

    Treat Claude Code's output the same way you'd treat a colleague's pull request: read what actually changed before you accept it.

Prompt
“

Find every place in this repo that calls the old formatCurrency helper, replace it with the new formatMoney utility (same arguments, different name), and run the test suite to confirm nothing broke. Leave formatCurrencyRange untouched, it's a different function despite the similar name.

”

Inside Claude Tutorial

Describing outcomes, not steps, is a transferable skill

Telling Claude what should be true when it's done, rather than walking it through every step yourself, is the same underlying habit the app teaches across many kinds of work, not just code.

Coming Soon
Download on theApp Store
GET IT ONGoogle Play

  • Your git working directory is clean before you start, so a change is easy to review or revert on its own

  • You've named anything that looks similar but should be left alone

  • You have a real way to verify the result, tests, a build, a manual check, not just a visual read of the diff

Continue reading