Pith. sign in

REVIEW 2 major objections 4 minor 34 references

AgenticRepair: Multi-Faceted Program Context Engineering for Agentic Vulnerability Repair

T0 review · 2 major / 4 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 AgenticRepair claims that engineering code-structure, runtime-execution, and commit-history context into a repair agent's memory lifts automated vulnerability repair to a 73% success rate on SEC-Bench, 29 percentage points above the…

desk verdict Solid benchmark result with a weak causal story: worth a serious referee, but the context-facet contribution needs real ablation support. read the letter →

arxiv 2607.29422 v1 pith:Z2APEQ4L submitted 2026-07-31 cs.SE cs.AIcs.CR

Michael Fu , Qiyue Mei , Patanamon Thongtanunam , Kla Tantithamthavorn This is my paper · ORCID
classification cs.SEcs.AIcs.CR
keywords agenticvulnerabilityrepairprogramcontextengineeringmulti-agentLLMsystemssanitizer-basedverificationmemory-safetyvulnerabilitiesSEC-Benchautomated
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

AgenticRepair is a multi-agent framework for automated vulnerability repair that starts from a triage report and assembles three kinds of program context before writing any patch: code-structure context (cross-file data flows and memory-operation patterns), runtime-execution context (crash signatures, backtraces, memory origins), and commit-history context (how fragile code was introduced). The authors report that on SEC-Bench, 300 real-world C/C++ vulnerabilities each verified by a runtime memory-error sanitizer, the framework fixes 220 instances (73%), beating the strongest baseline by 29 percentage points. Their ablation study argues the three context facets are complementary, since removing any one costs only 0.5 to 2.0 points, while the multi-agent scaffold and a large base model are each essential. If this result is right, an autonomous agent can turn a vulnerability description plus sanitizer trace into a verified patch for a majority of real memory-safety flaws.

What carries the argument

The load-bearing object is the engineered multi-faceted context $\mathcal{C} = \{\mathcal{C}_{\mathrm{struct}}, \mathcal{C}_{\mathrm{exec}}, \mathcal{C}_{\mathrm{hist}}\}$: three parallel LLM subagents distill static structural analysis, dynamic runtime traces, and commit history into compact structured summaries, which are then injected as a persistent episodic memory $\mathcal{M}$ that the repair subagent consults on every synthesis step. This front-loads the security diagnosis: the repair agent is conditioned on root-cause hypotheses and fix directions before it writes a patch, rather than rediscovering them through trial and error.

What would settle it

Take the 220 accepted patches and run each against additional inputs from the same vulnerable region—mutated PoCs, neighboring fuzz-corpus cases, or the project's own regression tests—and check whether any still produce a sanitizer report; if a meaningful fraction do, the stated success rate overstates how many vulnerabilities were truly eliminated.

Watch

Extended reading notes

Core claim

The paper's central claim is that deliberate, multi-faceted program context engineering—not larger models or longer context windows alone—is what makes agentic vulnerability repair work. It operationalizes this as a pipeline of three specialized subagents that compress static analysis, dynamic execution traces, and git history into a unified context embedded in the repair subagent's episodic memory, so every patch decision is conditioned on that context. The reported evidence is a 73% success rate (220/300) on SEC-Bench, with 40% of successful repairs spanning multiple files, and ablations showing that the context facets are complementary, the multi-agent scaffold contributes a 44.5-point drop when removed, and base-model capacity contributes substantially. The paper concludes that engineering program context the way a security engineer would is a key design principle for this task.

Load-bearing premise

The 73% figure counts a patch as correct when it applies, compiles, stops the provided proof-of-concept from triggering the sanitizer, and exits with code 0; a patch could pass that single input while the underlying flaw remains reachable through another input, or a different flaw could go unnoticed.

Editorial extensions

If this is right

  • Under the paper's strict success criterion, the 200-CVE success rate is 75%, against 23.5–45% for the general-purpose agents compared; if the result holds, repository-level automated patching is practical for a clear majority of disclosed C/C++ memory-safety flaws.
  • The multi-agent scaffold is load-bearing: removing it drops strict success from 75% to 30.5% even when all three context summaries are still supplied, so the paper's gain is not only about what information is gathered but about who processes it.
  • The failure split (53 of 80 failures are invalid or truncated diffs that fail git apply, 22 are harness-fatal runtime errors) implies that sanitizer-clean synthesis is not the main bottleneck; patch formatting and functional-harness acceptance are the next gates.
  • Because 40% of successful patches modify more than one file, single-function or single-file repair formulations systematically miss a large share of real vulnerabilities.

