I started putting a “change budget” on AI coding tasks

by

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?

5 views

Add a comment

Replies

Best

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.