Skimming this morning's arxiv list, one paper gave a name to something every one of us has stared at in an agent's pull request: the diff that's twice as long as it needs to be — a helper the agent added and then stopped using, a guard it wrote for a hypothesis it abandoned, a temporary change it never cleaned up. A Google/Columbia team calls this CodeSlop, and their key move is arguing it isn't a generation-style problem you can prompt away. It's a fossil record of the agent's search. The thesis I'm taking from it: the cheapest place to clean up agent code is the trajectory, not the diff.
What it does#
TRIM starts from a measured observation — agent-generated code is consistently larger and more verbose than the equivalent human implementation — and pins the cause on the agent's own iterate-to-green loop. While searching for a passing solution, the agent accumulates speculative edits, abandoned hypotheses, and temporary changes that persist into the final patch. Harmless for one patch; corrosive across a codebase, which “accumulates redundancy faster than it can be cleaned up” as agents take over ever-larger slices of it. The authors formalize this residue as CodeSlop — functionally unnecessary edits — and introduce TRIM (Trajectory-guided Redundancy Identification and Minimization) to remove it.
The clever part is the indirection. Instead of trying to identify redundant code directly — which would mean reasoning about what's dead — TRIM minimizes the trajectory. It reconstructs the sequence of edits the agent made between each round of test feedback, then runs a coarse-to-fine counterfactual search: can I drop this entire edit batch? this file? this single atomic edit? A removal is accepted only if the patch still passes the task test suite and got smaller, processed in reverse temporal order. This isn't a linter or a cleanliness classifier bolted onto the output — it's a replay-and-prune over the agent's actual search path, which is what makes it both effective and cheap.
The key result#
The headline: TRIM cuts CodeSlop by 17.9%–32.9% across four agentic scaffolds, with negligible performance regression. On Live-kBench (534 Linux kernel vulnerabilities, 293 non-trivial repairs) the per-scaffold reductions were CrashFixer 32.9%, OpenHands 26.6%, mini-SWE 26%, and SWE-agent 17.9%. On SWE-Bench-Verified it stripped 20.0% of slop while preserving oracle correctness on 327 of 330 patches (99.1%) — and 18 minimized patches collapsed all the way down to the exact developer-written solution. Just as important for anyone who'd run this in a loop: it's efficient. TRIM used roughly half the validation cost of Delta Debugging (~2,600 vs ~5,200 test executions; 16 vs 43 max validations per bug) for a statistically equivalent reduction (32.9% vs 31.5%, p=0.50).
Why it matters#
The reframe is the real contribution. We've mostly been treating agent verbosity as a prompt or style problem — tell it to be concise, add a cleanliness rubric, pick a tidier model. This paper says the bloat is structural: it's the exhaust of the search, and no amount of generation-time steering removes an edit the agent genuinely needed during solving but not after. That's why the trajectory is the right unit of analysis. It also explains why blind Delta Debugging is wasteful — it bisects hunks with no idea which edits belong together, when the agent already told you: they're the ones between two test-feedback boundaries. TRIM exploits that free segmentation and gets ~2x cheaper for it.
For a builder, this slots cleanly into the harness as a new step — a minimize-before-commit pass that replays the trajectory and prunes before the agent opens a PR. It's a natural sub-agent: hand a dedicated “minimizer” the editor's trajectory plus the test suite, get back the smallest patch that still passes. That job is validatable, model-optional (it's counterfactual test runs, not a judgment call), and it composes. It also lands squarely in a thread I've been tracking — cleanliness is a cost lever not a capability lever, the trajectory is auditable evidence rather than exhaust, a good trajectory is an asset with a depreciation schedule. TRIM is the operational counterpart to all three: don't just diagnose the messy trajectory, replay it to strip what wasn't load-bearing. The concrete thing I'd change tomorrow: stop trusting the final diff as minimal, and stop paying for full delta-debugging when the agent handed me the segmentation for free.
The caveats#
The oracle is the test suite. TRIM can only remove what the tests don't cover — so a genuinely-needed-but-untested edit can be silently pruned away. Slop reduction is bounded by test strength, the same weak-oracle caveat that haunts every execution-graded result.
Atomic edits are the floor. Redundancy inside a single edit is invisible to the method; it minimizes across edits, not within them.
Successful repairs only. The evaluation covers patches that already passed — it says nothing about failed trajectories, which are probably where the worst slop actually lives.
Domain scope. Kernel and repo-level repair anchored on failing tests; greenfield app-building with no test to anchor on may not have the same exploitable trajectory structure. And “negligible” regression still meant a few real regressions (3/330 on SWE-bench; OpenHands -1.13% oracle).
The takeaway#
What I'm filing away: agent code bloat is a search artifact, and the trajectory is both the diagnosis and the cure. If I'm shipping agent patches at any volume, a trajectory-guided minimize pass before the PR is cheap insurance against codebase drift — and it's meaningfully cheaper than the blind-bisection version precisely because the agent already segmented its own work. What I'm doing differently after reading this: treating “is this diff minimal?” as a question the harness answers by replay, not one I hope the model got right.