SliceMate: LLM-Driven Static Slicing

• SliceMate is a multi-agent static program slicing solution that avoids explicit PDG/SDG construction by using structured LLM agents.
• It integrates synthesis, verification, and refinement agents to iteratively generate and correct candidate slices for improved accuracy.
• Evaluated on SliceBench, SliceMate outperforms traditional and learning-based methods with significant gains in Precision, F1, and Exact-Match Accuracy.

SliceMate is a static program slicing solution powered by LLM agents that targets static backward slicing without explicit Program Dependence Graph or System Dependence Graph construction. It was introduced as a multi-agent framework for Java and Python programs, combining synthesis, verification, and refinement agents under a control module, and evaluated on SliceBench, a benchmark of 2,200 manually annotated slicing instances spanning CodeNet-derived and GitHub-derived programs (Chang et al., 25 Jul 2025).

1. Definition and problem setting

SliceMate targets static backward slicing. In the formulation used for the system, a slicing criterion is a program point together with a set of variables, and a statement belongs to the static backward slice if it may affect, directly or indirectly, the value observed at that criterion along some feasible execution. The framework explicitly considers data dependencies, control dependencies, and inter-procedural dependencies such as function calls, parameter passing, and global or field state (Chang et al., 25 Jul 2025).

The system was motivated by limitations in both traditional and learning-based slicing. Traditional static slicers construct PDGs or SDGs and solve a reachability problem, which is computationally expensive on large multi-file programs, language-specific, and brittle when code is incomplete or non-compilable. Learning-based approaches such as statement-level binary classifiers avoid some graph-construction costs, but they are upper-bounded by training labels, require large labeled datasets, and tend to over-include statements to maximize recall. SliceMate was designed to avoid explicit PDG/SDG construction, avoid supervised fine-tuning, and move from per-statement classification to structured, scoped LLM-driven generation (Chang et al., 25 Jul 2025).

The broader research landscape situates SliceMate between graph-based and neural extractive paradigms. SymPas, for example, performs context-sensitive slicing directly on LLVM IR using an Instruction Dependency Table and symbolic procedure summaries rather than PDG/SDG construction (Zhang, 2019). SliceT5, by contrast, reformulates static slicing as a sequence-to-sequence task with a copy mechanism and constrained decoding, emphasizing extractiveness and robustness to incomplete code (He et al., 22 Sep 2025). This suggests that SliceMate is best understood as a semantic reasoning architecture for slicing rather than a graph algorithm or a fine-tuned seq2seq extractor.

2. Multi-agent architecture

SliceMate is organized around four cooperating components: a control module, a synthesis agent, a verification agent, and a refinement agent (Chang et al., 25 Jul 2025).

Component	Primary role
Control module	Loop management and termination
Synthesis agent	Candidate slice generation and scope expansion
Verification agent	Conciseness and completeness checks
Refinement agent	Minimal repairs using existing code

The control module initializes the workflow by invoking the synthesis agent to produce an initial candidate slice, then iteratively alternates verification and refinement. If verification determines that the current slice is already correct, execution terminates early. Otherwise, the refinement agent revises the slice and the loop continues. The iteration bound is set to 5, selected from ablation results showing substantial F1 gains up to 5 iterations and only marginal gains beyond that point (Chang et al., 25 Jul 2025).

The synthesis agent constructs candidate slices by incremental scope expansion. It begins from a function-level initial search scope derived from the slicing criterion, then generates a slice within that scope, extracts invocation sites from the slice, resolves relevant project functions, and expands the scope accordingly. This cycle repeats until no new invocation sites appear in the generated slice. A final module-level expansion adds global variables, class fields, declarations, imports, and related modifying functions before a last slicing pass (Chang et al., 25 Jul 2025).

The verification agent operates in two stages. Conciseness analysis removes redundant lines while preserving line-level syntactic integrity and considering both data and control dependencies. Completeness analysis checks the candidate slice against the full searched scope and identifies missing dependency statements, missing control predicates, and missing structural context such as function or class definitions and necessary import or package declarations. The refinement agent then repairs the slice using the verification output, under a strict reuse-only constraint: it must add missing statements or structural elements from the searched scope and apply minimal edits rather than inventing new code (Chang et al., 25 Jul 2025).

3. Scope management, ACIs, and prompting discipline

