Pith. sign in

REVIEW 5 major objections 6 minor 64 references

SLICEMATE: Accurate and Scalable Static Program Slicing via LLM-Powered Agents

T0 review · 5 major / 6 minor · reviewed 2026-08-15 · deepseek-v4-flash

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

Pith's one-line read LLM agents beat dependency-graph slicing on large programs.

desk verdict A genuinely new LLM-agent slicing pipeline with a valuable hand-annotated benchmark, but the headline gains are weakened by leakage risk, single-run evaluation, and a hyperparameter tuned on the same benchmark. read the letter →

arxiv 2507.18957 v1 pith:GGDHKXCR submitted 2025-07-25 cs.SE

Jianming Chang , Jieke Shi , Yunbo Lyu , Xin Zhou , Lulu Wang , Zhou Yang , Bixin Li , David Lo This is my paper · ORCID
classification cs.SE
keywords staticprogramslicingLLMagentsmulti-agentsystemsdependencegraphbuglocalizationcodeanalysisbenchmarkverificationrefinementloopJavaandPython
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

SliceMate is a proposal to replace the standard machinery of static program slicing—dependency-graph reachability and per-statement learned classification—with an orchestrated team of three large-language-model agents: one that synthesizes candidate slices, one that verifies them for completeness and conciseness, and one that repairs them. The paper claims this agent loop beats all five existing slicing tools it compares against, with the largest gains on large multi-file programs: up to 63.1% higher accuracy and 62.5% higher F1 than the best baseline, and up to 34% better Top-10 bug-localization accuracy downstream. It also contributes SliceBench, 2,200 manually annotated slicing instances in Java and Python, with programs up to 8,577 lines. A sympathetic reader would care because the result suggests that a core code-analysis primitive, one traditionally tied to expensive graph infrastructure and language-specific parsers, can be carried by LLM reasoning with no dependency graph and no task-specific training.

What carries the argument

The load-bearing mechanism is the four-interface, three-agent loop. A criterion-scope search establishes the starting function; invocation extraction and project-function retrieval let the synthesis agent expand across functions using LLM-inferred dependencies; module-information extraction pulls in globals and structural context. The verification agent then runs conciseness analysis, which drops irrelevant statements, and completeness analysis, which reports missing data, control, or inter-procedural dependencies in a fixed format, and the refinement agent repairs the slice using only verbatim code from the search scope. A control module halts at a valid verdict or after five iterations. The structured check-then-repair cycle is what the paper claims converts a strong but unreliable single-pass generator into a high-accuracy slicer.

What would settle it

Record the verification agent's flagged missing and irrelevant statements on the 2,200 SliceBench instances and compare them with the human-annotated ground truth. If the verifier's per-judgment precision and recall are near chance while end-to-end F1 remains high, the reported gains do not come from the claimed verification mechanism. A direct oracle experiment—feeding the true missing statements into the refinement agent instead of the verifier's output—should leave end-to-end F1 unchanged if the verifier is already supplying exactly that information.

Watch

Extended reading notes

Core claim

The paper's central claim is that a fixed-pipeline trio of LLM agents can compute static program slices more accurately than both dependency-graph reachability tools and models trained on those tools' output. The synthesis agent starts from the function containing the slicing criterion and expands its search scope one function or file at a time; the verification agent separates conciseness from completeness and reports missing dependencies or structures in a structured format; the refinement agent adds only missing code copied verbatim from the already-seen scope. The authors report that this loop outperforms all five baselines on every metric for Java and Python, with the largest wins on large multi-file programs, and that the resulting slices improve downstream bug localization by up to 34% in Top-10 accuracy. The claim is backed by a newly constructed manually annotated benchmark of 2,200 instances, with programs up to 8,577 lines and near-perfect annotator agreement.

Load-bearing premise

The load-bearing premise is that the verification agent's judgments about missing and irrelevant statements align with the human slicing semantics used to build the ground truth, since every repair step obeys those judgments and the paper only validates the end-to-end slice, never that judgment directly.

Editorial extensions

If this is right

  • Static slicing no longer requires building and traversing a program dependence graph, since the same LLM front-end handles Java and Python and is claimed to be language-agnostic with suitable parsing support.
  • The advantage over existing tools grows with program size: on multi-file programs averaging over 2,100 statements, SliceMate reports up to 63.1% higher accuracy and 62.5% higher F1 than the best baseline, where the paper's analysis says both traditional reachability and per-statement classification degrade.
  • Downstream consumers benefit: slices from SliceMate raise Top-10 bug-localization accuracy of existing localizers by up to 34% and improve bug-coverage ratios in debugging, because the slices are both precise and concise.
  • The verification–refinement loop is load-bearing: removing it lowers F1 by 5.5% to 29.1% across settings, and each additional iteration yields diminishing returns beyond five.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the mechanism generalizes, the same synthesis–verify–repair architecture could be applied to other graph-reachability analyses such as taint tracking or change-impact analysis, with the verifier redesigned around each analysis's own correctness condition.
  • The headline gains are measured against human-annotated slices rather than the classical reachability-defined slice, so whether those gains transfer to consumers that expect exact graph-theoretic slices remains untested.
  • A cheap mechanism check is to replace the LLM verification agent with a deterministic under-approximation, such as flagging only variables used before definition within the slice, and measure how much of the F1 and localization gains survive; this isolates the verifier's contribution.
  • Because refinement may only add code verbatim from the already-searched scope, the system's ceiling is set by the synthesis agent's scope expansion, so measuring scope-expansion recall separately from slice F1 would show where failures originate.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

