Pith. sign in

REVIEW 3 major objections 7 minor 37 references

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.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-08-01 15:47 UTC pith:OQVMDIU3

load-bearing objection Solid trajectory-guided minimization idea with a careful evaluation, but the headline reduction numbers are inflated by excluding already-minimal patches. the 3 major comments →

arxiv 2607.18161 v1 pith:OQVMDIU3 submitted 2026-07-20 cs.SE cs.AIcs.OS

TRIM: Reducing AI-Generated CodeSlop via Agent Trajectory Minimization

Alex Mathai , Shobini Iyer , Aleksandr Nogikh , Petros Maniatis , Franjo Ivancic , Junfeng Yang , Baishakhi Ray This is my paper
classification cs.SE cs.AIcs.OS
keywords AI coding agentsCodeSloppatch minimizationtrajectory minimizationcounterfactual searchprogram repairdelta debuggingredundant edits
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

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.

Core claim

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

What carries the argument

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

Load-bearing premise

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.

What would settle it

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.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • 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.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • 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.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

3 major / 7 minor

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.

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 (3)
  1. [§V-A, Table I, Abstract] 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
  2. [§VI (RQ1), Tables I–II, §VIII-A] 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.
  3. [§III-B, §IV-C (Alg. 1, Line 11), §VIII-A] 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.
minor comments (7)
  1. [Figure 3] 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.
  2. [References [13], [22]] References [13] and [22] appear to refer to the same SlopCodeBench paper with inconsistent author lists. Please consolidate and verify the citation.
  3. [Algorithm 1, Line 11] 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.
  4. [Algorithm 1] The reverse traversal order is unmotivated. A one-sentence explanation of why units are considered in reverse trajectory order would help.
  5. [Abstract / §I] 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.
  6. [Table IV] 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.
  7. [Conclusion] 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.

Circularity Check

0 steps flagged

No significant circularity: TRIM is a test-driven search with no fitted constants or definitionally forced outputs.

full rationale

TRIM's derivation is self-contained. CodeSlop is defined via the ideal minimal behavior-preserving patch AP* (Definitions 1-2), not via any quantity TRIM computes; Algorithm 1's acceptance rule (`if apply(S\u_j) passes TF and len(S\u_j) < len(S)`) is an empirical counterfactual search with no fitted parameters. The reported 17.9%-32.9% Delta Slop is the measured post-hoc length reduction on Live-kBench and SWE-Bench, not an input to the algorithm; it could have been zero if agent patches were already minimal. The author-overlap citations (Live-kBench [20], KGym [23], CrashFixer [24]) provide benchmarks and scaffolds with independent test artifacts, and the core minimization result also replicates on the external SWE-Bench-Verified benchmark; no uniqueness theorem or ansatz is imported as load-bearing. The disclosed limitations (TF as a proxy for correctness, edit-action granularity, exclusion of 140 one-edit patches) affect the strength and interpretation of the headline quantitative claim but do not make the derivation reduce to its own inputs.

Axiom & Free-Parameter Ledger

0 free parameters · 4 axioms · 0 invented entities

No numeric free parameters are fitted; TRIM's only tunable is the boolean oneMin and the granularity schedule. The algorithm and evaluation rest on the test-suite correctness proxy and on trajectory replay completeness. CodeSlop is a definitional term, not a postulated entity, so no invented entity is recorded.

axioms (4)
  • domain assumption Behavior preservation can be adequately approximated by passing the task-specific test suite T_F.
    Every counterfactual in Algorithm 1 is accepted iff apply(S\u_j) passes T_F (Line 11). The entire practical definition of CodeSlop/AP* is replaced by test-passing; hidden oracle regressions are possible. Section IV-C.
  • domain assumption The reduced trajectory TrajR contains all edits that survive into the final patch and preserves their dependency ordering after replay.
    Section IV-B1: 'TRIM faithfully replays the trajectory in temporal order, applying both edit and undo operations.' If replay is lossy for heterogeneous scaffolds, the hierarchical search space is incomplete.
  • domain assumption Edit sequences between feedback requests are meaningful dependency groups for counterfactual removal.
    The coarse-to-fine search at edit-sequence granularity assumes edits made between tests form a natural repair hypothesis; this is the paper's key structural bet (Section IV-C).
  • domain assumption Hidden oracle tests (fail-to-pass suite or LLM judge) are a valid evaluation measure of behavior preservation.
    Section V-B uses Live-kBench LLM judge and SWE-Bench hidden tests to validate MP; LLM judge bias is acknowledged in Threats to Validity.