A central feature of SliceMate is its use of Agent–Computer Interfaces. The synthesis agent can invoke four ACIs: Criterion Scope Search, Invocation Extraction, Project Function Retrieval, and Module Information Extraction. Criterion Scope Search uses Tree-sitter to locate the AST node corresponding to the criterion and returns the enclosing syntactic structure, typically the containing function or method body. Invocation Extraction identifies method or function invocations in the current slice or scope. Project Function Retrieval parses the project to recover declarations, parameter lists, enclosing classes, and inheritance context. Module Information Extraction returns global variables or class fields referenced in the slice, their declarations, functions that modify them, and additional structural elements such as package, module, class, and import declarations (Chang et al., 25 Jul 2025).

This design reflects an explicit scope-control strategy. Whole-file input is treated as too large and noisy for LLM context, so the system starts at function granularity and expands only when inferred call relationships or module-level state demand it. The expansion process is therefore not whole-program graph traversal, but iterative semantic retrieval guided by the LLM and constrained by structural metadata (Chang et al., 25 Jul 2025).

SliceMate uses GPT-4o with temperature $0$. Prompting is role-specialized: the synthesis prompt defines the slicing task and dependency notions, the scope-expansion prompt matches call sites to relevant definitions, the conciseness prompt removes redundant lines, the completeness prompt acts as an inspector over the full searched scope, and the refinement prompt repairs slices using only existing code. The prompts enforce structured input and output, including filename-tagged code segments and explicit listings of missing elements. The reuse-only constraint is intended to reduce hallucination, while the decomposition into synthesis, verification, and refinement reduces role overload relative to single-shot prompting (Chang et al., 25 Jul 2025).

The importance of controlled generation connects SliceMate to parallel developments in learning-based slicing. SliceT5 also treats slicing as structured generation, but it enforces extractiveness through a copy mechanism and constrained decoding with lexical and TSED-based syntactic constraints, rather than through multi-agent prompting and verification loops (He et al., 22 Sep 2025). A plausible implication is that the two lines of work address a common problem—faithful slice construction—but impose control at different layers of the system stack.

4. Benchmark construction and empirical performance

SliceMate was evaluated on SliceBench, a benchmark of 2,200 manually annotated static slicing instances. SliceBench contains 1,000 Java and 1,000 Python CodeNet-derived programs, plus 100 Java Defects4J programs and 100 Python BugsInPy programs. The CodeNet programs are typically around 30 lines and usually single-function, while the GitHub-derived programs average about 2,106 statements and include multiple files, functions, and cross-file dependencies. The criterion is the final print statement for CodeNet and the failing test unit’s assert statement for the GitHub programs (Chang et al., 25 Jul 2025).

Annotation was performed by 8 experts: 2 professors specializing in program slicing, 2 PhD students, and 4 MSc students, all with at least 4 years of programming experience and knowledge of slicing. Each slice was independently annotated by two annotators, with disagreements resolved by one of the professors. Average Cohen’s $\kappa$ was $0.927$ for CodeNet programs and $0.893$ for GitHub programs (Chang et al., 25 Jul 2025).

Evaluation uses statement-level metrics: $$\text{Accuracy} = \frac{\text{TP} + \text{TN}}{\text{TP} + \text{FP} + \text{FN} + \text{TN}},$$

$$\text{Precision} = \frac{\text{TP}}{\text{TP} + \text{FP}},$$

$$\text{Recall} = \frac{\text{TP}}{\text{TP} + \text{FN}},$$

$$\text{F1} = \frac{2 \cdot \text{Precision} \cdot \text{Recall}}{\text{Precision} + \text{Recall}}.$$

A stricter metric, Accuracy-EM, measures the proportion of instances for which the predicted slice exactly matches the ground-truth slice as a line set (Chang et al., 25 Jul 2025).

On SliceBench-CodeNet, SliceMate achieved the best reported results on both Python and Java. For Python, it obtained Precision $0.975$, Recall $0.952$, F1 $\kappa$0, Acc-EM $\kappa$1, and Accuracy $\kappa$2, compared with the best baseline NS-Slicer Pro at Precision $\kappa$3, Recall $\kappa$4, F1 $\kappa$5, Acc-EM $\kappa$6, and Accuracy $\kappa$7. For Java, SliceMate obtained Precision $\kappa$8, Recall $\kappa$9, F1 $0.927$0, Acc-EM $0.927$1, and Accuracy $0.927$2, again exceeding NS-Slicer Pro, which reached Precision $0.927$3, Recall $0.927$4, F1 $0.927$5, Acc-EM $0.927$6, and Accuracy $0.927$7 (Chang et al., 25 Jul 2025).

