I started putting a “change budget” on AI coding tasks
I noticed a pattern with AI coding agents that bothered me more than the actual code quality.

I'd ask for a small change.
The change would work.
Then I'd look at the diff and realize the agent had touched:
11 files for what I thought was a 2-file task.
Sometimes there was a good reason.
Sometimes it was just architecture drift disguised as cleanup.
So I started experimenting with a simple rule:
Every task gets a change budget.
Before implementation, I ask the agent to identify:
files it expects to modify
files it expects to add
dependencies it expects to touch
anything outside that scope that might be affected
Then I set a rough boundary.
For example:
“This should probably stay within these 3–4 files. If you think it needs more, stop and explain why before continuing.”
That has created a useful checkpoint.
If the agent suddenly says:
“I also need to refactor these 7 other files…”
I can decide whether that is actually necessary before the diff exists.
It's not a hard rule. Some changes genuinely have a larger blast radius.
The useful part is making that expansion visible before implementation, instead of discovering it after everything has changed.
I'm starting to think AI coding needs another concept alongside "plan":
Scope control.
Not just:
“What are you going to build?”
but:
“How far should this change be allowed to spread?”
How do you handle unexpected scope expansion when an AI agent starts touching more of the codebase than you expected?
Replies
My approach: before the agent runs, I make it answer what, why, and how it plans to do it. It sorts out the logic itself after that.