Reading between the lines

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

  • The patch-similarity numbers reported by the paper—no exact matches to the reference patches, average line-level overlap around 0.12, file-level around 0.58—suggest the benchmark is not being solved by memorized fixes; they also mean success is defined by the sanitizer oracle, so two accepted patches need not be equally robust outside the tested proof-of-concept.
  • The sharp single-agent drop is compatible with the paper's 'cognitive load' explanation, but it could equally reflect attention dilution over a long multi-source context; distinguishing those mechanisms would require an experiment that varies context length while holding the agent fixed.
  • A concrete next step implied by the paper's own failure attribution is to add a syntactic pre-validation step before patch application and to feed functional and resource-failure signals into the runtime context; the authors attribute 75 of 80 failures to these two causes.
  • The project-level spread suggests patch breadth is a separate quality axis: the lowest-scoring large project fails because accepted-looking patches are extremely broad, while successful patches are narrow, and the sanitizer oracle alone does not penalize overbroad edits.
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

2 major / 4 minor

Summary. AgenticRepair is a multi-agent LLM framework for automatically repairing C/C++ vulnerabilities from triage reports. It uses three parallel subagents to construct code-structure, runtime-execution, and commit-history contexts, embeds the synthesized context into a persistent memory for a repair subagent, and iterates a patch synthesis/verification loop. On the 300-instance SEC-Bench benchmark the paper reports a strict success rate of 73% (220/300), exceeding the strongest baseline by 29 percentage points. An ablation on the 200 CVE subset examines the contribution of each context facet, the multi-agent scaffold, and the base-model size.

Significance. If the reported results replicate, a 73% sanitizer-verified repair rate on real-world C/C++ vulnerabilities would be a substantial advance for automated vulnerability repair and a strong demonstration of context engineering. The paper is transparent in its evaluation design: it promises release of full execution logs, trajectories, and a ready-to-run implementation, and the patch-similarity analysis provides reasonable evidence against simple memorization of gold patches. The failure analysis and project/category breakdowns are also useful contributions. However, the causal conclusion that multi-faceted program context engineering is the key design principle is not yet established by the evidence presented, so the paper's significance depends on additional ablations and repeated runs.

major comments (2)
  1. [Section V, RQ2 and Table II] The evidence for the central causal claim is not sufficient. In strict mode, removing code-structure context changes success by -1.5% (3 of 200 instances), removing program-execution context by -0.5% (1 instance), and removing commit-history context by -2.0% (4 instances). These are single-run results with no confidence intervals, no repeated trials, and no significance test; for an LLM pipeline run at temperature 1.0, deltas of one to four instances are indistinguishable from sampling noise. The study also omits an all-context-off condition and single-facet-only conditions, so the data cannot distinguish 'mutually complementary' from 'near-redundant' or even 'not contributing.' The w/ Single Agent Scaffold row (-44.5%) retains all context and therefore isolates scaffolding rather than context, and the Smolagents baseline differs in scaffold, prompts, and tools simultaneously, so it cannot attribute the +29% gap to the context facets. The abstract's statement that the ablation confirms that the facets are complementary overstates what Table II supports.
  2. [Section V, RQ1 (success criterion)] The 73% headline figure is built on the benchmark oracle defined as 'the patched code compiles, prevents the original PoC from triggering the sanitizer error, and does not introduce new sanitizer-detectable issues.' Passing one provided PoC with exit code 0 is a proxy for vulnerability elimination, not a proof: a patch can bypass the supplied crashing input while leaving the same underlying flaw reachable through another input, and a single sanitizer run may not detect a newly introduced bug. The paper uses stronger language such as 'confirming successful vulnerability elimination,' and even the 'Still Vulnerable' failure category is defined with respect to the same PoC. The manuscript should either soften the claims to 'passes the provided sanitizer PoC' and add an explicit limitation, or add a supplementary validation on a sample using additional PoCs, regression tests, or manual security review.
