Stop AI Rewriting Files You Never Touched

A button ordered, a renovation delivered

"Add a retry button to the failed-payments page."

The agent added the button. It also refactored the payments code "for consistency", upgraded two dependencies "while here", reformatted four unrelated files and renamed a helper used in six places.

The button worked. The diff touched fifteen files.

Review took far too long. It caught a renamed export that broke webhooks, and it left one question open: what else changed?

Agents expand scope by default. Unbounded prompts produce unbounded diffs.

Scoped work against sprawl

Three lessons come out of sprawl.

"While I'm here" is the most expensive sentence. Agents batch improvements as eagerly as the task. Each one is reasonable alone and a nightmare together.

Refactors hide behavior changes. Renames and reformatting camouflage real changes. Reviewers skim the familiar parts, which is exactly where the breaking rename hides.

Unasked upgrades are unowned risk. No changelog read, no compatibility check, no rollback plan. Discovered at 2 a.m.

What to do

Name the files before any code.

Put one line at the top of every task: touch only these three files, and ask before touching another.

Named files turn an open task into a bounded one. Thirty seconds of filenames prevents an hour of archaeology.

Cap the diff mechanically. Look at its size before you read a line.

More than three files, or about 150 lines, is an automatic reject with the same prompt again.

"Too big" is arguable. "Four files against a limit of three" is arithmetic.

Quarantine the good ideas.

Ask the agent to write its suggestions into a notes file instead of acting on them.

Once a month, read the list.

Schedule one or two.

Delete the rest.

The agent feels heard. Nothing unasked reaches your code.

When the task really is big

Say so upfront. Name the seven files and the reason for each.

Review that as a plan before any code is written. Big and declared is fine. Big and surprising is not.

Large features split into slices: data, actions, route, screen. Each slice stays under the cap.

Know this first

Naming files costs thirty seconds a prompt. Hurried prompts are exactly when sprawl strikes.

The habit is yours to keep.

Why BoringPush is the way to do this

Small diffs are safe diffs.

BoringPush keeps each kind of change in one known place. A new entity, a new endpoint, a new screen each have one home.

So a task touches a few files, not fifteen.

Your agent stays inside the lines. You review in minutes.

FAQ

How is ai scope creep fix different from just reviewing carefully?

Review catches sprawl after the tokens burned and the hour passed; caps prevent it before either. Careful review of fifteen files still takes an hour — prevention takes thirty seconds of filenames.

Both, layered: caps bound the work, review verifies within bounds. Prevention first (cheap), review second (focused), archaeology never.

What if the task legitimately needs more than 3 files?

Then say so upfront: "touch these 7 named files" — the rule is explicitness, not the number three. Big refactors get named-file lists plus per-file reasons, reviewed as a plan before code.

Explicit bigness reviews fine; surprise bigness reviews never. Cap scales with declared scope; undeclared scope stays capped.

Should agents be allowed to fix obvious bugs they find nearby?

No — report, don't repair: "noticed X looks off in file Y, continuing with assigned files" keeps the diff clean and the observation alive. Drive-by fixes mix concerns (revert becomes surgery) and skip the spec process that keeps fixes correct. Nearby bugs go in the quarantine file beside good ideas — tracked, scheduled, never smuggled inside other diffs.

How do I handle "helpful" reformatting of whole files?

Forbid it explicitly ("no formatting changes outside touched lines") plus enforce via diff review (reformat-only hunks rejected on sight). Formatters run repo-wide on schedule (monthly, separate commit, human-approved) — never inside feature diffs.

Formatting mixed into diffs doubles review load and hides real changes in whitespace. Separate lanes, always.

Do file caps slow down genuinely large features?

Large features split into capped slices (the slicing post's technique): schema slice, provider slice, route slice, UI slice — each ≤3 files, each reviewable, sequenced by dependency. Slices preserve the cap's protection at any feature size.

Bigness decomposes; sprawl doesn't. Slice large work, cap every slice, ship the sequence.

When should the quarantine list be reviewed and by whom?

Monthly, ten minutes, by whoever reviews agent PRs (usually you): promote 1–2 items with real value, schedule deliberately, delete the rest without guilt. Stale quarantine (six months unreviewed) becomes a second backlog — prune ruthlessly.

Ideas are cheap; scheduled ideas are roadmap. The list serves decisions, not storage.

Keep reading

• My Agent Built the Wrong Thing Perfectly — the spec failure sprawl rides with
• OpenCode SaaS Starter: Stop the Every-Session Redesign — the file holding these caps
• 30 Calls for a 3-Call Task: Stop Agent Token Loops — the other machine-speed waste class