Leaning on Copilot Edits for multi-file, reviewable diffs instead of raw chat

I spent most of a year describing multi-file changes to Copilot Chat, getting back four or five code blocks, and manually pasting each one into the right file while trying to hold the whole change in my head at once. It worked. It was also the single most error-prone part of using the tool, and the errors weren’t the model’s, they were mine, made while transcribing.

Copilot Edits fixes exactly that, and it’s a smaller change than it sounds: the output becomes a diff against your actual working tree instead of a transcript you have to reassemble by hand.

What actually changes

Chat answers a question. Edits proposes a change. That’s the whole distinction, and it turns out to matter enormously in practice.

With Chat, a request touching three files comes back as three code blocks, each requiring you to find the right file, work out what’s actually different from what’s already there, and paste carefully enough not to lose a line you needed. Every one of those steps is a place to introduce a bug that has nothing to do with the AI being wrong.

With Edits, the same request comes back as an actual diff, applied against your working files, viewable the same way you’d review any other change: added lines, removed lines, in context. You’re reviewing a diff, which is a skill everyone doing this job already has, instead of proofreading a transcript, which is a skill nobody has because it’s not a real skill.

Reviewing it like you’d review anything else

The habit worth building here is treating an Edits session exactly like a colleague’s pull request, because structurally that’s what it is.

Read the diff file by file rather than accepting the whole session in one click. Multi-file changes from any source, human or model, tend to have one file that’s the actual point and several that are along for the ride, and those secondary files deserve a slower read precisely because they’re easy to wave through.

Watch for the specific failure mode this tool has: a plausible-looking edit applied to the wrong file because two files share a similar structure. It happens more than the marketing suggests, and it’s exactly the kind of mistake that’s invisible in a Chat transcript and glaringly obvious in a proper diff, which is itself a decent argument for using Edits even on changes you’d have been comfortable doing via Chat.

Where the multi-file view actually pays for itself

The gain isn’t uniform across kinds of changes. It’s largest on the boring, mechanical, sprawling ones.

Renaming a function used across a dozen call sites. Updating an interface and every implementation that satisfies it. Adding a parameter to a constructor and fixing every call site that now needs it. These are changes with a single clear intent and a wide, tedious blast radius, exactly the profile where Chat’s copy-paste model falls apart and where a proper diff view lets you scan fifteen mechanical edits in the time it would take to manually apply three.

For genuinely exploratory work, where you’re not sure what the change should even look like yet, Chat is still the better tool. You want the back-and-forth of a conversation, not a diff to review, when you’re still figuring out the shape of the problem. Edits is for once you know what you want and the work is mostly mechanical execution across files.

The undo that makes this safe to try

The thing that actually earns trust here is that a rejected Edits session leaves your files untouched, cleanly, which is not a small thing once you’ve been burned by a Chat paste that half-applied.

That safety net changes the calculus on when to reach for it. I’ll now let Edits attempt something I’m only sixty percent sure is a good idea, because reviewing and discarding the diff costs nothing. Doing the equivalent experiment via Chat meant committing to manually undo a paste if it turned out wrong, which is friction that quietly discouraged trying anything speculative.

What it still doesn’t solve

Edits doesn’t make the underlying suggestions any smarter, and it won’t catch a change that’s confidently wrong in a way that still compiles. It also doesn’t replace running the tests, which stays non-negotiable regardless of how clean the diff looks.

What it solves is narrower and more useful than it sounds: the gap between a model proposing something reasonable and you being able to trust that what actually landed in your files is what you think you approved. For anything touching more than one file, that gap was where most of my actual mistakes were happening, not in the model’s reasoning.

More field notes on GitHub Copilot

This piece is one entry in a running series on how AI coding tools change day-to-day engineering work. For more practical notes on Copilot specifically, browse the full set at /blog/tag/github-copilot/. For the wider view across every tool in the stack, the AI coding tag collects the whole archive in one place.