pith-pipeline@v1.3.0-alltime-deepseek · 18155 in / 14956 out tokens · 135212 ms · 2026-08-01T15:47:29.496499+00:00 · methodology

0 comments
read the original abstract

Coding agents are increasingly used to accelerate code generation in many downstream tasks, such as fixing bugs, building applications, and prototyping. However, despite their value as coding assistants, agent-generated code tends to be larger and more verbose than the corresponding human-written implementation. In this work, we show that the cause lies in the agent's own search process: while iterating toward a passing solution, an agent accumulates speculative edits, abandoned hypotheses, and temporary changes that persist into the final patch. This may seem harmless for a single patch, but the problem compounds as agents take responsibility for ever-larger portions of a codebase-a codebase that was once minimal and well-maintained slowly accumulates redundancy faster than it can be cleaned up, drifting to a state that is harder to maintain. Given the magnitude of this problem, we take a step towards alleviating this issue. First, we formally define this phenomenon as CodeSlop-the residual and functionally unnecessary edits commonly seen in AI-generated code. We then introduce our algorithm TRIM (Trajectory-guided Redundancy Identification and Minimization). Rather than minimizing CodeSlop directly, TRIM instead minimizes agent trajectories. As we show empirically, this indirect technique of minimizing CodeSlop is highly effective: TRIM cuts CodeSlop by 17.9%-32.9% across agentic scaffolds, with negligible performance regression. TRIM is also highly efficient, requiring roughly half the validation cost of algorithmic baselines such as Delta Debugging.

Figures

Figures reproduced from arXiv: 2607.18161 by Aleksandr Nogikh, Alex Mathai, Baishakhi Ray, Franjo Ivancic, Junfeng Yang, Petros Maniatis, Shobini Iyer.

