Programming with AI
ENRU
3.13

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

Diagram from the book — to be redrawn for the web
The narrower the zone, the smaller the diff — and the likelier you are to actually read it.

Sentences that work

Prompt
Change only the format_report function. Don't touch the rest
of the file.
Prompt
Changes only in handlers/weather.py. If something else needs
changing, say so, but don't do it.
Prompt
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:

Better
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

ZoneWhenHow to say it
Functiona pinpoint fix, a bug"only the function X"
Filea feature in one place"changes only in file Y"
A set of filesa 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 --stat

One 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.