5 major / 6 minor

Summary. SliceMate is an LLM-based multi-agent system for static program slicing that avoids explicit dependency graph construction. It uses a synthesis agent to generate candidate slices, a verification agent to check completeness and conciseness, and a refinement agent to repair slices, controlled by a module that limits iterations. The paper introduces SliceBench, a manually annotated benchmark of 2,200 Java and Python slicing instances, and reports that SliceMate outperforms traditional tools (Joern, JavaSlicer, TyperSlicer) and learning-based baselines (NS-Slicer, NS-Slicer Pro) on both CodeNet-scale and real-world GitHub-scale programs. It also demonstrates downstream improvements in debugging and bug localization on Defects4J and BugsInPy.

Significance. If validated, SliceMate would be a significant advance: it shows that a prompt-based LLM pipeline can perform inter-procedural slicing on large multi-file programs without constructing a program dependence graph, and the manually annotated SliceBench with high inter-annotator agreement is a valuable resource for the community. The strength of the paper lies in the concrete agent design, the replication of the full pipeline description, and the substantial annotation effort. However, the empirical claims are currently not fully supported because of the lack of control for training-data leakage, test-set tuning of a hyperparameter, and absence of statistical validation. The core results could still hold, but the evidence as presented is not yet convincing.

major comments (5)
  1. [§4.1, §6.1.1] The evaluation uses only public programs from CodeNet, Defects4J, and BugsInPy, all of which are very likely to be present in GPT-4o's pretraining data. No membership check, knowledge-cutoff filter, private holdout, or semantics-preserving variant evaluation is reported. Since the baselines do not have access to these exact programs, any memorization advantage transfers directly to the reported gains of up to 63.1% in accuracy and 62.5% in F1. Please provide evidence that the results reflect slicing competence rather than memorization, for example by evaluating on newly collected or modified programs, or by reporting a leakage analysis.
  2. [§3.4, §6.3.3] The maximum number of verification-refinement iterations (set to 5) is chosen by measuring F1 on SliceBench-GitHub, which is the same benchmark used for the headline RQ1 results in Table 1. This constitutes tuning a free parameter on the test set and can inflate reported performance. Use a separate validation set, nested cross-validation, or report RQ1 results across different iteration limits to show that the conclusion is robust.
  3. [§6.1.1] No repeated runs or statistical significance tests are reported for SliceMate. LLM outputs are stochastic even at temperature 0, and the paper claims SliceMate 'significantly outperforms' baselines without quantifying variance. Report mean and standard deviation over multiple runs, and perform appropriate significance tests (e.g., paired bootstrap or Wilcoxon) against the best baseline for the headline metrics.
  4. [§3.2] The verification agent is load-bearing for the claim that the refinement loop converges to the human-defined slice, yet its completeness and conciseness judgments are never evaluated in isolation. The paper only reports end-to-end F1. An evaluation of the verifier's precision/recall on artificially corrupted slices, or an error analysis of the refinement iterations, would clarify whether the gains come from genuine semantic verification or from aligning with annotation conventions or memorized ground truth.
  5. [§1, §7] The contributions state that SliceBench is 'publicly available', but the manuscript contains no link, repository identifier, or data availability statement. Since SliceBench is a central contribution and the experiments depend on it, please provide the actual availability information and ensure code and data are accessible for reproducibility.
minor comments (6)
  1. [§4.1] The description of the CodeNet sampling is internally inconsistent: it first says 'select 1,000 representative programs' and then says 'we further sample 1,000 Python and 1,000 Java programs from CodeNet, yielding 2,000 slicing instances.' Please clarify the exact composition of the CodeNet subset.
  2. [Abstract/§1] The abstract reports improvements of 'up to 22% accuracy and 28% F1' while the introduction reports 'up to 63.1% accuracy and 62.5% F1' for large programs. Please reconcile these numbers or clearly specify the setting for each.
  3. [§6.2.2] The text uses 'BugsInPY' instead of the correct 'BugsInPy' in several places.
  4. [§6.1.2] The sentence 'The bolded value in the table indicate the highest value' should be 'values indicate' or 'value indicates'.
  5. [§3.1, §6.1.1] Several instances of 'SliceMate' and other words are missing spaces in the text, e.g., 'AlthoughSliceMatedoes not need' in §3.1.
  6. [Figure 12] The legend relies on red/blue colors that are not distinguishable in grayscale print; add markers or textual labels for the Python and Java curves.

Circularity Check

1 steps flagged · score 4.0 of 10