The GitHub setting is more revealing because of scale and inter-procedural complexity. On Python GitHub programs, SliceMate achieved Precision $0.927$8, Recall $0.927$9, F1 $0.893$0, Acc-EM $0.893$1, and Accuracy $0.893$2, while the best baseline by F1, NS-Slicer Pro, obtained Precision $0.893$3, Recall $0.893$4, F1 $0.893$5, Acc-EM $0.893$6, and Accuracy $0.893$7. On Java GitHub programs, SliceMate achieved Precision $0.893$8, Recall $0.893$9, F1 $$\text{Accuracy} = \frac{\text{TP} + \text{TN}}{\text{TP} + \text{FP} + \text{FN} + \text{TN}},$$0, Acc-EM $$\text{Accuracy} = \frac{\text{TP} + \text{TN}}{\text{TP} + \text{FP} + \text{FN} + \text{TN}},$$1, and Accuracy $$\text{Accuracy} = \frac{\text{TP} + \text{TN}}{\text{TP} + \text{FP} + \text{FN} + \text{TN}},$$2; the strongest baseline by F1 was TypeSlicer at F1 $$\text{Accuracy} = \frac{\text{TP} + \text{TN}}{\text{TP} + \text{FP} + \text{FN} + \text{TN}},$$3 and Accuracy $$\text{Accuracy} = \frac{\text{TP} + \text{TN}}{\text{TP} + \text{FP} + \text{FN} + \text{TN}},$$4 (Chang et al., 25 Jul 2025).

The framework’s contribution is not limited to intrinsic slicing metrics. The reported downstream results state average improvements on SliceBench of $$\text{Accuracy} = \frac{\text{TP} + \text{TN}}{\text{TP} + \text{FP} + \text{FN} + \text{TN}},$$5 in Accuracy, $$\text{Accuracy} = \frac{\text{TP} + \text{TN}}{\text{TP} + \text{FP} + \text{FN} + \text{TN}},$$6 in F1, and $$\text{Accuracy} = \frac{\text{TP} + \text{TN}}{\text{TP} + \text{FP} + \text{FN} + \text{TN}},$$7 in Accuracy-EM, with gains on large-scale programs reaching up to $$\text{Accuracy} = \frac{\text{TP} + \text{TN}}{\text{TP} + \text{FP} + \text{FN} + \text{TN}},$$8 higher Accuracy and $$\text{Accuracy} = \frac{\text{TP} + \text{TN}}{\text{TP} + \text{FP} + \text{FN} + \text{TN}},$$9 higher F1. For debugging, Ratio$$\text{Precision} = \frac{\text{TP}}{\text{TP} + \text{FP}},$$0 and Ratio$$\text{Precision} = \frac{\text{TP}}{\text{TP} + \text{FP}},$$1 improve by up to about $$\text{Precision} = \frac{\text{TP}}{\text{TP} + \text{FP}},$$2 over the best baseline, and bug localization Top-10 accuracy improves by up to $$\text{Precision} = \frac{\text{TP}}{\text{TP} + \text{FP}},$$3 when slices are used with IncBL and LLM4FPM (Chang et al., 25 Jul 2025).

5. Ablation findings and operational characteristics

The principal ablation compares full SliceMate with SliceMate$$\text{Precision} = \frac{\text{TP}}{\text{TP} + \text{FP}},$$4, a variant that removes verification and refinement and relies only on the synthesis agent. The results indicate that the multi-agent loop is not a cosmetic addition but a major source of performance (Chang et al., 25 Jul 2025).

