Your Agent Will Refactor a Working Function and Quietly Drop the Edge Case

A 40-line helper function that has been in production since 2022 was handed to an agent and asked to be cleaned up. Thirty seconds later, the agent returned a 14-line version, which was well-named, flat, and free of nested conditionals. The existing tests passed and the refactored code merged cleanly into the main branch. However, six weeks later, a customer on a legacy plan encountered a path that hadn't been exercised since the migration, which caused the function to return null instead of a degraded-but-valid response.

The original author left a comment explaining the situation, but the agent removed it along with the branch and the associated test, as no reference to it existed in the current codebase. The reasoning behind this lies in the agent's optimization for the existing code, without considering other factors such as which callers are on incompatible client versions, edge cases that were a temporary fix, or input formats still being produced by infrequent batch jobs.

To prevent this from happening, the writer suggests two things: first, requesting a list of deleted branches and their reasons in the same diff, and second, writing a characterization test for the current behavior before refactoring. The second point is especially crucial, as people often assume the existing test suite covers all behavior, but it usually only covers the paths someone remembered to test.

The writer drew the line recently on a similar situation where an agent simplified a response schema by making a nullable field required, based on the three tenants onboarded in 2025, but neglected to check for the two from 2023 that had since been stopped asking about. The solution was to keep the contract as the source of truth and diff it against the live response before trusting any refactors.

The key takeaway is that a refactor claim must be checked against something that remembers the messy code's original purpose and defense.