Pith. sign in

REVIEW 4 major objections 5 minor 1 cited by

PAGENT: Learning to Patch Software Engineering Agents

T0 review · 4 major / 5 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 A post-processing layer that combines static program analysis with an LLM can convert a meaningful fraction of failed AI-generated patches into passing fixes.

desk verdict The failure taxonomy is a genuine empirical contribution, but the headline 22.83% improvement rate is unsupported by the paper's own numbers; the underlying PAGENT idea still deserves a serious look. read the letter →

arxiv 2506.17772 v1 pith:7ZQDKRBO submitted 2025-06-21 cs.SE

Haoran Xue , Gias Uddin , Song Wang This is my paper · ORCID
classification cs.SE
keywords automatedprogramrepairLLM-basedsoftwareagentsfailuretaxonomytypeinferencestaticanalysiscontrolflowgraphSWE-benchLitepatchrewriting
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

This paper asks why LLM-based issue-resolution agents fail and whether those failures can be repaired after the fact. Studying 114 issues from SWE-bench Lite that none of seven agents could resolve, it classifies 769 failed patches into six failure patterns, finding that insufficient data-type and structure handling is one of the most common causes. To exploit that finding, it builds PAGENT, a post-processing layer that statically analyzes the repository around a patch, infers variable types, and rewrites the patch accordingly. On 127 type-related failed patches from three agents, PAGENT turned 29 into passing patches, a 22.83% improvement rate. The result matters because it suggests that a targeted, model-agnostic repair step can salvage a substantial share of failures that otherwise look like general LLM limitations.

What carries the argument

The machinery is PAGENT's four-stage pipeline: a patch analysis module that validates diff format and syntax; a code analysis module that parses the repository into abstract syntax trees, builds control-flow graphs, and runs reaching-definitions analysis to track what values a variable can hold; a type inference system that combines these static results with an LLM's contextual judgment to assign types; and a patch rewriter that regenerates the diff and checks it with a static type checker. The control-flow graph and reaching-definitions analysis do the load-bearing work of overcoming localized patch inspection by tracing type flow across execution paths.

What would settle it

Reclassify the 769 failed patches with two independent human annotators who are blind to PAGENT's outcome, then count how many of PAGENT's 29 fixed patches fall outside the type-related label; if more than a handful fall outside, the 22.83% rate reflects label selection rather than type repair.

Watch

Extended reading notes

Core claim

The central claim is that type-related patch failures form an identifiable, separable failure class, and that a hybrid static-analysis-plus-LLM post-processor can repair roughly one in five of them. The paper states this as 29 resolved patches out of 127 previously failed type-related patches, a 22.83% improvement rate. It also claims the empirical taxonomy identifies six failure patterns—type and data structure handling, shallow code-context understanding, inadequate error handling, limited integration with existing utilities, cross-version compatibility, and performance implications—with type handling and code context among the most frequent.

Load-bearing premise

The whole 29-fix result rests on the assumption that the LLM-assisted manual review correctly identified which failed patches were type-related, because that label determines both the 127-patch test set and the claimed 22.83% improvement rate.

Editorial extensions

If this is right

  • A post-processing layer can raise an agent's effective pass rate without retraining the agent, with the reported gains coming from three different base agents whose type-related failures were most frequent.
  • The failed-patch taxonomy provides a route to build other targeted repair tools, since each category names a specific, localized failure mechanism rather than leaving failures as a general LLM weakness.
  • Type-related errors involving complex nested data structures are the most tractable for this static-analysis approach, since they made up 44.4% of the 18 unique issues PAGENT fixed.
  • Agents whose original patches already handle types adequately gain nothing from this repair layer, since four of the seven evaluated agents showed no improvement.

Reading between the lines

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

  • Because the 127-patch test set is defined by the taxonomy labels, an independent re-labeling of the same 769 failures would show whether the 22.83% rate is really about types or about some correlated property of the patches.
  • The same CFG-plus-LLM pipeline could plausibly be applied to other taxonomy categories, such as missing error handling or overlooked utility functions, but the paper does not test that.
  • The paper's own unfixed-case analysis suggests the ceiling is structural: even with correct type information, patches fail when fixes require multi-module architectural reasoning or domain-specific API knowledge.
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

4 major / 5 minor

