# Stop AI Rewriting Files You Never Touched

> One prompt, fifteen files changed: scope creep is the default, not the exception. File-count caps plus diff review end it. Inside.

Source: https://boringpush.com/blog/ai-scope-creep-refactors-everything-fix

## 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

| Task: a retry button | Scoped, 3 files | Sprawl, 15 files |
|---|---|---|
| Review time | Short | Long |
| Breakage | None | A renamed export |
| Undo | One clean revert | Surgery |
| Dependencies | Untouched | Two unasked upgrades |
| Trust afterward | Intact | "What else changed?" |

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](/blog/cursor-built-wrong-thing-cleanly-fix) — the spec failure sprawl rides with
- [OpenCode SaaS Starter: Stop the Every-Session Redesign](/blog/opencode-saas-starter) — the file holding these caps
- [30 Calls for a 3-Call Task: Stop Agent Token Loops](/blog/ai-agents-token-waste-loops-fix) — the other machine-speed waste class