minor comments (4)
  1. [Table I and Section V] The table caption and text state that OpenHands, SWE-Agent, and Aider were evaluated only on the 200 CVE instances, but the table's 'Total' column with dashes makes this easy to miss; add an explicit footnote warning against comparing those rows on the total.
  2. [Section III-C and Figure 7] The 'cmd' tool used throughout the trajectory analysis is never defined; specify that it is the shell-command execution tool and state what commands it can run.
  3. [Figure 9 caption] Vulnerability categories are 'inferred from benchmark text via rule matching'; the main text should describe this inference procedure, since category-level conclusions about use-after-free and double-free cases depend on it.
  4. [Section VI-B] The statement that two proposed improvements 'would address 75 out of 80 failures (93.8%)' is a projection from trajectory attribution, not a demonstrated result; it should be framed as a hypothesis or expected effect.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found: the central 73% result is an externally benchmarked outcome, and the component ablations are empirical comparisons rather than derivations from the paper's inputs.

full rationale

AgenticRepair's central claim is an empirical success rate on SEC-Bench, an external benchmark constructed by Lee et al. The paper's pipeline (context-engineering subagents, then repair subagent) is a system design, not a derivation; there is no equation in which the predicted output equals an input by construction, and no parameter is fitted to the benchmark and then reported as a prediction. The ablation rows in Table II compare actual runs with one context facet removed; the differences are small and statistically unsupported, but that is a validity or correctness concern, not circularity, because the ablated configurations are genuinely different executions rather than renamed versions of the same fit. Self-citations (e.g., Fu et al. on prior LLM repair methods) appear only in related work and are not load-bearing; the motivating example cites an external GitHub issue and SEC-Bench. No uniqueness theorem or ansatz is imported from the authors' prior work. The patch-similarity analysis provides independent evidence against contamination. Therefore the paper's results and stated comparisons are self-contained with respect to circularity; at most one might question evidential strength, which does not raise the circularity score.

Assumptions & free parameters 2 free parameters · 5 assumptions · 0 invented entities

No new physical entities, particles, forces, or conserved quantities are introduced. The episodic memory and context facets are software design components, not invented entities requiring independent evidence. The listed free parameters are hand-configured evaluation choices rather than fitted scientific constants.

free parameters (2)
  • Step budgets for subagents = 20 per context subagent; 75 for repair subagent
    Hand-configured following SEC-Bench; not fitted on a validation split, but these caps influence how many repair attempts are made and could affect success rate.
  • LLM sampling temperature = 1.0
    Fixed by the provider for GPT-5.2 reasoning-effort models; non-determinism affects reproducibility of the single-run evaluation.
assumptions (5)
  • domain assumption Sanitizer-based reproduction is a valid oracle for vulnerability elimination
    The 'correct' criterion in RQ1 requires compile success, no sanitizer error on the PoC, and no new sanitizer-detectable issues; this assumes the PoC and sanitizer cover the vulnerability.
  • domain assumption SEC-Bench is representative of real-world vulnerability repair
    Generalization claims in Section VIII rely on SEC-Bench's 300 C/C++ instances; no other language or non-sanitizer-checkable bug is evaluated.
  • domain assumption Leaderboard results for OpenHands, SWE-Agent, and Aider are comparable
    The paper reports these baselines from the SEC-Bench leaderboard without rerunning them; differences in base model, environment, and budget could affect the comparison.
  • domain assumption Single-run LLM evaluations are stable enough to support small differences
    Ablation deltas of 0.5 to 2.0 percentage points are reported without repeated runs or confidence intervals.
  • domain assumption The tool implementations (CodeQL, GDB, Valgrind, PyDriller) operate as described in the sandbox
    The paper relies on these tools, but does not ship their configurations in the preprint.

how reviews work

0 comments
Cite this review

Pith. "Pith review of AgenticRepair: Multi-Faceted Program Context Engineering for Agentic Vulnerability Repair." pith.science (2026). https://pith.science/paper/Z2APEQ4L

@misc{pith2026260729422,
  author       = {Pith},
  title        = {Pith review of: AgenticRepair: Multi-Faceted Program Context Engineering for Agentic Vulnerability Repair},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/Z2APEQ4L}},
  note         = {Machine review of arXiv:2607.29422}
}
read the original abstract

Automated vulnerability repair aims to reduce the time and effort required to patch security flaws from a vulnerability triage report. Recent agentic AI approaches have shown promising results in automated program repair. However, vulnerability repair demands richer program context than general bug repair - context that security engineers routinely assemble in practice but that existing agentic approaches do not engineer. We identify three critical gaps: code-structure context capturing cross-file data flows and memory operation patterns, runtime-execution context revealing crash semantics and memory origins, and commit-history context recovering how fragile code patterns were introduced. We present AgenticRepair, an agentic vulnerability repair framework that addresses the gaps through multi-faceted program context engineering. AgenticRepair orchestrates three specialized LLM subagents to engineer the contexts, which are then embedded into the memory of a dedicated repair subagent for context-conditioned patch synthesis. Evaluated on SEC-Bench comprising 300 real-world instances with sanitizer-based patch verification, AgenticRepair achieves a 73% success rate, substantially outperforming the strongest baseline by 29%. Our ablation study confirms that the three context facets are mutually complementary, and that multi-agent scaffolding and base-model capacity each play an essential role. Collectively, these findings establish multi-faceted program context engineering as a promising design direction for agentic vulnerability repair.

