1 min lesson
Multi-file edits and diff coordination
Tell someone how to act on this idea: "Model the whole change as a map from file path to a list of in-file edits."
Step 1 of 3
When an agent rewrites a function and updates its three call sites in other files, that is a multi-file edit. It must land as one unit or not at all.
Model the whole change as a map from file path to a list of in-file edits. The unit of work is the batch, not the individual edit, because a half-applied refactor leaves the repo broken.
Learn more
Full explanation
Full explanation
type MultiFileEdit = Map<string, Edit[]>; interface ApplyResult { applied: Map<string, string>; // path -> new contents conflicts: string[]; // paths that could not apply }
Apply atomically, report conflictsall-or-nothing across files
Compute every new file body first, in memory, before you write a single byte to disk. If any file fails - overlapping edits, a stale base, an out-of-range offset - you abort the whole batch and report which paths conflicted. The user sees one clean failure, not a repo in a torn state.
Interactive diagram. Step through it with the Next and Previous controls below, or Tab to a region to read its detail.
Everything happens in memory until one gate passes; nothing touches disk before it.
Learn more
Optional practice
Practice: Multi-file edits and diff coordination
QYou're applying a multi-file edit (a function rename plus its call sites in three other files). Which approach keeps the change atomic?