The Agent Re-formatted the Whole File and Buried Its Own Change

A reporter delves into the issue of automated code formatting and its impact on code review. An agent was tasked to resolve a null-handling bug in a 900-line file. The agent's response was a 12-line change to the function and a green test, but the 400 lines of reformatting occurred as well. The true change was buried among twelve diff chunks, making it difficult for reviewers to focus on the important alteration.

The agent's blanket reformatting approach isn't ideal. Most agents run the project's formatter after edits, assuming the file was already formatted. When it wasn't, such as with legacy code or mixed quotes, the formatter turned a minor edit into a full-file rewrite. The agent didn't intentionally hide the bug; it simply aimed for a clean tree. Over time, reviewers started ignoring the file's diff entirely due to the uniform noise caused by the formatter.

To mitigate this, three simple rules can be followed. Firstly, instruct the agent to leave formatting to the formatter but not to run it. Secondly, explicitly request a behavioral change only, and if the file isn't formatted, create a separate PR touching only whitespace. Lastly, split the diff before requesting review, ensuring a one-function fix results in a one-function diff.

The real cost isn't the reformatting itself, but the loss of trust in diff size. A 12-line bug fix and a 400-line reformat appear as the same pull request to the merge queue, CI report, and changelog. Reviewers spend as much mental energy on a small change as they would on a large one, or worse, none at all. The agent was acting reasonably, but the failure was in not separating the fix from the housekeeping.

By treating formatting as its own commit, the actual change becomes visible again. The reporter questions whether to let agents format edited files or keep fixes and housekeeping separate.