{"id":"c3c27d45-10fc-4114-9f44-7181752f3d15","arxiv_id":"2607.18161","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"TRIM uses an AI coding agent's repair trajectory to prune leftover redundant edits, cutting agent patch size by 17.9–32.9% at about half the validation cost of delta debugging.","lead":"This paper defines 'CodeSlop' as the redundant edits AI coding agents leave in their fixes, and introduces TRIM, a post-processing algorithm that prunes those edits by replaying the agent's search trajectory. The main result is a 17.9–32.9% reduction in patch size across four agent scaffolds at roughly half the validation cost of delta debugging.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Headline ΔSlop is computed only on non-trivial patches; including the 140 excluded one-edit repairs drops the reported 17.9–32.9% to roughly 12–22%, overstating the central quantitative claim.","rationale":"The reader's verdict is CONDITIONAL and identifies the TF proxy as the weakest assumption. That is a real concern and the paper's own oracle evaluation partially addresses it (3/330 SWE-Bench regressions, ~1% Live-kBench drop), but it is not the single most load-bearing issue for the headline number. The most load-bearing concern is that the reported 17.9%–32.9% CodeSlop reduction is computed on a filtered subset of repairs, excluding 140 of 433 successful Live-kBench repairs. Because the excluded patches have ΔSlop=0 under TRIM's edit-action granularity, including them changes the headline by a factor of about 1.5×. The paper does disclose the exclusion, but the abstract and conclusion state the filtered numbers without the caveat, so a reader would reasonably infer the reduction applies across successful agent repairs. This is also a measurement-validity issue rather than a mere presentation issue: the excluded 'one-minimal' patches can still contain redundancy within a single atomic edit, and TRIM cannot remove it, so the filtering can overstate both the amount of CodeSlop and TRIM's ability to reduce it. A straightforward recomputation settles the matter. The TF-proxy concern is important but is explicitly acknowledged, partially mitigated by hidden-oracle evaluation, and would likely not change the verdict beyond CONDITIONAL; the subset-exclusion concern is concrete, easily tested, and directly affects the central claim as stated. Therefore I keep the reader's CONDITIONAL verdict, with partial agreement on which assumption is weakest.","tokens_in":18384,"tokens_out":10033,"duration_ms":107290,"concrete_test":"Recompute Table I's ΔSlop over all 433 successful Live-kBench repairs, assigning ΔSlop=0 to the 140 one-edit-action patches (or, better, rerun TRIM with a line-level or character-level edit representation on those patches to allow within-edit removal). If the recomputed range falls materially below 17.9%–32.9% (e.g., below 25% at the top end), the abstract and conclusion must be revised to state that the reduction applies only to non-trivial multi-edit patches. Additionally, manually inspect a sample of the 140 one-edit patches to determine whether they contain removable within-edit redundancy; if they do, the 'trivially one-minimal' exclusion is hiding exactly the CodeSlop TRIM purports to measure.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The abstract and conclusion claim TRIM 'cuts CodeSlop by 17.9%–32.9%', but Table I's ΔSlop is averaged only over the 293 Live-kBench bugs that remain after excluding 140 'trivially one-minimal' repairs (single edit action). Since ΔSlop = (avg(len(AP)-len(MP)) / avg(len(AP))) × 100, including those 140 patches with ΔSlop=0 would reduce the reported range: e.g., CRASHFIXER 32.9% becomes roughly 32.9% × (293/433) ≈ 22.3%, and SWE Agent 17.9% becomes ≈ 12.1%. The unqualified headline therefore overstates the expected reduction on the full population of successful agent repairs by roughly 1.5×. Moreover, a patch with one edit action is not necessarily free of CodeSlop: an atomic edit can modify multiple lines or locations, and TRIM cannot remove redundancy internal to that edit action. Calling such patches 'trivially one-minimal' conflates one removable unit with zero removable redundancy, so the exclusion is not a harmless lower-bound choice. This does not invalidate the algorithm's mechanism, but it directly affects the paper's primary quantitative claim and needs disclosure or redefinition.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper formalizes a notion of CodeSlop as removable functional redundancy in agent-generated patches, defines the Patch Minimization problem (recover the smallest behavior-preserving sub-patch), and proposes TRIM, a hierarchical counterfactual search algorithm that removes edits at sequence, file, and edit-action granularity, accepting a removal only if the task test suite TF still passes and the patch strictly shrinks. The algorithm is evaluated on Live-kBench and SWE-Bench-Verified across four agentic scaffolds against agentic minimization baselines and hunk-level delta debugging. The headline claim is that TRIM cuts CodeSlop by 17.9%–32.9% with negligible regression and at roughly half the validation cost of delta debugging.","tokens_in":18743,"tokens_out":10084,"duration_ms":112163,"significance":"If the evaluation were properly conditioned, this would be a useful post-processing method for coding-agent outputs and a clean formalization of a phenomenon that is increasingly discussed informally. The paper's strengths are its explicit formal definition of CodeSlop, a clear deterministic algorithm (Algorithm 1), the use of hidden oracle tests for evaluation rather than only the agent's own test suite, and an explicit cost model in terms of test-suite executions. The threats-to-validity section is candid about edit-granularity and oracle-imperfection issues. However, the primary quantitative claim is overstated because the reported ΔSlop is computed only on non-trivial patches, and the hidden-oracle filtering is not transparent enough to support the 'negligible regression' claim as stated.","major_comments":[{"comment":"The headline 'cuts CodeSlop by 17.9%–32.9%' is computed only on the 293 Live-kBench bugs that remain after excluding 140 'trivially one-minimal' repairs (single edit action). Since those 140 repairs contribute ΔSlop=0 by construction, the reported range is a conditional average over the non-trivial subset. Including the excluded repairs would lower the aggregate range to roughly 12–22% under the simplest equal-length assumption (e.g., 32.9% × 293/433 ≈ 22.3%; 17.9% × 293/433 ≈ 12.1%). Moreover, a single edit action can modify multiple lines or locations, so 'one removable unit' does not imply 'zero removable redundancy'; redundancy internal to an edit action is invisible to TRIM. The exclusion is therefore not a harmless lower-bound choice. Please report unconditional population-level ΔSlop or clearly label the conditional statistic in the abstract and conclusion, and discuss edit-action","section":"§V-A, Table I, Abstract"},{"comment":"The paper states that evaluation 'additionally requires every minimized patch to satisfy the hidden oracle' and then reports oracle performance changes (e.g., −1.13% for OpenHands in Table II). If the hidden oracle is used as a filter before computing Table I and Table II, the 'negligible regression' claim is not an independent measurement, and the comparison with agentic baselines is asymmetric: agentic failures are counted as no minimization rather than excluded. Please specify exactly which trajectories enter each table, whether the oracle filter is applied before or after computing ΔSlop, and re-run the baseline comparison under the same filtering or report unfiltered numbers.","section":"§VI (RQ1), Tables I–II, §VIII-A"},{"comment":"The formal definition of CodeSlop is behavioral ('can be removed without changing behavior'), but every counterfactual is accepted solely on the task test suite TF. The paper's own oracle evaluation quantifies the resulting risk: 3/330 SWE-Bench regressions and up to ~1% Live-kBench drop. This means the reported ΔSlop measures reduction in TF-equivalent redundancy, not CodeSlop as defined. The abstract's 'negligible performance regression' should be bounded by these measured oracle regressions, and the ideal/operational distinction should be stated in the conclusion, not only in the threats-to-validity section.","section":"§III-B, §IV-C (Alg. 1, Line 11), §VIII-A"}],"minor_comments":[{"comment":"Figure 3 contains an unfinished placeholder 'Shobhi, please add a traj here' inside the diagram. This should be replaced with an actual trajectory snippet before submission.","section":"Figure 3"},{"comment":"References [13] and [22] appear to refer to the same SlopCodeBench paper with inconsistent author lists. Please consolidate and verify the citation.","section":"References [13], [22]"},{"comment":"The condition 'len(S\\u_j) < len(S)' uses S as a working set of trajectory units, but the paper defines len() on applied patches. Clarify that lengths are computed on apply(...), or introduce notation for the applied patch.","section":"Algorithm 1, Line 11"},{"comment":"The reverse traversal order is unmotivated. A one-sentence explanation of why units are considered in reverse trajectory order would help.","section":"Algorithm 1"},{"comment":"The abstract says 'we show that the cause lies in the agent's own search process.' The paper provides correlational trajectory evidence and motivating examples, not a causal proof. Soften this claim.","section":"Abstract / §I"},{"comment":"The table header '327oracle-preserved patches' is missing a space. Also, the fact that the table reports statistics only on the 327 oracle-preserved patches should be stated in the main text, not only in the table note.","section":"Table IV"},{"comment":"The conclusion says TRIM 'minimizes edit-actions in agent trajectories,' but the algorithm minimizes the final patch using the trajectory as a search space. Align the wording with the problem formulation in §III.","section":"Conclusion"}],"recommendation":"major_revision","confidential_remarks":"The core algorithm is sensible and the evaluation is mostly careful, but the headline quantitative claim is inflated by the exclusion of trivially one-minimal patches, and the hidden-oracle filtering is not sufficiently transparent. These are fixable within the manuscript's scope. The self-citation load is noticeable, but many are benchmark artifacts used legitimately. I would support acceptance after the conditional-statistic issue is resolved and the oracle-filtering pipeline is clarified."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Two things to know before you read it. The central mechanism is sound: TRIM formalizes slop as removable functional redundancy, then shrinks agent patches by hierarchical counterfactual search over the repair trajectory, and that is a real idea with a careful evaluation. But the headline 'cuts CodeSlop by 17.9%–32.9%' is computed only over non-trivial repairs; the full-population number is materially lower, so read the abstract with that caveat.\n\nWhat's actually new and good: the behavioral definition of CodeSlop is a genuine departure from static verbosity metrics. The algorithm itself is simple and plausible: edit-sequence → file → edit-action removal, accepting a deletion only if the test suite still passes and the patch shrinks. The evaluation is more careful than most in this area. They use hidden oracle tests, multiple scaffolds, cost in test-suite executions rather than wall-clock, and an explicit comparison against hunk-level delta debugging. The headline result — matching DD-Hunk's reduction at roughly half the validation cost — is useful if it reproduces. The oracle regressions are rare (3/330 on SWE-Bench, up to ~1% on Live-kBench), which is reassuring.\n\nNow the soft spots, in proportion. The biggest is the denominator. Of 433 successful Live-kBench repairs, 140 are single-edit patches and are excluded from Table I. The reported 17.9–32.9% is averaged over the remaining 293. That's not a harmless lower-bound choice: a single edit action can still contain redundancy inside it, and TRIM's smallest removable unit is the edit action, so calling those patches 'trivially one-minimal' conflates one removable unit with zero removable redundancy. Including them at ΔSlop=0 would drop the headline range to roughly 12–22%. The paper should disclose this or redefine the metric.\n\nSecond, HDD — the closest hierarchical delta-debugging baseline — is cited but never run. The comparison is against DD-Hunk, which flattens the patch into hunks, so the claim that trajectory structure is what saves cost is plausible but not directly supported by a hierarchical baseline.\n\nThird, no code, data, or trajectories are released. Given the author-built benchmarks (Live-kBench, KGym, CrashFixer), that's a real limitation for a post-processing tool that should be easy to ship. Minor: Figure 3 still contains a 'Shobhi, please add a traj here' placeholder.\n\nWho is this for: anyone working on agent reliability, patch review, or security patching. It deserves a serious referee; the issues are fixable with better reporting, an HDD baseline, and artifact release. I'd engage with it.","headline":"Solid trajectory-guided minimization idea with a careful evaluation, but the headline reduction numbers are inflated by excluding already-minimal patches.","tokens_in":19166,"tokens_out":3383,"would_cite":true,"duration_ms":31409,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper argues that bloat in AI-generated patches is leftover search debris that can be cut by up to a third via trajectory-guided trimming, at roughly half the validation cost of delta debugging.","keywords":["AI coding agents","CodeSlop","patch minimization","trajectory minimization","counterfactual search","program repair","delta debugging","redundant edits"],"falsifier":"Take a set of agent-repaired bugs with strong held-out oracles, run TRIM using only the agent's own tests, then run the minimized patch against the held-out oracle; if a meaningful fraction of minimized patches fail hidden tests that the original patch passed, the test-suite proxy is insufficient.","tokens_in":18350,"feed_emoji":"✂️","tokens_out":5794,"duration_ms":54126,"temperature":0.7,"pith_summary":"Coding agents routinely leave speculative edits, abandoned hypotheses, and temporary changes in the patches they submit; the paper names this residue CodeSlop and defines it behaviorally, as the part of a patch that can be deleted while the patch still passes its tests. The paper's central claim is that this residue can be identified and removed by minimizing the agent's repair trajectory rather than the final patch, using a coarse-to-fine counterfactual search that asks, for each group of edits, whether the patch still works without them. Across four agent scaffolds and two repair benchmarks, this procedure cuts CodeSlop by 17.9%–32.9% with negligible regression in test-visible correctness, and does so at roughly half the validation cost of a hunk-level delta-debugging baseline. If this holds, agent patches that already pass tests can be systematically shrunk toward the minimal human fix, reducing review burden and slowing the accumulation of redundant code in AI-maintained codebases.","feed_headline":"TRIM cuts AI patch bloat by up to 33 percent","feed_subtitle":"Removing an agent's leftover search edits yields smaller, reviewable patches with no test-visible behavior change.","key_machinery":"The load-bearing object is the repair trajectory — the ordered list of edit actions and test-feedback requests the agent produced before finding a passing patch — reconstructed as a reduced trajectory of edit sequences separated by feedback requests. TRIM uses this structure as a hierarchical search space: it first asks whether an entire edit sequence can be cut, then whether all edits to a file can be cut, then whether each individual edit action can be cut, revalidating against the task-specific test suite after every candidate removal. The trajectory matters because edits made in the same exploratory cycle tend to depend on each other; removing them as a unit prunes the exponential search","core_discovery":"The paper's discovery is that most of the extra bulk in agent-generated patches is not stylistic verbosity but removable functional redundancy: edits that survive into the final patch solely because the agent stops editing once tests pass. It formalizes the goal as finding the minimal behavior-preserving patch derivable from the agent's patch, and shows that the agent's own trajectory supplies the dependency structure needed to find it efficiently. The algorithm TRIM replays the trajectory, groups surviving edits by the agent's edit-test cycles, and then runs three passes — dropping whole edit sequences, then whole files, then individual edit actions — accepting a deletion only when the rema","pith_inferences":["TRIM's deletions are only as safe as the task-specific test suite it validates against; the paper's own hidden-oracle results (3/330 regressions on one repository benchmark) bound this risk, so in domains with weak tests the minimized patch should still be reviewed before merge.","Because the temporal edit-test structure is the core signal, any coding scaffold that logs its editing steps in order could adopt TRIM without modifying the underlying agent, making the method a general post-processing layer rather than a per-agent fix.","Applied continuously in CI or before patch submission, TRIM could remove an agent's exploratory debris before it accumulates, which the paper identifies as the long-term hazard of agent-maintained codebases.","Behavioral CodeSlop is invisible to static linters, so periodic trajectory-replay cleanup would be the practical way to detect it; no static metric can distinguish a removable clean edit from a necessary one."],"forward_implications":["Agent patches can be shrunk by 17.9%–32.9% on security-critical repair tasks with negligible test-visible regression, and the effect carries over to repository-level repair, where the paper reports about a fifth of the patch removed by its conservative measure.","The hierarchical search is roughly twice as cheap as hunk-level delta debugging and has a much tighter worst-case validation count, so it is practical when test runs are expensive.","Minimization sometimes lands exactly on the developer-written fix, which would turn patch review into a near no-op in those cases.","Prompting the agent to minimize its own patch is unreliable, with 3.8%–44.9% of attempts failing or inflating the patch, so a deterministic trajectory search is the dependable route.","Dropping the one-minimality guarantee costs almost nothing in reduction quality while cutting validation cost, giving users a budget knob between a guarantee and efficiency."],"fun_headline_variants":["AI patch bloat cut 33% via trajectory minimization","TRIM minimizes agent paths to shrink AI patches by up to 33%","Trajectory trimming removes AI's leftover edits, cutting patch size by up to a third","CodeSlop in AI patches drops 33% with TRIM's trajectory pruning","TRIM's trajectory minimization cuts patch bloat by up to a third"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"TRIM accepts the task-specific test suite as the definition of 'behavior preserved,' so if that suite under-specifies the task, a removal that deletes a functionally necessary edit can still pass validation and shrink the patch.","fun_headline_variants_meta":{"raw":{"variants":["AI patch bloat cut 33% via trajectory minimization","TRIM minimizes agent paths to shrink AI patches by up to 33%","Trajectory trimming removes AI's leftover edits, cutting patch size by up to a third","CodeSlop in AI patches drops 33% with TRIM's trajectory pruning","TRIM's trajectory minimization cuts patch bloat by up to a third"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001425,"raw_usage":{"total_tokens":5608,"prompt_tokens":789,"completion_tokens":4819,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":533,"completion_tokens_details":{"reasoning_tokens":4729}},"tokens_in":533,"tokens_out":4819,"duration_ms":33429,"temperature":1.0,"reasoning_tokens":4729,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-01T15:47:29.496499+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Take a set of agent-repaired bugs with strong held-out oracles, run TRIM using only the agent's own tests, then run the minimized patch against the held-out oracle; if a meaningful fraction of minimized patches fail hidden tests that the original patch passed, the test-suite proxy is insufficient.","supporting_citations":[],"review_version":1}