Answer
How do you stop a coding agent from changing unrelated files?
Name the files it may touch, and require anything else it noticed to be reported rather than fixed.
Name the files it may change, and require anything else it notices to be reported instead of fixed. The changes are not accidents; they are helpful acts that arrive inside a review scoped for something smaller.
The behaviour has an understandable origin. Working through a task, the agent encounters something else that is wrong — an obvious bug, an inconsistent name, a missing case — and fixes it, because a diligent worker would. The result is a diff that is larger than the task, contains changes nobody asked for, and takes longer to review than the work saved. Repeated a few times, this is the reason teams stop using agents on shared code.
The control that works is separating noticing from acting. Requiring adjacent findings to be reported and not fixed keeps the genuinely valuable half — you learn about the bug — and removes the part that expands the review. This is a single line in the brief and it changes the shape of the output more than any other instruction of comparable length.
Alongside it, name the permitted files or the permitted area explicitly. A general instruction to stay in scope is interpreted against the agent's understanding of scope, which is precisely what is in question when it decides that the adjacent file is part of the job. A list, or a directory, is not open to interpretation.
Reformatting deserves its own mention because it is the most common unintended change and the most annoying. An agent editing a file with a formatter available will often reformat the whole file, producing a diff where two intended lines are buried in three hundred. The fix is usually configuration rather than instruction: format on commit rather than on save, or restrict formatting to changed lines, so the tooling makes the wide change impossible.
A second frequent case is generated artefacts. Lock files, build outputs, snapshots, generated clients. These change as a side effect of running something, they are legitimately part of some changes and not others, and an agent has no reliable way to know which. Stating what to do about them — regenerate and include, or leave alone — resolves it, and leaving it unstated produces both errors on alternate runs.
Finally, review the file list before the content. A change touching files the task had no business touching is identifiable in seconds, and catching it there is much cheaper than discovering it in the reasoning. This also makes the report-do-not-fix rule enforceable, because a violation is visible without reading anything.
The unrelated change is not a mistake, it is initiative arriving in a review that was budgeted for one thing.
Siddharth Sharma, Context Theory
Related questions
Is it worth losing the incidental fixes?
You do not lose them; you receive them as findings and decide. Some will be worth doing immediately and can be requested as their own change with its own review. The thing being removed is not the value, it is the arrival of unrequested work inside a review scoped for something else, which is what makes it expensive.
What if the task genuinely requires touching another file?
Then the agent should say so and either ask or proceed with it named explicitly in the report, depending on how the brief was set. The distinction that matters is whether the extra file was necessary or noticed. A necessary change explained in the report is fine; the problem is the unexplained one.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
| Close rate — response under 5 minutes vs over 24 hours | 32% vs 12% | Category-wide |
2026 speed-to-lead benchmark · verified
Optifai speed-to-lead benchmark · n=939 companies · Q2 2025–Q1 2026 · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Workflow | Unrelated changes originate as helpful fixes to problems encountered during the task rather than as errors, which is why they survive instructions about care and are removed only by separating noticing from acting. | Classifying the unintended files in a set of agent diffs by whether the change corrects something genuinely wrong. |
| Software | Whole-file reformatting is the most common unintended change and is best addressed by tooling configuration — formatting on commit or restricting it to changed lines — rather than by instruction, because the editor action is not under the agent's deliberate control. | Checking whether the project's formatter runs on save across the whole file for the agent's editing path. |
| Response | Generated artefacts such as lock files, build outputs and snapshots change as side effects and belong in some changes and not others, which an agent cannot determine, so an explicit rule is required or both errors occur across runs. | Comparing agent diffs across several runs for inconsistent treatment of generated files. |
| Constraint | Reviewing the changed-file list before the content detects scope violations in seconds and makes a report-rather-than-fix rule enforceable, because a breach is visible without reading any code. | Comparing the file list of a change against the files the task named as permitted. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one