Figure 1
Figure 1. Figure 1: Two motivating examples of CODESLOP. TRIM recovers the human-equivalent fix hidden inside a larger agent patch. Each trajectory shows (i) sequence of edits (E), (ii) atomic edit action (eij ), and (iii) Feedbacks. Atomic edits in the trajectory map to regions of the final patch (bounded boxes). The starred region (⋆) is the human patch, while the purple-bordered regions are CODESLOP—residual edits (eij ) f… view at source ↗
Figure 2
Figure 2. Figure 2: The task of minimizing CODESLOP. The horizontal line measures patch length. On the left is the minimal behavior￾preserving patch (AP∗ ) and on the right is the original verbose agent patch (AP). In the middle is the minimized patch (MP). To minimize CODESLOP and patch length, we move MP closer to AP∗ and further away from AP. where n is the number of modifiable units in the patch. Consequently, exhaustive … view at source ↗
Figure 3
Figure 3. Figure 3: Overview of TRIM. 0 A coding agent repairs a bug, producing a patch and an execution trajectory containing code edits, repository interactions, and feedback requests (F R). 1 We preprocess the trajectory, retaining only edits and feedback requests, and group edits between consecutive F Rs into edit sequences (E1–E3), forming the trajectory-derived search space T rajR (shown for the motivating example in §I… view at source ↗
Figure 4
Figure 4. Figure 4: TRIM recovering the minimal patch from a 7-edit agent patch. Different rows represent the granularity TRIM reasons about at each level—edit sequence, then files, then individual edit actions. Node color denotes the edited file; starred edits (e41, e43) are the true edit actions and all others are CODESLOP. The patch shrinks 7 → 5 → 3→2. Otherwise, the candidate is rejected and the removed edits are restore… view at source ↗
Figure 5
Figure 5. Figure 5: Left. ∆Slop % vs Cost for TRIM’s variants and DD-Hunk on CRASHFIXER trajectories (Live-kBench). TRIM variants reach comparable ∆Slop at half the cost of DD-Hunk. Right. TRIM vs. DD-Hunks. TRIM removes similar slop (∆=+0.24 lines, 95% CI [- 0.4,+0.9]) at 1.9× lower cost. The shaded green region indicates the better setting: more slop removed at cheaper cost. Results [PITH_FULL_IMAGE:figures/full_fig_p009_5.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

37 extracted references · 8 linked inside Pith

  1. [1]

    (2026) Claude Code by Anthropic — AI Coding Agent, Terminal, IDE

    Anthropic, PBC. (2026) Claude Code by Anthropic — AI Coding Agent, Terminal, IDE. [Online]. Available: https://claude.com/product/claude-code

    2026

  2. [2]

    (2026) Claude Code by Anthropic — AI Coding Agent, Terminal, IDE

    GitHub, Inc. (2026) Claude Code by Anthropic — AI Coding Agent, Terminal, IDE. [Online]. Available: https://github.com/features/copilot

    2026

  3. [3]

    (2026) Cursor: The best coding agent

    Anysphere, Inc. (2026) Cursor: The best coding agent. [Online]. Available: https://cursor.com

    2026

  4. [4]

    Agentic ai software engineers: Programming with trust,

    A. Roychoudhury, C. P ˘as˘areanu, M. Pradel, and B. Ray, “Agentic ai software engineers: Programming with trust,” Communications of the ACM, vol. 69, no. 5, pp. 56–58, 2026

    2026

  5. [5]

    Understanding software engineering agents through the lens of traceability: An empirical study,

    I. Ceka, S. Pujar, S. Ramji, L. Buratti, G. Kaiser, and B. Ray, “Understanding software engineering agents through the lens of traceability: An empirical study,” 2026

    2026

  6. [6]

    Why agentic-prs get rejected: A comparative study of coding agents,

    S. Nakashima, Y . Ishimoto, M. Kondo, S. Mclntosh, and Y . Kamei, “Why agentic-prs get rejected: A comparative study of coding agents,”arXiv preprint arXiv:2602.04226, 2026

    arXiv 2026

  7. [7]

    Novice developers produce larger review overhead for project maintainers while vibe cod- ing,

    S. A. Asdaque, I. Haider, M. U. Malik, M. A. Ghafoor, and A. A. Bangash, “Novice developers produce larger review overhead for project maintainers while vibe cod- ing,”arXiv preprint arXiv:2602.23905, 2026

    arXiv 2026

  8. [8]

    Traje- val: Decomposing code agent trajectories for fine-grained diagnosis,

    M. Kim, D. Wang, S. Cui, F. Farmahinifarahani, S. Garg, B. Ray, T. Y . Zhuo, R. Mukherjee, and V . Kumar, “Traje- val: Decomposing code agent trajectories for fine-grained diagnosis,”arXiv preprint arXiv:2603.24631, 2026

    Pith/arXiv arXiv 2026

  9. [9]

    Improving the efficiency of llm agent systems through trajectory reduction,

    Y .-A. Xiao, P. Gao, C. Peng, and Y . Xiong, “Improving the efficiency of llm agent systems through trajectory reduction,”arXiv preprint arXiv:2509.23586, 2025

    arXiv 2025

  10. [10]

    Memory leak in map create,

    Syzkaller, “Memory leak in map create,” 2025. [Online]. Available: https://syzkaller.appspot.com/bug? extid=cf08c551fecea9fd1320

    2025

  11. [11]

    SWE-agent: Agent- computer interfaces enable automated software engi- neering,

    J. Yang, C. E. Jimenez, A. Wettig, K. Lieret, S. Yao, K. Narasimhan, and O. Press, “SWE-agent: Agent- computer interfaces enable automated software engi- neering,”Advances in Neural Information Processing Systems, vol. 37, pp. 50 528–50 652, 2024

    2024

  12. [12]

    What to cut? predicting unnecessary methods in agentic code generation,

    K. Watanabe, T. Shirai, Y . Kashiwa, and H. Iida, “What to cut? predicting unnecessary methods in agentic code generation,”arXiv preprint arXiv:2602.17091, 2026

    arXiv 2026

  13. [14]

    What is wrong with your code generated by large language models? an extensive study,

    S. Dou, H. Jia, S. Wu, H. Zheng, M. Wu, Y . Tao, M. Zhang, M. Chai, J. Fan, Z. Xiet al., “What is wrong with your code generated by large language models? an extensive study,”Science China Information Sciences, vol. 69, no. 1, p. 112107, 2026

    2026

  14. [15]

    Speed at the cost of quality: How cursor ai increases short-term velocity and long-term complex- ity in open-source projects,

    H. He, C. Miller, S. Agarwal, C. K ¨astner, and B. Vasilescu, “Speed at the cost of quality: How cursor ai increases short-term velocity and long-term complex- ity in open-source projects,”23rd International Mining Software Repositories Conference (MSR)), 2026

    2026

  15. [16]

    Faster code, deeper debt? a multivocal literature review on technical debt and its early signs in llm-assisted software development,

    R. Ehsani, S. Rawal, Y . Cai, and P. Chatterjee, “Faster code, deeper debt? a multivocal literature review on technical debt and its early signs in llm-assisted software development,”ACM Transactions on Software Engineer- ing and Methodology, 2026

    2026

  16. [17]

    A taxonomy of inefficiencies in llm-generated python code,

    A. A. Abbassi, L. Da Silva, A. Nikanjam, and F. Khomh, “A taxonomy of inefficiencies in llm-generated python code,” in2025 IEEE International Conference on Soft- ware Maintenance and Evolution (ICSME). IEEE, 2025, pp. 393–404

    2025

  17. [18]

    Yesterday, my program worked. today, it does not. why?

    A. Zeller, “Yesterday, my program worked. today, it does not. why?”SIGSOFT Softw. Eng. Notes, vol. 24, no. 6, p. 253–267, Oct. 1999. [Online]. Available: https://doi.org/10.1145/318774.318946

    arXiv 1999

  18. [19]

    Git bisect,

    Git, “Git bisect,” 2026. [Online]. Available: https: //git-scm.com/docs/git-bisect

    2026

  19. [20]

    Outrunning llm cutoffs: A live kernel crash resolution benchmark for all,

    C. Huang, A. Mathai, F. Yu, A. Nogikh, P. Maniatis, 11 F. Ivan ˇci´c, E. Wu, K. Kaffes, J. Yang, and B. Ray, “Outrunning llm cutoffs: A live kernel crash resolution benchmark for all,” 2026. [Online]. Available: https: //arxiv.org/abs/2602.02690

    Pith/arXiv arXiv 2026

  20. [21]

    SWE-bench: Can lan- guage models resolve real-world github issues?

    C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, and K. Narasimhan, “SWE-bench: Can lan- guage models resolve real-world github issues?”arXiv preprint arXiv:2310.06770, 2023

    Pith/arXiv arXiv 2023

  21. [22]

    Slopcodebench: Benchmarking how coding agents degrade over long- horizon iterative tasks,

    G. Orlanski, D. Roy, A. Yun, C. Shin, A. Gu, A. Ge, D. Adila, F. Sala, and A. Albarghouthi, “Slopcodebench: Benchmarking how coding agents degrade over long- horizon iterative tasks,” 2026. [Online]. Available: https://arxiv.org/abs/2603.24755

    Pith/arXiv arXiv 2026

  22. [23]

    Kgym: A platform and dataset to benchmark large language models on linux kernel crash resolution,

    A. Mathai, C. Huang, P. Maniatis, A. Nogikh, F. Ivan ˇci´c, J. Yang, and B. Ray, “Kgym: A platform and dataset to benchmark large language models on linux kernel crash resolution,”Advances in Neural Information Processing Systems, vol. 37, pp. 78 053–78 078, 2024

    2024

  23. [24]

    CrashFixer: A crash resolution agent for the Linux kernel,

    A. Mathai, C. Huang, S. Ma, J. Kim, H. Mitchell, A. Nogikh, P. Maniatis, F. Ivan ˇci´c, J. Yang, and B. Ray, “CrashFixer: A crash resolution agent for the Linux kernel,”arXiv preprint arXiv:2504.20412, 2025

    Pith/arXiv arXiv 2025

  24. [25]

    Openhands: An open platform for ai software developers as generalist agents,

    X. Wang, B. Li, Y . Song, F. F. Xu, X. Tang, M. Zhuge, J. Pan, Y . Song, B. Li, J. Singhet al., “Openhands: An open platform for ai software developers as generalist agents,”arXiv preprint arXiv:2407.16741, 2024

    Pith/arXiv arXiv 2024

  25. [26]

    Hdd: hierarchical delta debugging,

    G. Misherghi and Z. Su, “Hdd: hierarchical delta debugging,” inProceedings of the 28th International Conference on Software Engineering, ser. ICSE ’06. New York, NY , USA: Association for Computing Machinery, 2006, p. 142–151. [Online]. Available: https://doi.org/10.1145/1134285.1134307

    arXiv 2006

  26. [27]

    Measuring ai

    C. Shaib, T. Chakrabarty, D. Garcia-Olano, and B. C. Wallace, “Measuring ai ”slop” in text,” 2026. [Online]. Available: https://arxiv.org/abs/2509.19163

    arXiv 2026

  27. [28]

    Test-case reduction for c compiler bugs,

    J. Regehr, Y . Chen, P. Cuoq, E. Eide, C. Ellison, and X. Yang, “Test-case reduction for c compiler bugs,”SIGPLAN Not., vol. 47, no. 6, p. 335–346, Jun. 2012. [Online]. Available: https://doi.org/10.1145/ 2345156.2254104

    arXiv 2012

  28. [29]

    Perses: syntax-guided program reduction,

    C. Sun, Y . Li, Q. Zhang, T. Gu, and Z. Su, “Perses: syntax-guided program reduction,” inProceedings of the 40th International Conference on Software Engineering, ser. ICSE ’18. New York, NY , USA: Association for Computing Machinery, 2018, p. 361–371. [Online]. Available: https://doi.org/10.1145/3180155.3180236

    arXiv 2018

  29. [30]

    Effective program debloating via reinforcement learning,

    K. Heo, W. Lee, P. Pashakhanloo, and M. Naik, “Effective program debloating via reinforcement learning,” inProceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’18. New York, NY , USA: Association for Computing Machinery, 2018, p. 380–394. [Online]. Available: https://doi.org/10.1145/3243734.3243838

    arXiv 2018

  30. [31]

    Cimplifier: automatically debloating containers,

    V . Rastogi, D. Davidson, L. De Carli, S. Jha, and P. McDaniel, “Cimplifier: automatically debloating containers,” inProceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering, ser. ESEC/FSE 2017. New York, NY , USA: Association for Computing Machinery, 2017, p. 476–486. [Online]. Available: https://doi.org/10.1145/3106237.3106271

    arXiv 2017

  31. [32]

    Jred: Program customiza- tion and bloatware mitigation based on static analysis,

    Y . Jiang, D. Wu, and P. Liu, “Jred: Program customiza- tion and bloatware mitigation based on static analysis,” 06 2016, pp. 12–21

    2016

  32. [33]

    Debloating software through Piece-Wise compilation and loading,

    A. Quach, A. Prakash, and L. Yan, “Debloating software through Piece-Wise compilation and loading,” in27th USENIX Security Symposium (USENIX Security 18). Baltimore, MD: USENIX Association, Aug. 2018, pp. 869–886. [Online]. Available: https://www.usenix.org/ conference/usenixsecurity18/presentation/quach

    2018

  33. [34]

    Compressing code context for llm-based issue resolution,

    H. Jia, E. T. Barr, and S. Mechtaev, “Compressing code context for llm-based issue resolution,” 2026. [Online]. Available: https://arxiv.org/abs/2603.28119

    arXiv 2026

  34. [35]

    SWE-bench leader- boards,

    C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, and K. Narasimhan, “SWE-bench leader- boards,” https://www.swebench.com/, 2025

    2025

  35. [36]

    Trae agent: An LLM-based agent for software engineering with test-time scaling,

    Trae Research Team, P. Gao, Z. Tian, X. Meng, X. Wang, R. Hu, Y . Xiao, Y . Liu, Z. Zhang, J. Chen, C. Gao, Y . Lin, Y . Xiong, C. Peng, and X. Liu, “Trae agent: An LLM-based agent for software engineering with test-time scaling,” 2025. [Online]. Available: https://arxiv.org/abs/2507.23370

    Pith/arXiv arXiv 2025

  36. [37]

    Live-SWE-agent: Can software engineering agents self- evolve on the fly?

    C. S. Xia, Z. Wang, Y . Yang, Y . Wei, and L. Zhang, “Live-SWE-agent: Can software engineering agents self- evolve on the fly?”arXiv preprint arXiv:2511.13646, 2025

    arXiv 2025

  37. [38]

    Code Researcher: Deep research agent for large systems code and commit history,

    R. Singh, S. Joel, A. Mehrotra, N. Wadhwa, R. B. Bairi, A. Kanade, and N. Natarajan, “Code Researcher: Deep research agent for large systems code and commit history,”arXiv preprint arXiv:2506.11060, 2025. 12

    Pith/arXiv arXiv 2025