Your Agent Fixed the Bug, Then Tidied Up. Google's Review Guide Says That's Two Changes

• Book: AI Agents Pocket Guide
• The series: Pocket Guides for Developers — 8 short books on agents, RAG, prompts, observability, events, databases and system design — the whole series
• My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
• Me: xgabriel.com | GitHub

You asked for one line. The bug report says calculateTotal() crashes on an empty order, and the fix is a guard clause at the top of the function.

The branch the agent hands back touches seven files. The guard clause is in there. So is amt renamed to amount at every call site, the imports in cart.ts sorted, and the discount logic next door pulled out into a helper "for readability." The tests pass. The summary says done.

Now you're the reviewer. Which of those lines is the fix?

My take: don't review that branch. Reject it and have the agent split it. Google's public code review guide already has the rule, and agents make following it cheaper than it has ever been.

The rule is already written down

Google publishes its code review practices as eng-practices. The page on small changes (Google calls a change a CL, for changelist) says the right size is "one self-contained change", one that "makes a minimal change that addresses just one thing."

Then the part that matters here: "It's usually best to do refactorings in a separate CL from feature changes or bug fixes." The example in the guide could have been written about agents: "moving and renaming a class should be in a different CL from fixing a bug in that class."

The reason it gives is the reviewer: "It is much easier for reviewers to understand the changes introduced by each CL when they are separate." Among the benefits of small changes, the same page lists that they get reviewed more thoroughly, are less likely to introduce bugs and are simpler to roll back. That last one bites hardest with a mixed branch. If the guard clause turns out to be wrong and you revert it, the rename and the new helper go with it.

The guide also says reviewers "have discretion to reject your change outright for the sole reason of it being too large." A mixed branch doesn't need to be large to earn the same answer.

To be fair to the guide, it has an exception: "Small cleanups such as fixing a local variable name can be included inside of a feature change or bug fix CL, though." Hold that thought. I think it stops applying to agents.

Agents tidy up, and their vendors write rules against it

You don't have to take this from me. The vendors deal with it in their own docs and prompts.

Anthropic's prompting best practices has a section called "Overeagerness". It says Claude Opus 4.5 and Claude Opus 4.6 "have a tendency to overengineer by creating extra files, adding unnecessary abstractions, or building in flexibility that wasn't requested." The sample prompt it offers against that includes one line worth pinning to your monitor: "A bug fix doesn't need surrounding code cleaned up."

OpenAI's open-source Codex CLI carries the same rule in its system prompt. The GPT-5.2 prompt in the repository says: "Do not attempt to fix unrelated bugs or broken tests. It is not your responsibility to fix them." It adds that "Changes should be minimal and focused on the task," and lets the agent mention unrelated problems in its final message instead.

So both vendors' own guidance lines up with Google's. That still doesn't make the rule hold every time. Claude Code's memory docs say Claude treats your instruction files "as context, not enforced configuration." The prompt lowers the odds of a tidy-up, and the review gate is what catches the rest.

Reject it. Don't review it.

When an agent branch mixes the fix with cleanup, send it back before you read it line by line.

Reviewing it spends the most expensive thing in the loop, which is your attention, on sorting intent. Every renamed variable is a line you have to confirm changes nothing. Every moved block is a hunk you have to match in your head against where it came from. You end up doing the agent's bookkeeping.

Splitting it costs almost nothing. For a human, Google's exception makes sense: pulling a one-line rename into its own change is real work, with a separate branch, description and wait for review. For an agent, it's one more prompt. When the split is that cheap, the reason for the exception mostly goes away, so I'd hold agent branches to the strict version: the fix, a test for the fix, and nothing else.

That's my reading, not Google's. The guide leaves the line between a small cleanup and a refactoring to the developer and the reviewer.

A rejection should be quick, so make the first check mechanical with git diff:

# which files did the branch touch?
git diff --stat main...HEAD

# hide whitespace-only edits, then read
git diff -w main...HEAD

The three dots compare against the point where the branch left main, so work that landed on main since then stays out of the way. If --stat lists files the bug never touched, you have your answer before you've read a single hunk. -w ignores whitespace when comparing lines, so indentation and spacing changes drop out and the real edits stand out.

