Anyone who has reviewed a coding agent's pull request has felt this without a word for it. The fix works, the tests pass, and the diff is bigger than it needed to be. Researchers now have a name for the leftovers, CodeSlop, "the residual and functionally unnecessary edits commonly seen in AI-generated code." Their example is a real Linux kernel bug fix where an agent changed 21 lines, but only 3 actually mattered. The rest were debris from earlier, abandoned attempts the agent never bothered removing once something worked.
This comes from how agents solve problems, not from sloppiness in the model. An agent doesn't write a clean final patch in one pass. It tries something, checks if it worked, backs out, tries again, and keeps whatever was in place once the tests finally passed. At that point every edit along the way looks equally necessary, because none of them failed.
"Once a patch passes its tests, both the essential changes and the residual search artifacts appear equally valid, making them difficult to distinguish from the final patch alone."
TRIM examines an agent's whole trial-and-error history instead of just the final diff, stripping out entire abandoned attempts before it looks at individual lines. Tested on thousands of real bug fixes, it cut this junk by up to a third without breaking the fix it was cleaning up, and for one of the four agent systems tested, the cleaned-up patch matched the human-written fix even more often than the untouched original did. Against the standard technique for shrinking this kind of file, it removed about the same amount of junk in roughly half as many test runs, and was far more predictable about it, never needing more than 16 runs, where the older method sometimes needed 43, each one costing about 30 minutes.
Simply asking an agent to clean up its own patch, with no dedicated process behind it, turned out to be unreliable, as the "cleaned" version was sometimes larger than the original, or broken outright, in a meaningful share of attempts.
"Our results suggest that Patch Minimization is fundamentally a search problem rather than a generation problem."
A shrinking diff is not proof that an agent cleaned up after itself. The safer default is to assume the opposite until a team has checked. It also reframes what code review actually verifies. Passing tests confirms the patch works, not that it's the smallest patch that works, so an agent's PR is often search history and real decision mixed together with no visible seam. That has a knock-on effect on any dashboard tracking "lines changed" as a proxy for how risky or reviewable a change is. A shorter diff that came from an automated cleanup pass means less to read, not necessarily less that was actually decided, so the number is a weaker signal than it looks.
Any vendor claiming their agent "writes clean, minimal patches" is making a claim this paper gives reason to doubt by default. The trustworthy version is "we run a separate cleanup pass afterward," a checkable process, not a property of the model. The same logic applies to asking an agent, mid-review, to shrink its own diff, since this paper found that unreliable enough that the right response is to re-run the tests, not take the smaller diff on faith. And the scope is narrow, as this covers bug-fix-and-test workflows, not agents building new features, where extra scaffolding might be a real design choice rather than debris to prune.
Sources
- Mathai, A., Iyer, S., Nogikh, A. et al., "TRIM: Reducing AI-Generated CodeSlop via Agent Trajectory Minimization" — https://arxiv.org/abs/2607.18161