Summary. The paper reports an empirical study of failed patches produced by seven LLM-based issue-resolution agents on 114 SWE-bench Lite issues, presenting a taxonomy of six failure categories. The authors identify insufficient type and data structure handling as a frequent and addressable failure mode, and propose PAGENT, a post-processing agent that combines AST parsing, CFG construction, reaching-definitions analysis, LLM-based type refinement, and mypy-aware rewriting. PAGENT is applied to previously failed type-related patches, and the abstract and RQ1 report that it fixed 29 of 127 such patches, a 22.83% improvement rate, with model-specific gains for Aider, Agentless, and AutoCodeRover. The paper also analyzes the sub-categories of successfully fixed type-related issues.

Significance. If the empirical claims are correct, the work has two useful contributions: a structured taxonomy of failure modes for LLM code agents, and a concrete demonstration that targeted static analysis plus type inference can rescue a meaningful fraction of failed patches. The evaluation uses the external SWE-bench Lite harness through the Moatless platform, which is a strength because the headline result is measured by real test execution rather than by the authors' own proxy. The PAGENT design is clear and the worked examples are instructive. However, the central quantitative claim is currently not reproducible from the paper's own tables and sections, and the evaluation lacks a baseline that separates the contribution of static analysis from that of the LLM rewriting step. These issues must be resolved before the reported improvement rate can be accepted.

major comments (4)
  1. [Abstract, §5.2, Table 3, §5.1, §8] The headline result, 29 of 127 type-related failed patches (22.83%), is not derivable from the paper's own counts. Table 3 reports type-and-data-structure counts of 17, 14, and 13 for Agentless, Aider, and AutoCodeRover, respectively; these three sum to 44, and all seven agents sum to 98. Section 5.1 says there are 762 patches representing 37.34% of all failed patch attempts, which would imply roughly 284 type-related patches, not 127. Section 8 reports a 9.37% improvement rate, which for 29 fixes implies a denominator near 310. These numbers cannot all describe the same evaluation set, so the 22.83% rate and the conclusion's 9.37% rate are internally inconsistent. The authors must provide a consistent accounting of the evaluation set and recompute all rates.
  2. [§2.3, §6.2] The taxonomy that drives the selection of the 127 type-related patches (or whatever the correct denominator is) is produced by GPT-4o plus manual review, but no inter-rater reliability or validation of the labels is reported. Since the central claim depends on correctly identifying which failed patches are type-related, the absence of any agreement metric makes the result vulnerable to categorization bias that Section 6.2 itself acknowledges. I ask for at least a quantified agreement measure on a sample of labels, or an alternative validation of the labeling procedure.
  3. [§4, §5] There is no baseline or ablation that isolates the contribution of the static-analysis components (AST, CFG, reaching definitions) from the contribution of the LLM-based type refinement and patch rewriting. Without a condition that, for example, feeds the same failed patches to an LLM rewriter without the static-analysis context, or applies static analysis without the LLM refinement, it is not possible to attribute the 29 fixes to PAGENT's claimed novelty. Reporting such an ablation is necessary to support the paper's central design claim.
  4. [§5.3, Table 5] The model-specific improvement rates in Table 5 are expressed relative to each agent's total success rate on 300 issues, but PAGENT is applied only to a subset of previously failed patches. The correct denominator for a patch-level improvement rate is the set of type-related failed patches per agent, not the full 300-issue set. As reported, the 'relative gain' conflates patch-level fixes with overall issue-level success rates and is therefore difficult to interpret. Please report, per agent, the number of type-related failed patches and the number of those that PAGENT fixed.
minor comments (5)
  1. [§5.2] The text says PAGENT was applied to type-related failures 'cross all seven agents' but then reports results only for three agents; please clarify whether the evaluation set was the top three agents or all seven, and reconcile this with the abstract's statement about the top three agents.
  2. [§5.1] The sentence 'In total, there are 762 patches, representing approximately 37.34% of all failed patch attempts' is confusing: based on the data collection in §2.2, 769 cases were processed (with 29 excluded), so 762 cannot represent 37.34% of the total. Please clarify what 762 counts and what the 37.34% refers to.
  3. [§3.7, Table 3] The percentages in Figure 3 do not appear to be directly derivable from the raw counts in Table 3; for example, the type-handling percentage of 37.34% is not consistent with 98 out of the total failures shown in Table 3. Please explain the computation or the relationship between the figure and the table.
  4. [§4.5, Table 4] There are several typos that should be corrected: 'Optinal' should be 'Optional', 'endwith' should be 'endswith', 'Meatless' should be 'Moatless' in §2.2, 'leafing' should be 'leading' in §3.6, and the agent name 'AppMap Naive' is spelled inconsistently as 'Navie' in several places.
  5. [§5.4, Figure 8] The paper reports 18 unique issues across 29 total occurrences, but does not state how the overlap across agents is handled when computing the 22.83% improvement rate; please clarify whether the 29 fixes are counted per agent or per unique issue, since the abstract's '29 patches' suggests per-patch counting while RQ3 uses unique issues.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found: PAGENT's 29/127 improvement is measured against external SWE-bench tests, not derived from its inputs.