On CodeNet Python, SliceMate$$\text{Precision} = \frac{\text{TP}}{\text{TP} + \text{FP}},$$5 achieved Precision $$\text{Precision} = \frac{\text{TP}}{\text{TP} + \text{FP}},$$6, Recall $$\text{Precision} = \frac{\text{TP}}{\text{TP} + \text{FP}},$$7, F1 $$\text{Precision} = \frac{\text{TP}}{\text{TP} + \text{FP}},$$8, Acc-EM $$\text{Precision} = \frac{\text{TP}}{\text{TP} + \text{FP}},$$9, and Accuracy $$\text{Recall} = \frac{\text{TP}}{\text{TP} + \text{FN}},$$0, whereas full SliceMate reached Precision $$\text{Recall} = \frac{\text{TP}}{\text{TP} + \text{FN}},$$1, Recall $$\text{Recall} = \frac{\text{TP}}{\text{TP} + \text{FN}},$$2, F1 $$\text{Recall} = \frac{\text{TP}}{\text{TP} + \text{FN}},$$3, Acc-EM $$\text{Recall} = \frac{\text{TP}}{\text{TP} + \text{FN}},$$4, and Accuracy $$\text{Recall} = \frac{\text{TP}}{\text{TP} + \text{FN}},$$5. On CodeNet Java, F1 rose from $$\text{Recall} = \frac{\text{TP}}{\text{TP} + \text{FN}},$$6 to $$\text{Recall} = \frac{\text{TP}}{\text{TP} + \text{FN}},$$7, Accuracy from $$\text{Recall} = \frac{\text{TP}}{\text{TP} + \text{FN}},$$8 to $$\text{Recall} = \frac{\text{TP}}{\text{TP} + \text{FN}},$$9, and Acc-EM from $$\text{F1} = \frac{2 \cdot \text{Precision} \cdot \text{Recall}}{\text{Precision} + \text{Recall}}.$$0 to $$\text{F1} = \frac{2 \cdot \text{Precision} \cdot \text{Recall}}{\text{Precision} + \text{Recall}}.$$1. On GitHub Python, F1 rose from $$\text{F1} = \frac{2 \cdot \text{Precision} \cdot \text{Recall}}{\text{Precision} + \text{Recall}}.$$2 to $$\text{F1} = \frac{2 \cdot \text{Precision} \cdot \text{Recall}}{\text{Precision} + \text{Recall}}.$$3, and on GitHub Java from $$\text{F1} = \frac{2 \cdot \text{Precision} \cdot \text{Recall}}{\text{Precision} + \text{Recall}}.$$4 to $$\text{F1} = \frac{2 \cdot \text{Precision} \cdot \text{Recall}}{\text{Precision} + \text{Recall}}.$$5 (Chang et al., 25 Jul 2025).

The iteration study shows that F1 increases substantially from 1 to 5 verification–refinement iterations for both Python and Java, then approaches a plateau. The paper therefore fixes the maximum iteration count at 5. This operational choice balances quality against the cost of repeated LLM calls and guards against unstable over-correction (Chang et al., 25 Jul 2025).

The framework also has explicit economic and scalability characteristics. SliceMate uses GPT-4o via API, and the reported cost is about $$\text{F1} = \frac{2 \cdot \text{Precision} \cdot \text{Recall}}{\text{Precision} + \text{Recall}}.$$6 per slice for large-scale programs. The system handles programs up to 8,577 lines by combining function-level scoping with incremental expansion, rather than constructing whole-program dependency graphs (Chang et al., 25 Jul 2025).

A recurring misconception is that SliceMate is simply a prompting wrapper around a general-purpose LLM. The ablation results argue against that interpretation: single-agent generation performs substantially worse, especially on Exact-Match Accuracy. Another misconception is that it offers formal soundness or completeness guarantees comparable to classical dependence analysis. The paper explicitly states that SliceMate is not formally sound or complete in the static-analysis sense; its strength is empirical slicing quality rather than proof-theoretic guarantees (Chang et al., 25 Jul 2025).

6. Relation to other slicing paradigms and broader usage of the name

SliceMate belongs to a heterogeneous family of slicing techniques. SymPas represents one classical but non-graph-centric path: it performs slicing as data-flow analysis directly over LLVM IR, stores instruction-level dependences in an Instruction Dependency Table, and uses symbolic or parameterized procedure slices to avoid re-analyzing callees in each calling context. Its backward slicing was reported to reduce time cost by a factor of 6 and space cost by a factor of 4 relative to backward SDG-IFDS, while remaining highly size-scalable on programs up to 336,800 IR instructions (Zhang, 2019). This is a different notion of scalability from SliceMate’s, grounded in summary-based static analysis rather than LLM inference.