Core slicing pipeline is not circular, but the max-iteration hyperparameter is tuned on the same SliceBench-GitHub subset used for the headline large-scale evaluation, making the RQ1 gain partially self-confirming.

  1. fitted input called prediction [Section 6.3.1 / Section 6.3.3 and Table 1 (RQ1)]
    "Given the need for more extensive verification and refinement in large-scale programs, we conduct the experiment on SliceBench-GitHub. ... To determine an appropriate upper bound, we analyze how varying this maximum affects SliceMate’s performance by testing iteration counts from 1 to 10. ... Based on this trend, we set the default maximum iterations for SliceMate to 5."

    The max-iteration count is a method configuration, and it is selected by maximizing F1 on SliceBench-GitHub. The same SliceBench-GitHub subset is then used in Table 1 to report SliceMate's headline large-scale gains (up to 63.1% higher accuracy and 62.5% higher F1 than the best baseline). Thus the reported RQ1 performance on the large-scale subset is not an out-of-sample prediction: the evaluation labels were already used to choose the configuration. This is test-set tuning rather than a derivation-level circularity, but it makes the headline large-scale comparison partially self-confirming.

full rationale

SliceMate's slice-generation chain is not circular: the synthesis, verification, and refinement agents operate on source code and the slicing criterion, and the benchmark ground truth comes from independent manual annotation (dual review, Cohen's Kappa 0.893–0.927), not from SliceMate's outputs. The dependency definitions in the prompts and the annotation guidelines both follow standard static-slicing semantics, which is consistency rather than circularity. The self-citations to TypeSlicer [20] and IncBL [55] are used as baselines/tools, not as load-bearing justification for SliceMate's core claims, so they do not raise the score. The one circularity-adjacent issue is the control-module tuning: SliceBench-GitHub is used both to select the maximum iteration count (by maximizing F1, Section 6.3.3) and to report the large-scale RQ1 results (Table 1). This is test-set tuning rather than derivation-level circularity; the headline accuracy/F1 numbers on the large-scale subset are therefore not a fully independent prediction. Because the tuning affects only a convergence cap and the main pipeline is otherwise self-contained, the circularity score is moderate rather than high.

Assumptions & free parameters 1 free parameters · 4 assumptions · 0 invented entities

The central claims rest on the reliability of the human-annotated benchmark, the LLM's dependency reasoning, and the syntactic parsing used for scope expansion. The only numeric quantity tuned on the evaluation data is the iteration cap of 5. SliceBench is the paper's own dataset, which raises circularity concerns but is mitigated by dual human annotation and baseline comparisons.

free parameters (1)
  • max_verification_refinement_iterations = 5
    Section 6.3.3 selects the iteration cap by maximizing F1 on SliceBench-GitHub (Figure 12), then the same cap is used in the RQ1 headline results on the same benchmark. This is a hyperparameter tuned on the evaluation data.
assumptions (4)
  • domain assumption The standard definitions of data, control, and interprocedural dependencies (Weiser; Horwitz et al.) correctly characterize the static slicing semantics used for ground truth and prompts.
    The benchmark annotation guidelines and the LLM prompts in Section 3 and Section 4 rely on these definitions as the correct target semantics for static backward slicing.
  • domain assumption GPT-4o's LLM reasoning can infer program dependencies accurately enough from raw code and function metadata, both for generating candidate slices and for verifying completeness and conciseness.
    The entire SliceMate pipeline in Section 3 depends on the LLM's ability to reason about dependencies without explicit graph construction; the paper tests this empirically but does not prove it.
  • domain assumption Tree-sitter-based parsing correctly identifies functions, invocation statements, and module or class structure for both Java and Python, enabling scope expansion.
    The ACIs in Section 3.1, including Criterion Scope Search and Invocation Extraction, assume the parser reliably extracts the syntactic structure needed for interprocedural expansion.
  • domain assumption The manually constructed SliceBench annotations are correct ground truth for static backward slicing, including cross-file cases.
    All RQ1 and RQ2 evaluations compare against SliceBench labels; if the annotations are wrong or inconsistent, the reported gains are not meaningful. Inter-annotator agreement is reported but the dataset is not externally audited.

how reviews work

0 comments
Cite this review

Pith. "Pith review of SLICEMATE: Accurate and Scalable Static Program Slicing via LLM-Powered Agents." pith.science (2026). https://pith.science/paper/GGDHKXCR

@misc{pith2026250718957,
  author       = {Pith},
  title        = {Pith review of: SLICEMATE: Accurate and Scalable Static Program Slicing via LLM-Powered Agents},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/GGDHKXCR}},
  note         = {Machine review of arXiv:2507.18957}
}
read the original abstract

