Technique — limit the blast radius
the less we touch, the easier it is to check
What it is
By default an AI assumes it may change anything within reach. You asked for a function to be fixed — and along the way variables in the neighbouring one have been renamed, imports reordered, and error handling "improved" where nobody asked.
The technique is to name the boundaries in advance. The benefit is not tidiness but checkability: a ten-line diff you will read, a two-hundred-line diff you will not. And an unread diff is code you do not control.
What it looks like in code
Sentences that work
Change only the format_report function. Don't touch the rest
of the file.Changes only in handlers/weather.py. If something else needs
changing, say so, but don't do it.Don't touch imports, formatting or the names of existing
variables. Only the logic inside the named function.The third removes the most common source of noise: AIs love reordering imports and tidying up style, and those changes take up more of the diff than the real edit does.
The other half of the technique
Limiting the zone is not enough — you have to give a way out if the boundaries turn out to be wrong:
Change only fetch_weather. If the task cannot be solved without
touching anything else, stop and tell me what else needs
changing and why. Don't do it yourself.Without that sentence the AI, on hitting the limit, will either break it quietly or produce a worse solution just to stay inside it. With it, it asks — and you decide.
What to tell the AI
Boundaries come in three sizes
| Zone | When | How to say it |
|---|---|---|
| Function | a pinpoint fix, a bug | "only the function X" |
| File | a feature in one place | "changes only in file Y" |
| A set of files | a connected change | "you may touch A, B and C, nothing else" |
Start with the narrowest that looks sufficient. Widening it when the AI asks is easy; narrowing it after it has rewritten half the project is not.
Checking the boundaries by the diff
After a change, look first not at the contents but at the size:
git diff --statOne line of output where you expected one — good. Seven changed files where you expected one — a signal to stop and read carefully, whatever the reply said.
What to look for
Boundaries broken quietly. Checked not by reading the reply but with git diff --stat. In its text the AI usually says it did only what was asked.
Imports reordered, formatting changed. Harmless in itself, but it inflates the diff and hides the real changes in it. Forbid it in its own sentence.
The boundaries turned out too narrow. If the AI reports three times running that the task cannot be done within the limits, it is probably right. Widen the zone deliberately rather than dropping the constraint altogether.
The change smeared across the file. Even inside the permitted zone the edits may land in ten places instead of one. Ask: "make the change in one place rather than patching several".
Cheat sheet
Name the zone in advance: function · file · set of files.
Start with the narrowest; widening is easier than rolling back.
Forbid touching imports and formatting in a separate sentence.
Always add: "if it can't be done, say so, don't do it yourself".
Check the boundaries with
git diff --stat, not by the AI's reply.An unread diff is your responsibility.