Skip to main content

Command Palette

Search for a command to run...

Your Agent's PR Grows Three 'While I Was in Here' Cleanups, and Now You Can't Review It

You asked for one endpoint. The diff has the endpoint, a renamed variable across fourteen files, a rewritten error helper, and a formatting pass. You can't tell which hunk is the feature and which is a side quest. Here's the habit that fixed it.

Updated
•3 min read•View as Markdown

You ask your agent to add one endpoint.

You come back to a diff that contains:

  • the endpoint you asked for,
  • a renamed variable across fourteen files,
  • a rewritten error helper because the old one "looked inconsistent,"
  • and a formatting pass that touched forty lines you never mentioned.

The tests pass. CI is green. And now you are stuck: you cannot tell which hunk implements the feature and which hunk is a side quest the agent took because it had the whole repo in context.

The agent optimizes the whole repo, not your task

When an agent has your codebase open, "clean up while you're here" is not a boundary it respects. It sees a local inconsistency, and fixing it costs it one extra tool call. The marginal cost to the agent is near zero. The marginal cost to you, at review time, is not.

Every drive-by cleanup multiplies the surface area you have to verify. A rename that "should be safe" can still break a string reference, a log parser, or a test snapshot. A formatting pass can bury the one real line that actually matters. By the time you finish reviewing, you're not reviewing the feature anymore — you're auditing the agent's taste.

The instruction that actually helps

The fix that stuck for me was not a better prompt. It was a hard boundary in the task itself:

Make the smallest diff that satisfies the request. Do not rename, refactor, reformat, or touch files that are not required for this change. If you notice something that should be cleaned up, list it in the PR description as a follow-up and stop.

Two things change.

First, the agent stops treating the whole repo as the scope. Second, the side quests get surfaced as a list instead of silently merged. You can look at that list and say "yes, do the rename as its own PR" or "leave it." Either way, the feature diff stays small enough to read in one sitting.

Separate the cleanups on purpose

The follow-up list is the part people skip. It feels slower — now you're opening a second PR for the rename. But that rename, done as its own diff, is reviewable in ninety seconds. Bundled into the feature PR, it is the thing you will half-read and regret six weeks later.

Small diffs are not an aesthetic preference. They are the difference between reviewing a change and auditing a tour of the codebase.

When you hand an agent a task, you are not just handing it a feature. You are handing it permission to touch everything it can see. Draw the boundary up front, list the drive-bys instead of merging them, and the review gets fast again.

What's the most aggressive "while I was in here" cleanup an agent has ever folded into your diff?

N
netproxy4m ago

The boundary that worked for me: tell the agent to put anything it noticed but shouldn't touch into a follow-up list at the end. Keeps the diff reviewable, and I still get the benefit of its observations.

More from this blog

P

Powerduck Blogs

142 posts

Essays on local-first API tooling, OpenAPI contracts, MCP, and agentic coding failures. We build Powerduck, a local-first OpenAPI studio where the spec stays the source of truth. Topics: AI code review trust, testing AI-generated code, context engineering, and what actually breaks when AI writes your code.