Static program slicing, which extracts the executable portions of a program that affect the values at a specific location, supports many software analysis tasks such as debugging and security auditing. However, traditional slicing tools rely on computationally expensive reachability analysis over dependency graphs, which struggle to scale to large programs and often fail to handle code with incomplete syntax. Recently emerged learning-based methods, while more robust to such cases, still fall short of achieving comparable performance to traditional methods on well-formed code. In this work, we propose SliceMate, a novel static program slicing solution powered by Large Language Model (LLM) agents. It bypasses the need for explicit dependency graph construction and achieving superior slicing accuracy. Concretely, SliceMate integrates three specialized agents: (1) a synthesis agent that produces candidate slices by incrementally expanding the scan scope across functions and files guided by LLM-inferred dependencies; (2) a verification agent that performs conciseness and completeness checks of the candidate slices, detecting missing or irrelevant statements; and (3) a refinement agent that repairs the slices with minimal edits in accordance with the verification results. These agents are orchestrated by a control module that ensures timely convergence and outputs high-quality slices without manual intervention. For rigorous evaluation, we construct a new and high-quality benchmark, SliceBench, comprising 2,200 manually annotated Java and Python programs, with program lengths ranging from 5 to 8,577 lines, significantly larger than those in existing slicing benchmarks. Experimental results show that SliceMate greatly outperforms both traditional and learning-based slicing tools.

Figures

Figures reproduced from arXiv: 2507.18957 by the authors.