Figures

Figures reproduced from arXiv: 2607.29422 by the authors.

Figure 1
Figure 1. Comparison of the manual vulnerability remediation [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Motivating example [20]: CVE-2021-30027 in the [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Overview of our AGENTICREPAIR architecture, including three subagents (Astruct, Aexec, andAhist) for program context engineering and one subagent (Arepair) for vulnerability patch synthesis. to converge on a verified patch satisfying all sanitizer checks, which constitutes the final output of AGENTICREPAIR. C. Implementation AGENTICREPAIRis realized as a custom multi-agent orches￾tration framework built atop the smo… view at source ↗
Figures from the paper (5 more)
Figure 4
Figure 4. Figure 4: Patch generated by AGENTICREPAIR for php.ossfuzz-42501106. The top hunk shows the change in zend_create_closure_from_callable and the bottom hunk shows the change in zend_closure_from_frame. The red-to-green edits (deleted borrowed pointer assignments, added zend_strin…
Figure 5
Figure 5. Figure 5: Runtime execution context (Cexec) for php.ossfuzz-42501106. The backtrace shows the release path zend_closure_free_storage() → zend_string_release() on a previously freed zend_string* pointer (heap-use-after-free / double￾release pattern). AGENTICREPAIR against three a…
Figure 6
Figure 6. Figure 6: presents the distribution of the four failure types and the patch breadth of both successful and failed repairs. IF is the dominant failure type, accounting for 53 of the 80 failures (66.2%), followed by SV with 25 cases (31.2%). NP is rare, with only two instances, an…
Figure 8
Figure 8. Figure 8: Repair success rate by project on the 300-instance strict [PITH_FULL_IMAGE:figures/full_fig_p010_8.png]
Figure 9
Figure 9. Figure 9: Vulnerability-category success rates. Categories are [PITH_FULL_IMAGE:figures/full_fig_p011_9.png]

Review history (2 revisions) →

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

34 extracted references · 17 canonical work pages

  1. [1]

    [Online]

    Aider, “Aider,” 2026, accessed: 2026-02-26. [Online]. Available: https://aider.chat/

    work page 2026

  2. [2]

    Generating vulnerability security fixes with code language models,

    G. Bhandari, N. Gavric, and A. Shalaginov, “Generating vulnerability security fixes with code language models,”Information and Software Technology, vol. 185, p. 107786, 2025

    work page 2025

  3. [3]

    Cvefixes: automated collec- tion of vulnerabilities and their fixes from open-source software,

    G. Bhandari, A. Naseer, and L. Moonen, “Cvefixes: automated collec- tion of vulnerabilities and their fixes from open-source software,” in Proceedings of the 17th International Conference on Predictive Models and Data Analytics in Software Engineering, 2021, pp. 30–39

    2021

  4. [4]

    Identifying the characteristics of vulnerable code changes: An empirical study,

    A. Bosu, J. C. Carver, M. Hafiz, P. Hilley, and D. Janni, “Identifying the characteristics of vulnerable code changes: An empirical study,” in Proceedings of the 22nd ACM SIGSOFT international symposium on foundations of software engineering, 2014, pp. 257–268

    work page 2014

  5. [5]

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

    I. Bouzenia, P. Devanbu, and M. Pradel, “Repairagent: An autonomous, llm-based agent for program repair,” in2025 IEEE/ACM 47th Interna- tional Conference on Software Engineering (ICSE). IEEE, 2025, pp. 2188–2200

    2025

  6. [6]

    Diversevul: A new vulnerable source code dataset for deep learning based vulnerability detection,

    Y . Chen, Z. Ding, L. Alowain, X. Chen, and D. Wagner, “Diversevul: A new vulnerable source code dataset for deep learning based vulnerability detection,” inProceedings of the 26th international symposium on research in attacks, intrusions and defenses, 2023, pp. 654–668

    2023

  7. [7]

    Neural transfer learning for repairing security vulnerabilities in c code,

    Z. Chen, S. Kommrusch, and M. Monperrus, “Neural transfer learning for repairing security vulnerabilities in c code,”IEEE Transactions on Software Engineering, vol. 49, no. 1, pp. 147–165, 2022

    2022

  8. [8]

    Ac/c++ code vulnerability dataset with code changes and cve summaries,

    J. Fan, Y . Li, S. Wang, and T. N. Nguyen, “Ac/c++ code vulnerability dataset with code changes and cve summaries,” inProceedings of the 17th international conference on mining software repositories, 2020, pp. 508–512

    2020

Show all 34 references
  1. [9]

    Vision transformer inspired automated vulnerability repair,

    M. Fu, V . Nguyen, C. Tantithamthavorn, D. Phung, and T. Le, “Vision transformer inspired automated vulnerability repair,”ACM Transactions on Software Engineering and Methodology, vol. 33, no. 3, pp. 1–29, 2024

    2024

  2. [10]

    Aibughunter: A practical tool for predicting, classifying and repairing software vulnerabilities,

    M. Fu, C. Tantithamthavorn, T. Le, Y . Kume, V . Nguyen, D. Phung, and J. Grundy, “Aibughunter: A practical tool for predicting, classifying and repairing software vulnerabilities,”Empirical Software Engineering, vol. 29, no. 1, p. 4, 2024

    2024

  3. [11]

    Vulre- pair: a t5-based automated software vulnerability repair,

    M. Fu, C. Tantithamthavorn, T. Le, V . Nguyen, and D. Phung, “Vulre- pair: a t5-based automated software vulnerability repair,” inProceedings of the 30th ACM joint european software engineering conference and symposium on the foundations of software engineering, 2022, pp. 935– 947

    2022

  4. [12]

    Chatgpt for vulnerability detection, classification, and repair: How far are we?

    M. Fu, C. K. Tantithamthavorn, V . Nguyen, and T. Le, “Chatgpt for vulnerability detection, classification, and repair: How far are we?” in2023 30th Asia-Pacific Software Engineering Conference (APSEC). IEEE, 2023, pp. 632–636

    2023

  5. [13]

    Beyond tests: Program vulnerability repair via crash constraint extrac- tion,

    X. Gao, B. Wang, G. J. Duck, R. Ji, Y . Xiong, and A. Roychoudhury, “Beyond tests: Program vulnerability repair via crash constraint extrac- tion,”ACM Transactions on Software Engineering and Methodology (TOSEM), vol. 30, no. 2, pp. 1–27, 2021

    2021

  6. [14]

    Comprehensive fine- tuning large language models of code for automated program repair,

    K. Huang, J. Zhang, X. Bao, X. Wang, and Y . Liu, “Comprehensive fine- tuning large language models of code for automated program repair,” IEEE Transactions on Software Engineering, vol. 51, no. 4, pp. 904–928, 2025

    2025

  7. [15]

    Understanding vulnerability inducing commits of the linux kernel,

    M. Jiang, J. Jiang, T. Wu, Z. Ma, X. Luo, and Y . Zhou, “Understanding vulnerability inducing commits of the linux kernel,”ACM Transactions on Software Engineering and Methodology, vol. 33, no. 7, pp. 1–28, 2024

    2024

  8. [16]

    Sec-bench: Can llm agents solve critical security challenges?

    H. Lee, “Sec-bench: Can llm agents solve critical security challenges?” https://sec-bench.github.io/, 2025

    2025

  9. [17]

    Sec-bench: Automated benchmarking of llm agents on real-world software security tasks,

    H. Lee, Z. Zhang, H. Lu, and L. Zhang, “Sec-bench: Automated benchmarking of llm agents on real-world software security tasks,”arXiv preprint arXiv:2506.11791, 2025, to appear in NeurIPS 2025

    2025

  10. [18]

    Dover: Intervention-driven auto debugging for llm multi- agent systems,

    M. Ma, J. Zhang, F. Yang, Y . Kang, Q. Lin, S. Rajmohan, and 12 D. Zhang, “Dover: Intervention-driven auto debugging for llm multi- agent systems,”arXiv preprint arXiv:2512.06749, 2025

    2025

  11. [19]

    Arvo: Atlas of reproducible vulnerabilities for open source software,

    X. Mei, P. S. Singaria, J. Del Castillo, H. Xi, T. Bao, R. Wang, Y . Shoshitaishvili, A. Doup´e, H. Pearce, B. Dolan-Gavittet al., “Arvo: Atlas of reproducible vulnerabilities for open source software,”arXiv preprint arXiv:2408.02153, 2024

    2024 arXiv

  12. [20]

    Use of uninitialized value in the md analyze line() function,

    mity, “Use of uninitialized value in the md analyze line() function,” GitHub issue #155 in mity/md4c, 2021, cVE-2021-30027. [Online]. Available: https://github.com/mity/md4c/issues/155

    2021

  13. [21]

    Evaluating agent-based program repair at google,

    P. Rondon, R. Wei, J. Cambronero, J. Cito, A. Sun, S. Sanyam, M. Tufano, and S. Chandra, “Evaluating agent-based program repair at google,” in2025 IEEE/ACM 47th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP). IEEE, 2025, pp. 365–376

    2025

  14. [22]

    ‘smolagents‘: a smol library to build great agentic systems

    A. Roucher, A. V . del Moral, T. Wolf, L. von Werra, and E. Kaunism¨aki, “‘smolagents‘: a smol library to build great agentic systems.” https:// github.com/huggingface/smolagents, 2025

    2025

  15. [23]

    Patching zero-day vulnerabilities: an empirical analysis,

    Y . Roumani, “Patching zero-day vulnerabilities: an empirical analysis,” Journal of Cybersecurity, vol. 7, no. 1, p. tyab023, 2021

    2021

  16. [24]

    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

    2024 arXiv

  17. [25]

    Cybergym: Evaluating ai agents’ cybersecurity capabilities with real-world vulner- abilities at scale,

    Z. Wang, T. Shi, J. He, M. Cai, J. Zhang, and D. Song, “Cybergym: Evaluating ai agents’ cybersecurity capabilities with real-world vulner- abilities at scale,”arXiv e-prints, pp. arXiv–2506, 2025

    2025

  18. [26]

    Vul-r2: A reasoning llm for automated vulnerability repair,

    X.-C. Wen, Z. Lin, Y . Yang, C. Gao, and D. Ye, “Vul-r2: A reasoning llm for automated vulnerability repair,” in2025 40th IEEE/ACM Inter- national Conference on Automated Software Engineering (ASE). IEEE, 2025, pp. 26–38

    2025

  19. [27]

    Agentless: De- mystifying llm-based software engineering agents,

    C. S. Xia, Y . Deng, S. Dunn, and L. Zhang, “Agentless: De- mystifying llm-based software engineering agents,”arXiv preprint arXiv:2407.01489, 2024

    2024 arXiv

  20. [28]

    Automated program repair via conversation: Fixing 162 out of 337 bugs for $0.42 each using chatgpt,

    C. S. Xia and L. Zhang, “Automated program repair via conversation: Fixing 162 out of 337 bugs for $0.42 each using chatgpt,” inProceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, 2024, pp. 819–831

    2024

  21. [29]

    Modeling and discover- ing vulnerabilities with code property graphs,

    F. Yamaguchi, N. Golde, D. Arp, and K. Rieck, “Modeling and discover- ing vulnerabilities with code property graphs,” in2014 IEEE symposium on security and privacy. IEEE, 2014, pp. 590–604

    2014

  22. [30]

    Swe-agent: Agent-computer interfaces enable automated soft- ware engineering,

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

    2024

  23. [31]

    React: Synergizing reasoning and acting in language models,

    S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. R. Narasimhan, and Y . Cao, “React: Synergizing reasoning and acting in language models,” inThe eleventh international conference on learning representations, 2022

    2022

  24. [32]

    Which agent causes task failures and when? on automated failure attribution of llm multi-agent systems,

    S. Zhang, M. Yin, J. Zhang, J. Liu, Z. Han, J. Zhang, B. Li, C. Wang, H. Wang, Y . Chenet al., “Which agent causes task failures and when? on automated failure attribution of llm multi-agent systems,”arXiv preprint arXiv:2505.00212, 2025

    2025 arXiv

  25. [33]

    Autocoderover: Autonomous program improvement,

    Y . Zhang, H. Ruan, Z. Fan, and A. Roychoudhury, “Autocoderover: Autonomous program improvement,” inProceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, 2024, pp. 1592–1604

    2024

  26. [34]

    Out of sight, out of mind: Better automatic vulnerability repair by broadening input ranges and sources,

    X. Zhou, K. Kim, B. Xu, D. Han, and D. Lo, “Out of sight, out of mind: Better automatic vulnerability repair by broadening input ranges and sources,” inProceedings of the IEEE/ACM 46th international conference on software engineering, 2024, pp. 1–13

    2024

Pith tools

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