full rationale

The central claim, 'PAGENT successfully resolved 29 of 127 previously failed patches with type and data structure handling problems' (Section 5.2), is an empirical outcome checked on the Moatless evaluation platform against SWE-bench Lite test suites, not an algebraic consequence of PAGENT's design. The taxonomy (Section 3) and PAGENT's type-inference pipeline (Section 4.4) do not define success in terms of the taxonomy: a patch counts as fixed only if it passes the external tests. The 'type-related' labeling uses GPT-4o plus manual review, and PAGENT also uses an LLM for type refinement, but the final verdict is independent of the LLM's self-assessment. No parameter is fitted to the test outcome, no self-citation chain supplies the 29 successes, and no equation in the paper reduces the headline rate to its own assumptions. The paper does contain a numeric inconsistency in the denominator (Table 3 sums to 44 type-related patches for the top three agents, while Section 5.2 uses 127; Section 3.7 implies roughly 284), but that is an internal accounting problem that should be checked for correctness, not an instance of circular reasoning.

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

No numeric free parameters are fitted; the selection choices (seven agents, 114 common failures, 127 type-related patches, GPT-4o as analyzer/rewriter) are methodological choices rather than fitted constants. The central empirical claims rest on benchmark validity, taxonomy reliability, and the representative nature of the evaluated subset.

assumptions (4)
  • domain assumption SWE-bench Lite gold patches and test failures are a correct oracle for what counts as a resolved issue.
    Both the taxonomy and PAGENT evaluation treat SWE-bench tests and gold patches as ground truth (Section 2.2, Section 5.1).
  • domain assumption GPT-4o-generated failure reports, after manual review, identify true root causes of failed patches.
    The taxonomy is built from these reports; the authors concede possible categorization bias in Section 6.2 and report no inter-rater reliability.
  • domain assumption AST parsing, CFG construction, and reaching-definitions analysis, combined with LLM inference, can recover the type information relevant to a patch's failure.
    PAGENT's design assumes this in Sections 4.3 and 4.4; no ablation shows the static component is responsible for the fixes.
  • ad hoc to paper The 127 type-related patches from the top three agents are representative of type-related failures across the seven agents.
    PAGENT is only evaluated on this subset (Section 5.2, Section 5.3); generalizing to other agents or the full failure set is assumed.

how reviews work

0 comments
Cite this review

Pith. "Pith review of PAGENT: Learning to Patch Software Engineering Agents." pith.science (2026). https://pith.science/paper/7ZQDKRBO

@misc{pith2026250617772,
  author       = {Pith},
  title        = {Pith review of: PAGENT: Learning to Patch Software Engineering Agents},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7ZQDKRBO}},
  note         = {Machine review of arXiv:2506.17772}
}
read the original abstract

LLM Agents produce patches automatically to resolve an issue. However, they can generate inaccurate patches. Little is known about the root causes behind those failed patches or how those could be fixed. This paper reports an empirical study of the failed patches generated by seven top LLM code agents. We collected 114 issues from the SWE-bench Lite dataset that remained unresolved across the agents. The seven agents produced a total of 769 failed patches for those issues, which we checked with a combination of GPT-4o and manual analysis. We present a taxonomy of the failure reasons across the patches. The taxonomy contains six categories, with several sub-categories under each category. For example, a frequently observed category is the inability of an LLM to correctly infer/produce the appropriate variable type in the produced patch. As a first step towards addressing such type-related errors, we designed PAGENT (Patch Agent). PAGENT utilizes program analysis techniques like CFG creation and exploration to infer the type of information of a patch. PAGENT does this by applying repository-level static code analysis techniques. Then, PAGENT refines the inferred type by further utilizing an LLM-based inference technique. We tested PAGENT on all 127 type-related failed patches from the top three agents in our study. PAGENT could fix 29 of the 127 failed patches.