Figure 1
Figure 1. Difference between SliceMate and existing static slicing techniques. SliceMate produces program slices with￾out requiring explicit dependency graph construction, large￾scale training data, or task-specific fine-tuning. Static program slicing techniques can be broadly divided into two categories: traditional static slicing and learning-based slicing. Traditional methods (at the bottom of [PITH_FULL_IMAGE:figures/ful… view at source ↗
Figure 2
Figure 2. Overview of our approach. SliceMate generates a slice via synthesis agent and iteratively improves it through verification and refinement agents under control module. invocation, and output refinement, delivering adaptive and context￾aware solutions to real-world challenges in software engineering. LLM-based software engineering agents typically follow one of two paradigms [39]. The first adopts fixed, domain-specif… view at source ↗
Figure 3
Figure 3. Workflow of the synthesis agent. It generates slices [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figures from the paper (7 more)
Figure 5
Figure 5. Figure 5: Prompt for the search scope expansion comprehensive metadata about all functions in the project, includ￾ing their associated classes, function names, and parameter lists. This metadata enables the agent to accurately distinguish complex features between functions like …
Figure 4
Figure 4. Figure 4: Prompt for the synthesis agent [PITH_FULL_IMAGE:figures/full_fig_p004_4.png]
Figure 6
Figure 6. Figure 6: Workflow of the verification agent Completeness Analysis Prompt 1. Role Playing You are an AI that simplifies a static program slice by removing redundant lines. 1. Role Playing Conciseness Analysis Prompt 2. Data Slicing Criterion - Remove all lines that do not contri…
Figure 7
Figure 7. Figure 7: Prompt for the conciseness analysis determine whether each line contributes to the slicing criterion. Additionally, since static slicing typically operates at the line level, we explicitly instruct the model not to remove partial line content, in order to preserve the …
Figure 10
Figure 10. Figure 10: An illustrative example to show how SliceMate generates a slice compared with the baselines (RQ1) [PITH_FULL_IMAGE:figures/full_fig_p008_10.png]
Figure 11
Figure 11. Figure 11: The bug localization performance of IncBL and LLM4FPM with [PITH_FULL_IMAGE:figures/full_fig_p008_11.png]
Figure 12
Figure 12. Figure 12: F1 scores of SliceMate for different control mod￾ule iterations (RQ3). 6.3 RQ 3. Ablation Study 6.3.1 Settings. This experiment examines the impact of verifica￾tion and refinement agents on SliceMate. Since these agents iter￾atively refine slices with complementary ro…

Review history (2 revisions) →

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

64 extracted references · 59 canonical work pages

  1. [1]

    Program slicing

    Mark Weiser. Program slicing. In Proceedings of the 5th International Conference on Software Engineering (ICSE) , page 439–449. IEEE Press, 1981

    work page 1981

  2. [2]

    A survey of program slicing techniques

    Frank Tip. A survey of program slicing techniques. Technical report, NLD, 1994

    work page 1994

  3. [3]

    A brief survey of program slicing

    Baowen Xu, Ju Qian, Xiaofang Zhang, Zhongqiang Wu, and Lin Chen. A brief survey of program slicing. ACM SIGSOFT Software Engineering Notes , 30(2):1–36, 2005

    work page 2005

  4. [4]

    Lo- cating faults with program slicing: an empirical analysis

    Ezekiel Soremekun, Lukas Kirschner, Marcel Bohme, and Andreas Zeller. Lo- cating faults with program slicing: an empirical analysis. Empirical Software Engineering, 26(3):51, 2021

    work page 2021

  5. [5]

    Orbs: Language-independent program slicing

    David Binkley, Nicolas Gold, Mark Harman, Syed Islam, Jens Krinke, and Shin Yoo. Orbs: Language-independent program slicing. In Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering , pages 109–120, 2014

    work page 2014

  6. [6]

    More accurate dynamic slicing for better supporting software debugging

    Xiangyu Li and Alessandro Orso. More accurate dynamic slicing for better supporting software debugging. In 2020 IEEE 13th International Conference on Software Testing, Validation and Verification (ICST), pages 28–38. IEEE, 2020

    work page 2020

  7. [7]

    Mvd: Memory-related vulnerability detection based on flow-sensitive graph neural net- works

    Sicong Cao, Xiaobing Sun, Lili Bo, Rongxin Wu, Bin Li, and Chuanqi Tao. Mvd: Memory-related vulnerability detection based on flow-sensitive graph neural net- works. In 2022 IEEE/ACM 44th International Conference on Software Engineering (ICSE), pages 1456–1468, 2022

    work page 2022

  8. [8]

    On the effects of program slicing for vulnerability detection during code inspection

    Aurora Papotti, Fabio Massacci, and Katja Tuma. On the effects of program slicing for vulnerability detection during code inspection. In Proceedings of the 2024 IEEE/ACM 46th International Conference on Software Engineering: Companion Proceedings, pages 368–369, 2024

    work page 2024

Show all 64 references
  1. [9]

    Vulslicer: Vulnerability detection through code slicing

    Solmaz Salimi and Mehdi Kharrazi. Vulslicer: Vulnerability detection through code slicing. Journal of Systems and Software , 193:111450, 2022

    2022

  2. [10]

    The impact of program reduction on automated program repair

    Linas Vidziunas, David Binkley, and Leon Moonen. The impact of program reduction on automated program repair. In 2024 IEEE International Conference on Software Maintenance and Evolution (ICSME) , pages 337–349, 2024

    2024

  3. [11]

    Reduce before you repair: Advantages of combining program slicing with automated program repair

    Omar I Al-Bataineh. Reduce before you repair: Advantages of combining program slicing with automated program repair. In 2025 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER) , pages 1–6. IEEE, 2025

    2025

  4. [12]

    Automated software vulnerability patching using large language models

    Yu Nong, Haoran Yang, Long Cheng, Hongxin Hu, and Haipeng Cai. Automated software vulnerability patching using large language models. arXiv preprint arXiv:2408.13597, 2024

    2024 arXiv

  5. [13]

    Deep transfer bug localization

    Xuan Huo, Ferdian Thung, Ming Li, David Lo, and Shu-Ting Shi. Deep transfer bug localization. IEEE Transactions on Software Engineering , 47(7):1368–1380, 2021

    2021

  6. [14]

    Bridging bug localization and issue fixing: A hierarchical localization framework leveraging large language models

    Jianming Chang, Xin Zhou, Lulu Wang, David Lo, and Bixin Li. Bridging bug localization and issue fixing: A hierarchical localization framework leveraging large language models. arXiv preprint arXiv:2502.15292, 2025

    2025 arXiv

  7. [15]

    Ottenstein, and Joe D

    Jeanne Ferrante, Karl J. Ottenstein, and Joe D. Warren. The program dependence graph and its use in optimization. ACM Transactions on Programming Languages and Systems, 9(3):319–349, July 1987

    1987

  8. [16]

    A comparison of tree- and line-oriented observational slicing

    David Binkley, Nicolas Gold, Syed Islam, Jens Krinke, and Shin Yoo. A comparison of tree- and line-oriented observational slicing. Empirical Software Engineering, 24(5):3077–3113, October 2019

    2019

  9. [17]

    Program Slices: Formal, Psychological, and Practical Investigations of an Automatic Program Abstraction Method

    Mark Weiser. Program Slices: Formal, Psychological, and Practical Investigations of an Automatic Program Abstraction Method . Ph.d. thesis, University of Michigan, Ann Arbor, 1979

    1979

  10. [18]

    Gallagher and Suzanne J

    Keith B. Gallagher and Suzanne J. Kozaitis. Program slicing: A brief retrospective. IEEE Transactions on Software Engineering , 51(3):720–724, 2025

    2025

  11. [19]

    A program slicer for java

    Carlos Galindo, Sergio Perez, and Josep Silva. A program slicer for java. In Software Engineering and Formal Methods: 20th International Conference, SEFM 2022, Berlin, Germany, September 26–30, 2022, Proceedings , page 146–151, Berlin, Heidelberg, 2022. Springer-Verlag

    2022

  12. [20]

    Type slicing: An accurate object oriented slicing based on sub-statement level dependence graph

    Wang Lulu, Li Bixin, and Kong Xianglong. Type slicing: An accurate object oriented slicing based on sub-statement level dependence graph. Information and Software Technology, 127:106369, 2020

    2020

  13. [21]

    Aashish Yadavally, Yi Li, Shaohua Wang, and Tien N. Nguyen. A learning-based approach to static program slicing. ACM international conference on Object oriented programming systems languages and applications (OOPSLA) , 8, April 2024

    2024

  14. [22]

    Nguyen, Wenbo Wang, and Shaohua Wang

    Aashish Yadavally, Tien N. Nguyen, Wenbo Wang, and Shaohua Wang. (partial) program dependence learning. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE) , pages 2501–2513, 2023

    2023

  15. [23]

    Program slicing in the era of large language models, 2024

    Kimya Khakzad Shahandashti, Mohammad Mahdi Mohajer, Alvine Boaye Belle, Song Wang, and Hadi Hemmati. Program slicing in the era of large language models, 2024

    2024

  16. [24]

    Large language models for software engineering: A systematic literature review

    Xinyi Hou, Yanjie Zhao, Yue Liu, Zhou Yang, Kailong Wang, Li Li, Xiapu Luo, David Lo, John Grundy, and Haoyu Wang. Large language models for software engineering: A systematic literature review. ACM Transactions on Software Engineering and Methodology, 33(8):1–79, 2024

    2024

  17. [25]

    Software testing with large language models: Survey, landscape, and vision

    Junjie Wang, Yuchao Huang, Chunyang Chen, Zhe Liu, Song Wang, and Qing Wang. Software testing with large language models: Survey, landscape, and vision. IEEE Transactions on Software Engineering , 2024

    2024

  18. [26]

    Codebert: A pre-trained model for programming and natural languages

    Zhangyin Feng, Daya Guo, Duyu Tang, Nan Duan, Xiaocheng Feng, Ming Gong, Linjun Shou, Bing Qin, Ting Liu, Daxin Jiang, et al. Codebert: A pre-trained model for programming and natural languages. In Findings of the Association for Computational Linguistics: EMNLP 2020 , pages 1...

    2020

  19. [27]

    Jean-François Bergeretti and Bernard A. Carre. Information-flow and data-flow analysis of while-programs. ACM Transactions on Programming Languages and Systems, 7(1):37–61, 1985

    1985

  20. [28]

    Illustrating interference in interfering ver- sions of programs

    Thomas Reps and Thomas Bricker. Illustrating interference in interfering ver- sions of programs. InProceedings of the Second International Workshop on Software Configuration Management, volume 17 of SIGSOFT Software Engineering Notes , pages 46–55, Princeton, NJ, USA, 1989. ACM

    1989

  21. [29]

    Interprocedural slicing using dependence graphs

    Susan Horwitz, Thomas Reps, and David Binkley. Interprocedural slicing using dependence graphs. ACM Transactions on Programming Languages and Systems , 12(1):26–60, January 1990

    1990

  22. [30]

    A survey on large language model based autonomous agents

    Lei Wang, Chen Ma, Xueyang Feng, Zeyu Zhang, Hao Yang, Jingsen Zhang, Zhiyuan Chen, Jiakai Tang, Xu Chen, Yankai Lin, Wayne Xin Zhao, Zhewei Wei, and Jirong Wen. A survey on large language model based autonomous agents. Frontiers of Computer Science , 18(6):186345, 2024

    2024

  23. [31]

    The rise and potential of large language model based agents: a survey

    Zhiheng Xi, Wenxiang Chen, Xin Guo, Wei He, Yiwen Ding, Boyang Hong, Ming Zhang, Junzhe Wang, Senjie Jin, Enyu Zhou, Rui Zheng, Xiaoran Fan, Xiao Wang, Limao Xiong, Yuhao Zhou, Weiran Wang, Changhao Jiang, Yicheng Zou, Xiangyang Liu, Zhangyue Yin, Shihan Dou, Rongxiang Weng, W...

    2025

  24. [32]

    Large language models for software engineering: A systematic literature review, 2024

    Xinyi Hou, Yanjie Zhao, Yue Liu, Zhou Yang, Kailong Wang, Li Li, Xiapu Luo, David Lo, John Grundy, and Haoyu Wang. Large language models for software engineering: A systematic literature review, 2024

    2024

  25. [33]

    Llm-based multi-agent systems for software engineering: Literature review, vision, and the road ahead

    Junda He, Christoph Treude, and David Lo. Llm-based multi-agent systems for software engineering: Literature review, vision, and the road ahead. ACM Transactions on Software Engineering and Methodology , 34(5), May 2025

    2025

  26. [34]

    Combining prompts with examples to enhance llm-based requirement elicitation

    Shuaicai Ren, Hiroyuki Nakagawa, and Tatsuhiro Tsuchiya. Combining prompts with examples to enhance llm-based requirement elicitation. In 2024 IEEE 48th Annual Computers, Software, and Applications Conference (COMPSAC) , pages 1376–1381. IEEE, 2024

    2024

  27. [35]

    Research directions for using llm in software requirement engineering: A systematic review

    Arshia Hemmat, Mohammadreza Sharbaf, Shekoufeh Kolahdouz-Rahimi, Kevin Lano, and Sobhan Y Tehrani. Research directions for using llm in software requirement engineering: A systematic review. Frontiers in Computer Science , 7:1519437, 2025

    2025

  28. [36]

    Swe-gpt: A process-centric language model for automated software improvement

    Yingwei Ma, Rongyu Cao, Yongchang Cao, Yue Zhang, Jue Chen, Yibo Liu, Yuchen Liu, Binhua Li, Fei Huang, and Yongbin Li. Swe-gpt: A process-centric language model for automated software improvement. Proceedings of the ACM on Software Engineering, 2(ISSTA):2362–2383, 2025

    2025

  29. [37]

    You name it, i run it: An llm agent to execute tests of arbitrary projects

    Islem Bouzenia and Michael Pradel. You name it, i run it: An llm agent to execute tests of arbitrary projects. Proceedings of the ACM on Software Engineering , 2(ISSTA):1054–1076, 2025

    2025

  30. [38]

    Evaluation of the choice of llm in a multi-agent solution for gui-test generation

    Stevan Tomic, Emil Alégroth, and Maycel Isaac. Evaluation of the choice of llm in a multi-agent solution for gui-test generation. In 2025 IEEE Conference on Software Testing, Verification and Validation (ICST), pages 487–497. IEEE, 2025

    2025

  31. [39]

    From llms to llm-based agents for software engineering: A survey of current, challenges and future, 2025

    Haolin Jin, Linghan Huang, Haipeng Cai, Jun Yan, Bo Li, and Huaming Chen. From llms to llm-based agents for software engineering: A survey of current, challenges and future, 2025

    2025

  32. [40]

    Repairagent: An autonomous, llm-based agent for program repair

    Islem Bouzenia, Premkumar Devanbu, and Michael Pradel. Repairagent: An autonomous, llm-based agent for program repair. In 2025 IEEE/ACM 47th Inter- national Conference on Software Engineering (ICSE) , pages 2188–2200, 2025

    2025

  33. [41]

    Au- tocoderover: Autonomous program improvement

    Yuntong Zhang, Haifeng Ruan, Zhiyu Fan, and Abhik Roychoudhury. Au- tocoderover: Autonomous program improvement. InProceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA) , page 1592–1604, New York, NY, USA, 2024. Association for Co...

    2024

  34. [42]

    SWE-agent: Agent-computer interfaces enable automated software engineering

    John Yang, Carlos E Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik R Narasimhan, and Ofir Press. SWE-agent: Agent-computer interfaces enable automated software engineering. In The Thirty-eighth Annual Conference on Neural Information Processing Systems (NeurIPS) , 2024

    2024

  35. [43]

    Codeagent: Enhancing code generation with tool-integrated agent systems for real-world repo-level coding challenges

    Kechi Zhang, Jia Li, Ge Li, Xianjie Shi, and Zhi Jin. Codeagent: Enhancing code generation with tool-integrated agent systems for real-world repo-level coding challenges. In Lun-Wei Ku, Andre Martins, and Vivek Srikumar, editors, Proceedings of the 62nd Annual Meeting of the A...

    2024

  36. [44]

    Roy, and Cristina V

    Hitesh Sajnani, Vaibhav Saini, Jeffrey Svajlenko, Chanchal K. Roy, and Cristina V. Lopes. Sourcerercc: Scaling code clone detection to big-code. In 2016 IEEE/ACM 38th International Conference on Software Engineering (ICSE) , pages 1157–1168, 2016

    2016

  37. [45]

    Binkley and Keith Brian Gallagher

    David W. Binkley and Keith Brian Gallagher. Program slicing. volume 43 of Advances in Computers, pages 1–50. Elsevier, 1996

    1996

  38. [46]

    Slicer4j: a dynamic slicer for java

    Khaled Ahmed, Mieszko Lis, and Julia Rubin. Slicer4j: a dynamic slicer for java. In Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE), page 1570–1574, New York, NY, USA, 202...

    2021

  39. [47]

    Orbs: language-independent program slicing

    David Binkley, Nicolas Gold, Mark Harman, Syed Islam, Jens Krinke, and Shin Yoo. Orbs: language-independent program slicing. InProceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering (FSE) , page 109–120, New York, NY, USA, 2014. Asso...

    2014

  40. [48]

    Kung, Geert Janssen, Wei Zhang, Giacomo Domeniconi, Vladimir Zolotov, Julian Dolby, Jie Chen, Mihir R

    Ruchir Puri, David S. Kung, Geert Janssen, Wei Zhang, Giacomo Domeniconi, Vladimir Zolotov, Julian Dolby, Jie Chen, Mihir R. Choudhury, Lindsey Decker, Veronika Thost, Luca Buratti, Saurabh Pujar, Shyam Ramji, Ulrich Finkler, Susan Malaika, and Frederick Reiss. Codenet: A larg...

    2021

  41. [49]

    René Just, Darioush Jalali, and Michael D. Ernst. Defects4j: a database of existing faults to enable controlled testing studies for java programs. In Proceedings of the 2014 International Symposium on Software Testing and Analysis (ISSTA) , page 437–440, New York, NY, USA, 201...

    2014

  42. [50]

    Bugsinpy: a database of existing bugs in python programs to enable controlled testing and debugging studies

    Ratnadira Widyasari, Sheng Qin Sim, Camellia Lok, Haodi Qi, Jack Phan, Qijin Tay, Constance Tan, Fiona Wee, Jodie Ethelda Tan, Yuheng Yieh, Brian Goh, Ferdian Thung, Hong Jin Kang, Thong Hoang, David Lo, and Eng Lieh Ouh. Bugsinpy: a database of existing bugs in python program...

    2020

  43. [51]

    Murphy, and Gabriel Murray

    Sarah Rastkar, Gail C. Murphy, and Gabriel Murray. Summarizing software artifacts: a case study of bug reports. In 2010 ACM/IEEE 32nd International Conference on Software Engineering (ICSE) , volume 1, pages 505–514, 2010

    2010

  44. [52]

    Modeling and discovering vulnerabilities with code property graphs

    Fabian Yamaguchi, Nico Golde, Daniel Arp, and Konrad Rieck. Modeling and discovering vulnerabilities with code property graphs. In 2014 IEEE Symposium on Security and Privacy (SP) , pages 590–604, 2014

    2014

  45. [53]

    Graphcodebert: Pre-training code representations with data flow, 2021

    Daya Guo, Shuo Ren, Shuai Lu, Zhangyin Feng, Duyu Tang, Shujie Liu, Long Zhou, Nan Duan, Alexey Svyatkovskiy, Shengyu Fu, Michele Tufano, Shao Kun Deng, Colin Clement, Dawn Drain, Neel Sundaresan, Jian Yin, Daxin Jiang, and Ming Zhou. Graphcodebert: Pre-training code represent...

    2021

  46. [54]

    Aidan Z. H. Yang, Claire Le Goues, Ruben Martins, and Vincent Hellendoorn. Large language models for test-free fault localization. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering (ICSE) , New York, NY, USA, 2024. Association for Computing Machinery

    2024

  47. [55]

    Incbl: incremental bug localization

    Zhou Yang, Jieke Shi, Shaowei Wang, and David Lo. Incbl: incremental bug localization. In Proceedings of the 36th IEEE/ACM International Conference on Automated Software Engineering (ASE), page 1223–1226. IEEE Press, 2022

    2022

  48. [56]

    Utilizing precise and complete code context to guide llm in automatic false positive mitigation, 2025

    Jinbao Chen, Hongjing Xiang, Zuohong Zhao, Luhao Li, Yu Zhang, Boyao Ding, Qingwei Li, and Songyuan Xiong. Utilizing precise and complete code context to guide llm in automatic false positive mitigation, 2025

    2025

  49. [57]

    Im- proving fault localization and program repair with deep semantic features and transferred knowledge

    Xiangxin Meng, Xu Wang, Hongyu Zhang, Hailong Sun, and Xudong Liu. Im- proving fault localization and program repair with deep semantic features and transferred knowledge. In 2022 IEEE/ACM 44th International Conference on Software Engineering (ICSE), pages 1169–1180, 2022

    2022

  50. [58]

    Ernst, Deric Pang, and Benjamin Keller

    Spencer Pearson, José Campos, René Just, Gordon Fraser, Rui Abreu, Michael D. Ernst, Deric Pang, and Benjamin Keller. Evaluating and improving fault localiza- tion. In 2017 IEEE/ACM 39th International Conference on Software Engineering (ICSE), pages 609–620, 2017

    2017

  51. [59]

    A model for slicing java pro- grams hierarchically

    Bixin Li, Xiaocong Fan, Jun Pang, and Jianjun Zhao. A model for slicing java pro- grams hierarchically. Journal of Computer Science and Technology , 19(6):848–858, November 2004

    2004

  52. [60]

    Slicing concurrent java programs

    Jianjun Zhao. Slicing concurrent java programs. In Proceedings Seventh Interna- tional Workshop on Program Comprehension (WPC) , pages 126–133, 1999

    1999

  53. [61]

    Barrier slicing and chopping

    Jens Krinke. Barrier slicing and chopping. In Proceedings Third IEEE International Workshop on Source Code Analysis and Manipulation (SCAM) , pages 81–87, 2003

    2003

  54. [62]

    Fink, and Rastislav Bodik

    Manu Sridharan, Stephen J. Fink, and Rastislav Bodik. Thin slicing. ACM SIG- PLAN Conference on Programming Language Design and Implementation (PLDI) , 42(6):112–122, June 2007

    2007

  55. [63]

    Vijay Krishna Palepu and James A. Jones. Discriminating influences among instructions in a dynamic slice. In Proceedings of the 29th ACM/IEEE International Conference on Automated Software Engineering (ASE) , page 37–42, New York, NY, USA, 2014. Association for Computing Machinery

    2014

  56. [64]

    Ultravcs: Ultra-fine-grained variable-based code slicing for automated vulnerability de- tection

    Tongshuai Wu, Liwei Chen, Gewangzi Du, Dan Meng, and Gang Shi. Ultravcs: Ultra-fine-grained variable-based code slicing for automated vulnerability de- tection. IEEE Transactions on Information Forensics and Security , 19:3986–4000, 2024

    2024

Pith tools

Reviewed August 15, 2026 · model on record in the stance chip above.