I asked an agent to fix a null-handling bug in one 900-line file. It came back in four minutes with a 12-line change to the function and a green test. The PR it opened touched 412 lines in that same file.

The null fix was buried in the middle. The other 400 lines were reformatting: double quotes to single, trailing commas added, indentation re-indented, a few blank lines collapsed. The real change — the one a reviewer needs to reason about — was one of twelve diff chunks, and by the time you scroll through eleven whitespace chunks it is gone from your attention.

This is not a cosmetic annoyance. It is how regressions hide.

Why the reformat happens automatically

Most agents run the project's formatter after they edit. That is usually correct, but it assumes the file was already formatted. When it was not — legacy code, mixed quotes, a team that has not adopted a linter — the formatter turns a surgical edit into a full-file rewrite. The agent does not choose to bury the bug; it just wants a clean tree.

Worse, the formatter is deterministic, so the noise is uniform across every file the agent touches. After a few such PRs, reviewers stop reading that file's diff at all. That is the moment the next bug ships.

The fix that actually sticks

Three cheap rules cut this down without fighting the formatter.

Tell the agent to leave formatting to the formatter, but don't let it run. Add an explicit instruction: make the behavioral change only. If the file is not formatted, that is a separate, standalone PR — one that touches nothing but whitespace and needs no review beyond "yes, the formatter did this."

Split the diff before you ask for review. A one-function fix should be a one-function diff. If the agent reports a 400-line change for a 12-line problem, that is the signal to reject and re-ask, not to skim and approve.

Look at the diff by ignoring whitespace. Every review tool has a "hide whitespace" toggle. Open it first. If the real change disappears, the PR is not reviewable as written.

The part nobody budgets for

The expensive cost is not the reformatting itself. It is that you now cannot trust the size of a diff. A 12-line bug fix and a 400-line reformat look like the same pull request to the merge queue, the CI report, and the changelog. The reviewer spends the mental energy of a big review on a small change, or worse, spends none.

The agent was doing the reasonable thing. The failure was that nobody separated "the fix" from "the housekeeping." Treat formatting as its own commit, and the actual change becomes visible again.

What about you — do you let your agent format the file it edits, or do you keep the fix and the housekeeping in separate changes?