Figures

Figures reproduced from arXiv: 2506.17772 by the authors.

Figure 1
Figure 1. Analysis steps for failed patches from LLM agents [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Taxonomy of Failed Patches in Issue Resolution Agents [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Distribution of Analyzed Patches Across Categories [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (5 more)
Figure 4
Figure 4. Figure 4: Overall workflow of PAGENT appear in specific execution scenarios. These analysis techniques allow us to build a comprehensive understanding of the code con￾text surrounding the variables and expressions in the patch. This is essential for accurately inferring types an…
Figure 5
Figure 5. Figure 5: An example of how PAGENT processes an issue of django__django-14534 to refine it progressively RQ2. How effective is PAGENT in improving the performance of existing models? RQ3. How effective is PAGENT in handling the sub-categories of type-related issues? 5.1 Experime…
Figure 6
Figure 6. Figure 6: Distribution of unfixed patches across subcategories [PITH_FULL_IMAGE:figures/full_fig_p008_6.png]
Figure 7
Figure 7. Figure 7: Distribution of fixed patches across subcategories [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]
Figure 8
Figure 8. Figure 8: Number of fixed patches in each subcategory [PITH_FULL_IMAGE:figures/full_fig_p009_8.png]

Review history (2 revisions) →

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. One Tool Is Enough: Reinforcement Learning for Repository-Level LLM Agents

    cs.SE 2025-12 conditional novelty 6.0 of 10

    Repository-level issue localization can be done by a single jump-to-definition tool trained with reinforcement learning, achieving strong results on SWE-bench despite using only open-weights models.

Reference graph

Works this paper leans on

37 extracted references · 6 canonical work pages · cited by 1 Pith paper

  1. [1]

    Toufique Ahmed, Jatin Ganhotra, Rangeet Pan, Avraham Shinnar, Saurabh Sinha, and Martin Hirzel. 2025. Otter: Generating Tests from Issues to Validate SWE Patches. arXiv:2502.05368 [cs.SE] https://arxiv.org/abs/2502.05368

    arXiv 2025

  2. [2]

    Anthropic. 2024. Claude 3.5 Sonnet. https://www.anthropic.com/news/claude- 3-5-sonnet Accessed: 2025-03-13

    work page 2024

  3. [3]

    Bissyandé, David Lo, Lingxiao Jiang, Laurent Réveillère, Jacques Klein, and Yves Le Traon

    Tegawendé F. Bissyandé, David Lo, Lingxiao Jiang, Laurent Réveillère, Jacques Klein, and Yves Le Traon. 2013. Got issues? Who cares about it? A large scale investigation of issue trackers from GitHub. In 2013 IEEE 24th International Symposium on Software Reliability Engineering (ISSRE) . 188–197. https://doi.org/ 10.1109/ISSRE.2013.6698918

    work page arXiv 2013

  4. [4]

    Islem Bouzenia, Premkumar Devanbu, and Michael Pradel. 2024. RepairAgent: An Autonomous, LLM-Based Agent for Program Repair. arXiv:2403.17134 [cs.SE] https://arxiv.org/abs/2403.17134

    arXiv 2024

  5. [5]

    Dustin Byrne. 2024. AppMap: Specification for AppMap Clients. https://github. com/getappmap/appmap Accessed: 2025-03-13

    work page 2024

  6. [6]

    Zhiheng Xi et al. 2023. The Rise and Potential of Large Language Model Based Agents: A Survey. arXiv:2309.07864 [cs.AI] https://arxiv.org/abs/2309.07864

    arXiv 2023

  7. [7]

    Angela Fan, Beliz Gokkaya, Mark Harman, Mitya Lyubarskiy, Shubho Sengupta, Shin Yoo, and Jie M. Zhang. 2023. Large Language Models for Software Engi- neering: Survey and Open Problems. In 2023 IEEE/ACM International Confer- ence on Software Engineering: Future of Software Engineering (ICSE-FoSE) . 31–53. https://doi.org/10.1109/ICSE-FoSE59343.2023.00008

    arXiv 2023

  8. [8]

    Zhiyu Fan, Xiang Gao, Martin Mirchev, Abhik Roychoudhury, and Shin Hwei Tan. 2023. Automated Repair of Programs from Large Language Models. arXiv:2205.10583 [cs.SE] https://arxiv.org/abs/2205.10583

    arXiv 2023

Show all 37 references
  1. [9]

    Paul Gauthier. 2024. Aider: AI Pair Programming in Your Terminal. https: //aider.chat Accessed: 2025-03-13

    2024

  2. [10]

    Junda He, Christoph Treude, and David Lo. 2024. LLM-Based Multi-Agent Sys- tems for Software Engineering: Literature Review, Vision and the Road Ahead. arXiv:2404.04834 [cs.SE] https://arxiv.org/abs/2404.04834

    2024 arXiv

  3. [11]

    Xinyi Hou, Yanjie Zhao, Yue Liu, Zhou Yang, Kailong Wang, Li Li, Xiapu Luo, David Lo, John Grundy, and Haoyu Wang. 2024. Large Language Models for Software Engineering: A Systematic Literature Review. ACM Trans. Softw. Eng. Methodol. 33, 8, Article 220 (Dec. 2024), 79 pages. h...

    2024 doi

  4. [12]

    Nan Jiang, Kevin Liu, Thibaud Lutellier, and Lin Tan. 2023. Impact of Code Language Models on Automated Program Repair. arXiv:2302.05020 [cs.SE] https://arxiv.org/abs/2302.05020

    2023 arXiv

  5. [13]

    Yanjie Jiang, Hui Liu, Nan Niu, Lu Zhang, and Yamin Hu. 2021. Extracting Concise Bug-Fixing Patches from Human-Written Patches in Version Control Systems. In Proceedings of the 43rd International Conference on Software Engineering (ICSE) . IEEE/ACM, 686–698. https://doi.org/10...

    2021

  6. [14]

    Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. 2023. Swe-bench: Can language models resolve real-world github issues? arXiv preprint arXiv:2310.06770 (2023)

    2023 arXiv

  7. [15]

    Haolin Jin, Linghan Huang, Haipeng Cai, Jun Yan, Bo Li, and Huaming Chen. 2024. From LLMs to LLM-based Agents for Software Engineering: A Survey of Current, Challenges and Future. arXiv:2408.02479 [cs.SE] https://arxiv.org/abs/2408.02479

    2024 arXiv

  8. [16]

    Ummay Kulsum, Haotian Zhu, Bowen Xu, and Marcelo d’Amorim. 2024. A Case Study of LLM for Automated Vulnerability Repair: Assessing Impact of Reasoning and Patch Validation Feedback. In Proceedings of the 1st ACM Inter- national Conference on AI-Powered Software (Porto de Galin...

    2024

  9. [17]

    Thanh Le-Cong, Bach Le, and Toby Murray. 2024. Semantic-guided Search for Efficient Program Repair with Large Language Models. arXiv:2410.16655 [cs.SE] https://arxiv.org/abs/2410.16655

    2024

  10. [18]

    Cheryl Lee, Chunqiu Steven Xia, Longji Yang, Jen tse Huang, Zhouruixin Zhu, Lingming Zhang, and Michael R. Lyu. 2024. A Unified Debugging Approach via LLM-Based Multi-Agent Synergy. arXiv:2404.17153 [cs.SE] https://arxiv.org/ abs/2404.17153

    2024

  11. [19]

    Bo Lin, Shangwen Wang, Ming Wen, Liqian Chen, and Xiaoguang Mao. 2024. One Size Does Not Fit All: Multi-granularity Patch Generation for Better Automated Program Repair (ISSTA 2024). Association for Computing Machinery, New York, NY, USA, 1554–1566. https://doi.org/10.1145/365...

    2024

  12. [20]

    Facundo Molina, Juan Manuel Copia, and Alessandra Gorla. 2024. Improving Patch Correctness Analysis via Random Testing and Large Language Models. In 2024 IEEE Conference on Software Testing, Verification and Validation (ICST) . 317–328. https://doi.org/10.1109/ICST60714.2024.00036

    2024

  13. [21]

    OpenAI and Aaron Hurst et al. 2024. GPT-4o System Card. arXiv:2410.21276 [cs.CL] https://arxiv.org/abs/2410.21276

    2024 arXiv

  14. [22]

    Zichao Qi, Fan Long, Sara Achour, and Martin Rinard. 2015. An analysis of patch plausibility and correctness for generate-and-validate patch generation systems. In Proceedings of the 2015 International Symposium on Software Testing and Analysis (Baltimore, MD, USA) (ISSTA 2015...

    2015

  15. [23]

    Albert Örwall. 2024. Moatless Tools. https://github.com/aorwall/moatless-tools

    2024

  16. [24]

    Albert Örwall. 2024. SWE-bench-docker. https://github.com/aorwall/SWE- bench-docker

    2024

  17. [25]

    Junjie Wang, Yuchao Huang, Chunyang Chen, Zhe Liu, Song Wang, and Qing Wang. 2024. Software Testing With Large Language Models: Survey, Landscape, and Vision. IEEE Transactions on Software Engineering 50, 4 (2024), 911–936. https://doi.org/10.1109/TSE.2024.3368208

    2024

  18. [26]

    Shangwen Wang, Ming Wen, Bo Lin, Hongjun Wu, Yihao Qin, Deqing Zou, Xiaoguang Mao, and Hai Jin. 2021. Automated patch correctness assessment: how far are we?. In Proceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering (Virtual Event, Austral...

    2021

  19. [27]

    Ming Wen, Junjie Chen, Rongxin Wu, Dan Hao, and Shing-Chi Cheung. 2018. Context-aware patch generation for better automated program repair. InProceed- ings of the 40th International Conference on Software Engineering (Gothenburg, Sweden) (ICSE ’18). Association for Computing M...

    2018

  20. [28]

    Eric Wong, Ruizhi Gao, Yihao Li, Rui Abreu, and Franz Wotawa

    W. Eric Wong, Ruizhi Gao, Yihao Li, Rui Abreu, and Franz Wotawa. 2016. A survey on software fault localization. IEEE Transactions on Software Engineering 42, 8 (1 Aug. 2016), 707–740. https://doi.org/10.1109/TSE.2016.2521368

    2016

  21. [29]

    Chunqiu Steven Xia, Yinlin Deng, Soren Dunn, and Lingming Zhang

  22. [30]

    Chunqiu Steven Xia, Yuxiang Wei, and Lingming Zhang. 2023. Automated Program Repair in the Era of Large Pre-trained Language Models. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE) . 1482–

    2023

  23. [31]

    Chunqiu Steven Xia and Lingming Zhang. 2024. Automated Program Repair via Conversation: Fixing 162 out of 337 Bugs for $0.42 Each using ChatGPT. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA) (Vienna, Austria) (ISSTA 202...

    2024 doi

  24. [32]

    Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press

    John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. 2024. SWE-agent: Agent-Computer In- terfaces Enable Automated Software Engineering. arXiv:2405.15793 [cs.SE] https://arxiv.org/abs/2405.15793

    2024 arXiv

  25. [33]

    Tao Zhang, He Jiang, Xiapu Luo, and Alvin T.S. Chan. 2016. A Lit- erature Review of Research in Bug Resolution: Tasks, Challenges and Future Directions. Comput. J. 59, 5 (05 2016), 741–773. https:// doi.org/10.1093/comjnl/bxv114 arXiv:https://academic.oup.com/comjnl/article- p...

    2016 doi

  26. [34]

    Yuntong Zhang, Haifeng Ruan, Zhiyu Fan, and Abhik Roychoudhury. 2024. Au- toCodeRover: Autonomous Program Improvement. arXiv:2404.05427 [cs.SE] https://arxiv.org/abs/2404.05427

    2024 arXiv

  27. [35]

    Xin Zhou, Bowen Xu, Kisub Kim, DongGyun Han, Thanh Le-Cong, Junda He, Bach Le, and David Lo. 2024. PatchZero: Zero-Shot Automatic Patch Correctness Assessment. arXiv:2303.00202 [cs.SE] https://arxiv.org/abs/2303.00202

    2024 arXiv

  28. [1494]

    https://doi.org/10.1109/ICSE48619.2023.00129

    2023

  29. [2024]

    arXiv:2407.01489 [cs.SE] https://arxiv.org/abs/2407.01489

    Agentless: Demystifying LLM-based Software Engineering Agents. arXiv:2407.01489 [cs.SE] https://arxiv.org/abs/2407.01489

    arXiv

Pith tools

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