Make the agent write a list instead of a diff

The agent noticing that the discount function is a mess is useful. Fixing it in the same branch is the problem. Keep the noticing and change where it goes.

Put this in your AGENTS.md, the instruction file that Codex and many other agents read (agents.md), or in CLAUDE.md. Claude Code reads AGENTS.md too when the repository has no CLAUDE.md, according to the same memory docs:

## Scope
- Change only what the task asks for, plus a test for it.
- A bug fix doesn't get surrounding cleanup.
- Spotted something else worth fixing? Don't fix it.
  Add it under "Out of scope" in your final message:
  file, line, and one sentence on why it matters.

The first two bullets echo Anthropic's sample prompt. The last one takes the Codex prompt's idea of mentioning unrelated problems in the final message and turns it into something you can act on.

The list is the point. Each item becomes a task you can review and revert by itself. The fix can ship today; whether the rename ships at all is a separate decision.

If a branch already arrived mixed, you can still take it apart after the fact. I walked through that in splitting a coding agent's giant commit with git history split. Prevention is cheaper than surgery, though.

One tidy-up, one task, in Hermes

I build Hermes IDE, so weigh this section with that in mind. Everything here works with plain git too: one git worktree per task, made by hand. Hermes makes the loop shorter.

When the agent's final message lists three out-of-scope items, press ⌘N (Ctrl+Shift+N on Windows and Linux) once per item. Each task starts on a hermes/<name> branch in a fresh worktree, with the item as the agent's first prompt. The rename doesn't have to go to the agent that wrote the fix. Hermes runs Claude Code, Codex and other command-line agents side by side, each in a separate terminal with its own sign-in.

The Review Desk's Worktrees tab: one Hermes worktree each for orders-api, web-app and orders-types, with each worktree's hermes/ branch, task, age and disk size, and the free disk space.

Review then happens per task. The Review Desk (⌘G, or Ctrl+Shift+G) shows a task's changes by turn or by file, with risk flags. Every agent turn is saved, so you can diff or restore any single turn, with undo. If the agent made the fix in its first turn and tidied up in its second, you can restore your files to the point after the first turn and keep the fix. If both happened in the same turn, leave a line comment on the renamed line. It goes back to the agent that wrote it: revert this, and put it on the list.

The Review Desk (⌘G) in By turn view for a Claude Code task in orders-api: two turns listed, turn 1's diff of src/db.ts adding a refunded status, the changed-files list, and a commit message drafted from the turns.

Then Land commits, opens a pull request or merges locally in one step, into the branch the task started from, and it can be undone. Small tasks are what make that undo worth having: undoing a landed tidy-up doesn't take the fix with it. Hermes cleans up undo data for landed tasks after 14 days, per the 2.2.9 release notes.

What Hermes won't do is read a diff and tell you it mixes two intents. That call is still yours, and the --stat check above still comes first.

Where the rule bends

Google's exception exists for a reason, and a few cases deserve it.

• The name is the bug. If a variable called total actually holds a subtotal and that's why the math is wrong, renaming it is the fix. Keep it in.
• The fix needs a refactor first. Split it in order: the refactor as one change, then the fix on top. The guide expects big work to arrive as "a series of smaller changes," and this is that.
• A formatter rewrites whole files. That noise isn't the agent's choice. Run the formatter across the repository once, as its own change, and the problem stops coming back.

Outside those cases, I'd send it back. Would you bounce an agent's branch over one renamed variable, or is that too strict for your team? Tell me in the comments.

If this was useful

Deciding what an agent is allowed to touch is a guardrail question, and guardrails and autonomy for agents are a core part of the AI Agents Pocket Guide. It's one of 8 short books in Pocket Guides for Developers, covering agents, RAG, prompts, observability, events, databases and system design. If you want one task per branch without the worktree bookkeeping, Hermes IDE is free, source-available under BSL 1.1, runs on macOS, Windows and Linux, and a star on GitHub helps other developers find it. It isn't affiliated with Nous Research, Anthropic, OpenAI or any agent vendor.