Another distinct lineage is the incremental slicing of functional programs. That work models slicing criteria as demands over access paths, computes context-independent function summaries, and constructs completing automata during a one-time pre-computation phase so that later slicing with respect to a new criterion reduces to automaton intersection. The incremental step was reported to run orders of magnitude faster than the non-incremental version (K. et al., 2017). This suggests a design contrast: SliceMate optimizes repeated reasoning through scoped generation and iterative correction, whereas incremental demand-based slicing optimizes repeated reasoning through precomputed criterion-indexed summaries.

SliceT5 occupies yet another point in the design space. It reformulates static slicing as a sequence-to-sequence task over code tokens, uses CodeT5 or CodeT5+ with a copy mechanism, and constrains decoding lexically and syntactically so that outputs remain extractive and structurally valid. On CodeNet and LeetCode, it improved ExactMatch by up to $$\text{F1} = \frac{2 \cdot \text{Precision} \cdot \text{Recall}}{\text{Precision} + \text{Recall}}.$$7 over prior baselines and showed strong robustness on incomplete code (He et al., 22 Sep 2025). In adjacent discussions, the name “SliceMate” is used as a natural label for a developer-facing tool that could wrap such a SliceT5-style core. This suggests that the term has begun to function both as the name of the specific multi-agent system and as a broader tool concept for practical slicing assistance.

A further extension appears in security-oriented code reduction for npm malware detection. There, a SliceMate-like architecture is described as a taint-based slicing front end that feeds semantically dense slices to an LLM classifier. Using DeepSeek-Coder-6.7B and Node.js-specific taint-based slicing, the system reduced input volume by over $$\text{F1} = \frac{2 \cdot \text{Precision} \cdot \text{Recall}}{\text{Precision} + \text{Recall}}.$$8 while achieving $$\text{F1} = \frac{2 \cdot \text{Precision} \cdot \text{Recall}}{\text{Precision} + \text{Recall}}.$$9 detection accuracy, outperforming naive token splitting at $0.975$0 and a traditional static-analysis baseline (Nguyen et al., 13 Dec 2025). This broader usage indicates that “SliceMate” also denotes, in practice, a family resemblance: slicing as structured preselection for downstream reasoning systems.

7. Limitations, controversies, and future directions

SliceMate’s principal limitation is epistemic rather than empirical. It is not formally sound or complete, and the paper does not provide a proof that every statement that may affect the criterion is included. The system depends on GPT-4o, on prompt design, and on the adequacy of Tree-sitter-derived structure and ACI-retrieved context. Highly dynamic behavior, reflection, dynamic imports, and similar features remain challenging (Chang et al., 25 Jul 2025).

Its Exact-Match Accuracy on large multi-file GitHub programs remains low despite strong F1 and Accuracy: $0.975$1 for Python and $0.975$2 for Java. This indicates that the system often produces useful but not line-perfect slices at large scale. The paper also notes trade-offs in cost and latency, since the multi-agent workflow requires multiple API calls, and it identifies context-window limits as a continuing constraint mitigated, but not eliminated, by function-level scope control (Chang et al., 25 Jul 2025).

The comparison with other slicing paradigms clarifies the controversy around what counts as “accurate” slicing. Classical methods such as SymPas can claim equivalence to SDG-based slices under stated assumptions (Zhang, 2019), while demand-based incremental slicing can claim correctness relative to its non-incremental formulation (K. et al., 2017). SliceMate instead claims practical superiority on manually annotated benchmarks and on debugging and localization tasks. This suggests that current research distinguishes at least three evaluative regimes: formal semantic equivalence, benchmark-level agreement with human annotation, and downstream utility.

Future work identified in the SliceMate paper includes dynamic slicing, extension to additional languages beyond Java and Python, tighter integration with IDEs and analysis tools, and hybridization with lightweight static analysis. Related work points toward several concrete directions: combining SliceMate-style verification loops with SliceT5-style constrained generation (He et al., 22 Sep 2025), using symbolic summaries or IR-level caches for repeated interactive queries (Zhang, 2019), or using sliced outputs as high-signal prompts in security pipelines (Nguyen et al., 13 Dec 2025). A plausible implication is that the long-term significance of SliceMate may lie not only in its current architecture, but also in establishing multi-agent, structure-aware slicing as a reusable pattern for software-analysis systems.