Pith. sign in

REVIEW 4 major objections 4 minor 1 cited by

LinkAnchor: An Autonomous LLM-Based Agent for Issue-to-Commit Link Recovery

T0 review · 4 major / 4 minor · reviewed 2026-08-05 · deepseek-v4-flash

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

Pith's one-line read LinkAnchor, a training-free LLM agent, recovers issue-to-commit links with a mean Hit@1 of 0.8632 on six Apache projects, outperforming state-of-the-art methods by 60–262%.

desk verdict Genuinely new LLM-agent application for issue-to-commit linking with strong absolute accuracy, but the 60-262% claim over SOTA is not established until baselines are re-run under the redefined ground truth. read the letter →

arxiv 2508.12232 v5 pith:5VJO5CX6 submitted 2025-08-17 cs.SE cs.AI

Arshia Akhavan , Alireza Hoseinpour , Abbas Heydarnoori , Hamid Bagheri , Mehdi Keshani This is my paper · ORCID
classification cs.SEcs.AI
keywords issue-to-commitlinkrecoveryLLMagentsoftwaretraceabilitylazy-accessarchitecturefunctioncallingcommitresolutionGitHubissuesJira
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

LinkAnchor addresses issue-to-commit link recovery, the task of finding which commit actually resolved a given issue. The paper argues that prior methods degrade because they must fit all context into a fixed window or score every issue-commit pair in isolation, ignoring chains of commits and issue-discussion clues. LinkAnchor instead lets a general-purpose LLM act as an autonomous search agent: it invokes functions to pull only the relevant commits, comments, and code on demand. The paper reports that LinkAnchor achieves a mean Hit@1 of 0.8632 across six Apache projects, a 60–262% improvement over four state-of-the-art baselines, and 89% accuracy on 120 unseen GitHub issues, all without any training. If these numbers hold, agent-based lazy retrieval is a practical, setup-free alternative to trained link-recovery models.

What carries the argument

The load-bearing mechanism is a lazy-access agent architecture: LinkAnchor exposes 20 deterministic functions in Git, Issue, Codebase, and Control categories that a general-purpose LLM can call iteratively. Git functions provide paginated commit lists filtered by author, file, or time, with a unified branch view and safe-lifespan filtering (one week before issue creation to one week after resolution); Codebase functions use a Tree-sitter AST to fetch definitions, docs, or line ranges at any commit; Issue functions expose title, description, comments, and participants; Feedback lets the model discard unhelpful large outputs to conserve tokens. This machinery reframes link recovery from exhaus

What would settle it

Take EALink's six-project dataset, relabel each issue's ground truth to the latest linked commit (as the paper does), and rerun EALink, T-BERT, DeepLink, and VSM on those labels; if any baseline's Hit@1 reaches or exceeds LinkAnchor's 0.8632 mean, the claimed 60–262% improvements collapse.

Watch

Extended reading notes

Core claim

On the paper's own terms, the central discovery is that an LLM equipped with a small set of read-only functions can solve issue-to-commit link recovery by searching rather than by classifying. LinkAnchor redefines the target as the latest linked commit per issue, and its agent searches the repository's commit history, issue discussion, and code through 20 deterministic functions. It reports a mean Hit@1 of 0.8632 across six Apache projects, with per-project scores between 0.79 and 0.95, and a mean of 0.89 on 120 GitHub issues resolved after the model's training cutoff. The paper attributes the gains to access to previously untapped data sources, especially issue comments and code inspection,

Load-bearing premise

The load-bearing premise is that the published Hit@1 scores of the four prior methods remain valid when the ground truth is redefined as the latest linked commit per issue, even though those scores were never recomputed under that definition.

Editorial extensions

If this is right

  • LinkAnchor can be applied to a new repository immediately, with no training data, feature engineering, or GPU infrastructure, and reports a median cost of about $0.01 and 23 seconds per issue.
  • The approach succeeds on projects where prior methods degrade (e.g., Ignite and NetBeans), suggesting that dynamic data selection rather than fixed features is the source of stability.
  • Because all function responses are deterministic, every step of the agent's search is auditable against the true repository state.
  • The same architecture extends beyond Jira and GitHub to any platform with a data extractor, and to any Tree-sitter-supported language.

Reading between the lines

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

  • A natural stress test is to run LinkAnchor against an open-weight local LLM: if performance holds, the approach no longer depends on a specific API's pricing or training cutoff.
  • The paper's ground-truth redefinition (latest linked commit per issue) is reasonable but unilaterally applied; if prior baselines were recomputed on those labels, the size of the reported improvements could change, and a fair comparison would require releasing the relabeled dataset.
  • The same lazy-access agent pattern could plausibly transfer to other trace-link tasks, such as requirements-to-code or bug-report-to-fix, since the limiting factor in those tasks is also context-window capacity rather than the scoring model.
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 / 4 minor

Summary. LinkAnchor is an LLM-based agent for issue-to-commit link recovery. Given an issue URL and a Git repository, it lets an LLM invoke specialized functions to query commit history, issue threads, and code, finally returning a single commit hash. The paper evaluates LinkAnchor on six Apache projects from the EALink dataset (Table II) and on 120 recently resolved GitHub issues (Table V), reporting mean Hit@1 of 0.8632 and 0.89 respectively, and claims 60–262% improvement over four baselines. The approach is training-free, uses a lazy-access architecture to address context-window limits, and formulates ILR as a search problem rather than pairwise classification.

Significance. If the reported results hold, LinkAnchor would be a practical, training-free ILR approach that outperforms supervised methods while exploiting previously unused signals such as issue comments and codebase inspection. The modular design, public replication package, and three-run averaging for LLM variability are strengths. RQ2's use of post-training-cutoff issues is a thoughtful attempt to avoid data leakage. However, the headline comparative claim rests on a protocol mismatch in baseline evaluation, and the RQ1 sample sizes and RQ2 label construction are underspecified. These issues must be resolved before the significance of the claimed improvements can be assessed.

major comments (4)
  1. [Section V.A.2 / Table II] The comparison is not apples-to-apples. LinkAnchor's 'Hit@1' is the fraction of issues for which its single predicted commit equals the latest linked commit in the safe-lifespan commit set. The reported baseline scores come from EALink (and its baselines), where Hit@1 is measured by ranking a curated 100-commit candidate set guaranteed to contain exactly one true link. These differ in target definition (latest linked commit vs. any linked commit), candidate construction, and search space. The statement that Hit@1 'allows for a fair comparison' is unsupported. The 60–262% improvements in Table II are not established unless baselines are re-run under the adjusted ground truth and search protocol.
  2. [Section V.A.1 / Table II] The paper never states how many issues were run through LinkAnchor per project in RQ1. It refers to the full EALink dataset ('over 59k unique issues') and then reports Hit@1 proportions. Without the denominator and sampling method per project, the reader cannot judge whether a score of 0.79 on Netbeans is based on 10 or 1,000 issues. Please report the number of issues per project, the selection procedure, and ideally confidence intervals or per-run ranges. This also affects the cost analysis in Table VI, which appears to be based on a subset.
  3. [Section V.A.1] RQ1 uses the EALink dataset, whose issues and commits almost certainly predate the October 2023 training cutoff of ChatGPT-4o-nano. Since the LLM was pretrained on public GitHub/Jira data, it may have memorized some issue-commit links, which would inflate LinkAnchor's scores relative to the supervised baselines. RQ2 explicitly avoids this risk by using post-October-2023 issues, but the main comparison in Table II does not. Please either replace RQ1 with post-cutoff data or analyze the leakage risk (e.g., by comparing performance across time splits) and discuss the effect on the claimed improvements.
  4. [Section V.B.1] The construction of the RQ2 ground truth is under-specified. How was the 'true resolving commit' determined for each of the 120 issues? Possibilities include GitHub's explicit closing-link metadata, commit-message keyword matching, or manual inspection; each yields different labels and thus different success rates. The paper also does not state how 'resolved after October 2023' was verified or how the 20 issues per project were sampled. Please provide the exact labeling procedure and dataset construction code.
minor comments (4)
  1. [Throughout] Inconsistent naming: 'T-Bert' vs. 'T-BERT', 'ChatGPT-4o-nano' vs. 'Chat-GPT4o-nano', 'EA-Link' vs. 'EALink', 'TREE-SITTER' vs. 'Tree-sitter', and 'ignite' (Table III) vs. 'Ignite' elsewhere. Please standardize.
  2. [Eq. (1) / Section V.A.2] Equation (1) defines Hit@k on a candidate set Q, but LinkAnchor's metric is a success rate over issues, not a rank among 100 candidates. Suggest renaming LinkAnchor's metric (e.g., 'success@1') or explicitly describing it as an adapted metric to avoid confusion.
  3. [Section V.A.2] The sentence 'The number we report for LinkAnchor is calculated by dividing the number of correct commit hashes by the total number of issues available in the dataset' conflicts with the cost analysis, which suggests a subset was actually used. Please clarify the exact evaluation set.
  4. [Section VI] The EALink time comparison (29,101 × 0.126s) assumes EALink scores every commit per issue; if EALink uses candidate generation or pruning, this comparison is misleading. Also, per-issue time for LinkAnchor is compared to per-1000-pairs scoring time for EALink, which is not a direct apples-to-apples comparison.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: LinkAnchor's performance is measured, not derived from its inputs; baseline comparability concern is a validity issue, not a circular reduction.

full rationale

The paper's central claim is an empirical evaluation of an LLM agent, not a mathematical derivation. LinkAnchor is not fitted to the EALink dataset or to the redefined ground truth; it is a pre-trained LLM with deterministic retrieval functions. The adjustment of ground truth to 'the latest linked commit' (Section V.A.2) aligns the evaluation target with the agent's intended output, but this is task specification, not a circular reduction: the agent must still search commit history, diffs, issue threads, and code to find that commit, and the paper reports failures (e.g., GiveUp, misses) showing the outcome is not forced. The safe-lifespan filter (Section IV.B) restricts the search window but does not identify the answer; the LLM chooses among commits in that window. The baseline comparison uses published Hit@1/Hit@10 scores computed under EALink's original 100-commit candidate-set protocol, while LinkAnchor's Hit@1 is computed as the fraction of issues for which its single prediction equals the adjusted ground truth. This is an apples-to-oranges comparison and a threat to the claimed improvement percentages, but it is not circularity: the baseline numbers are external measurements, not functions of LinkAnchor's output or fitted parameters. No load-bearing self-citation appears; the cited Hybrid-Linker [14] and AROMA [5] involve co-authors but are related-work context, not justification of LinkAnchor's results. No uniqueness theorem is imported from the authors' prior work, and no ansatz is smuggled in via citation. Thus there is no step where a prediction reduces by construction to an input, and the circularity score is 0.

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

The central claim rests on several hand-chosen operational parameters (safe lifespan, token and iteration limits) and on domain assumptions about the definition of a resolving commit, the accuracy of the EALink labels, and the comparability of published baseline scores. No new physical or conceptual entities are introduced.

free parameters (4)
  • safe_lifespan_window = 7 days before issue creation to 7 days after issue resolution
    Git-Extractor restricts all queries to this window by default; a hand-chosen heuristic from prior ILR studies that reduces the search space for LinkAnchor.
  • max_iterations = 20
    Hard limit on LLM function-calling iterations to ensure termination, communicated in the initial prompt.
  • feedback_size_threshold = 40kB
    Responses larger than 40kB trigger a Feedback request to discard or preserve data; chosen to stay within the token budget.
  • max_tokens_per_issue = 200k
    Overall token budget per issue to control cost.
assumptions (5)
  • domain assumption The latest linked commit in a chain of commits is the correct resolving commit for an issue.
    Used to adapt the EALink dataset: the ground truth is redefined as the latest true link by timestamp, which is the target LinkAnchor returns.
  • domain assumption Most resolving commits fall within the safe lifespan of the issue (one week before creation to one week after resolution).
    Motivates the safe-lifespan filter that restricts LinkAnchor's default search space; cited from prior studies [7], [13], [23].
  • domain assumption The EALink dataset's true links are accurate labels.
    LinkAnchor's RQ1 evaluation uses the EALink dataset as ground truth; any label noise propagates to reported Hit@1.
  • domain assumption Published baseline Hit@1 scores are comparable to LinkAnchor's scores despite a different ground-truth definition.
    The claim of outperformance depends on the validity of directly comparing published baseline scores with LinkAnchor's adjusted-ground-truth scores.
  • domain assumption OpenAI's ChatGPT-4o-nano API returns answers consistent enough that three runs average to the true performance.
    The paper relies on a proprietary, non-deterministic model and repeats experiments three times.

how reviews work

0 comments
Cite this review

Pith. "Pith review of LinkAnchor: An Autonomous LLM-Based Agent for Issue-to-Commit Link Recovery." pith.science (2026). https://pith.science/paper/5VJO5CX6

@misc{pith2026250812232,
  author       = {Pith},
  title        = {Pith review of: LinkAnchor: An Autonomous LLM-Based Agent for Issue-to-Commit Link Recovery},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/5VJO5CX6}},
  note         = {Machine review of arXiv:2508.12232}
}
read the original abstract

Issue-to-commit link recovery in software repositories is fundamental to software traceability and project management, yet it remains a challenging task. Prior studies show that only about 42.2% of issues on GitHub are correctly linked to their commits, highlighting the need for more effective solutions. Existing work has explored a range of ML/DL approaches, and more recently, large language models (LLMs) have been applied to this problem. However, these methods face two major limitations. First, LLMs are restricted by limited context windows and cannot simultaneously process all available data sources, such as long commit histories, extensive issue discussions, and large code repositories. Second, most approaches operate on individual issue-commit pairs, where a model independently scores the relevance of a single commit to an issue. This pairwise formulation fails to account for the complex associativity of software fixes, where an issue is often resolved by an aggregate chain of commits rather than a single atomic change. By ignoring these temporal and parental dependencies, existing methods often fail to incorporate the complete resolution logic and might misidentify intermediate commits as final fixes. Furthermore, this strategy is computationally inefficient in large repositories, as it requires exhaustively evaluating an enormous number of candidate pairs. To address these challenges, we present LinkAnchor, the first autonomous LLM-based agent designed specifically for issue-to-commit link recovery. LinkAnchor introduces a lazy-access architecture that allows the underlying LLM to dynamically retrieve only the most relevant contextual data, such as commits, issue comments, and code files, without exceeding token limits.

Figures

Figures reproduced from arXiv: 2508.12232 by the authors.

Figure 1
Figure 1. LinkAnchor’s overall architecture that are critical to pinpointing the exact commit that resolves a given issue. 2) L2: Inaccuracy in Training Dataset: A common challenge in most previous studies lies in the training phase and the preparation of training data. In ILR tasks, the only ground-truth data available are the actual issue–commit links. Consequently, researchers often generate artificial negative examples by… view at source ↗
Figure 2
Figure 2. Two motivating examples traceability between software artifacts; (ii) ILR methods; and (iii) the use of LLM agents in various tasks. a) Software Traceability Link Recovery: The early TLR approaches primarily relied on information retrieval (IR) tech￾niques [30], [31], constructing retrieval models to calculate text similarity. Techniques such as the Vector Space Model (VSM) [32]–[35], Latent Semantic Indexing [36]–[… view at source ↗
Figure 3
Figure 3. Average function-call ratios per project, broken out by category. Function names are condensed for better presentation. [PITH_FULL_IMAGE:figures/full_fig_p009_3.png] view at source ↗

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. LinkRank: A Learning-to-Rank Framework for One-to-Many Issue-Commit Traceability

    cs.SE 2026-07 conditional novelty 6.0 of 10

    Framing one-to-many issue–commit recovery as issue-centric learning-to-rank with iterative pick–remove–renormalize selection substantially beats pairwise and LLM baselines on a new six-project dataset.

Reference graph

Works this paper leans on

61 extracted references · 4 canonical work pages · cited by 1 Pith paper

  1. [1]

    LinkAnchor’s replication package

    “LinkAnchor’s replication package.” https://github.com/ISE-Research/ LinkAnchor. Accessed: 08-30-2025

    2025

  2. [2]

    Improving the effectiveness of traceability link recovery using hierarchical bayesian networks,

    K. Moran, D. N. Palacio, C. Bernal-C ´ardenas, D. McCrystal, D. Poshy- vanyk, C. Shenefiel, and J. Johnson, “Improving the effectiveness of traceability link recovery using hierarchical bayesian networks,” in Pro- ceedings of the ACM/IEEE 42nd International Conference on Software Engineering, pp. 873–885, 2020

    2020

  3. [3]

    Leveraging in- termediate artifacts to improve automated trace link retrieval,

    A. D. Rodriguez, J. Cleland-Huang, and D. Falessi, “Leveraging in- termediate artifacts to improve automated trace link retrieval,” in 2021 IEEE International Conference on Software Maintenance and Evolution (ICSME), pp. 81–92, IEEE, 2021

    2021

  4. [4]

    Lissa: Toward generic traceability link recovery through retrieval- augmented generation,

    D. Fuchß, T. Hey, J. Keim, H. Liu, N. Ewald, T. Thirolf, and A. Koziolek, “Lissa: Toward generic traceability link recovery through retrieval- augmented generation,” in Proceedings of the IEEE/ACM 47th Inter- national Conference on Software Engineering. ICSE , vol. 25, 2025

    2025

  5. [5]

    Aroma: Automatic reproduction of maven artifacts,

    M. Keshani, T.-G. Velican, G. Bot, and S. Proksch, “Aroma: Automatic reproduction of maven artifacts,” Proceedings of the ACM on Software Engineering, vol. 1, no. FSE, pp. 836–858, 2024

    2024

  6. [6]

    Stack overflow developer survey 2022: Ver- sion control systems

    Stack Overflow, “Stack overflow developer survey 2022: Ver- sion control systems.” Online at https://survey.stackoverflow.co/2022/ #section-version-control-version-control-systems, 2022. Accessed: 26 March 2025

    2022

  7. [7]

    Deeplink: Recovering issue- commit links based on deep learning,

    H. Ruan, B. Chen, X. Peng, and W. Zhao, “Deeplink: Recovering issue- commit links based on deep learning,” Journal of Systems and Software, vol. 158, p. 110406, 2019

    2019

  8. [8]

    Rclinker: Automated linking of issue reports and commits leveraging rich con- textual information,

    T.-D. B. Le, M. Linares-V ´asquez, D. Lo, and D. Poshyvanyk, “Rclinker: Automated linking of issue reports and commits leveraging rich con- textual information,” in 2015 IEEE 23rd international conference on program comprehension, pp. 36–47, IEEE, 2015

    2015

Show all 61 references
  1. [9]

    Feature location in source code: a taxonomy and survey,

    B. Dit, M. Revelle, M. Gethers, and D. Poshyvanyk, “Feature location in source code: a taxonomy and survey,” Journal of software: Evolution and Process, vol. 25, no. 1, pp. 53–95, 2013

    2013

  2. [10]

    Who should fix this bug?,

    J. Anvik, L. Hiew, and G. C. Murphy, “Who should fix this bug?,” in Proceedings of the 28th international conference on Software engineer- ing, pp. 361–370, 2006

    2006

  3. [11]

    A literature review of automatic traceability links recovery for software change impact analysis,

    T. W. W. Aung, H. Huo, and Y . Sui, “A literature review of automatic traceability links recovery for software change impact analysis,” in Proceedings of the 28th International Conference on Program Com- prehension, pp. 14–24, 2020

    2020

  4. [12]

    Successful deployment of requirements traceability in a commercial engineering organization... really,

    M. C. Panis, “Successful deployment of requirements traceability in a commercial engineering organization... really,” in 2010 18th IEEE In- ternational Requirements Engineering Conference , pp. 303–307, IEEE, 2010

    2010

  5. [13]

    Frlink: Improving the recovery of missing issue-commit links by revisiting file relevance,

    Y . Sun, Q. Wang, and Y . Yang, “Frlink: Improving the recovery of missing issue-commit links by revisiting file relevance,” Information and Software Technology, vol. 84, pp. 33–47, 2017

    2017

  6. [14]

    Automated recovery of issue-commit links leveraging both textual and non-textual data,

    P. R. Mazrae, M. Izadi, and A. Heydarnoori, “Automated recovery of issue-commit links leveraging both textual and non-textual data,” in2021 IEEE International Conference on Software Maintenance and Evolution (ICSME), pp. 263–273, IEEE, 2021

    2021

  7. [15]

    Multi- layered approach for recovering links between bug reports and fixes,

    A. T. Nguyen, T. T. Nguyen, H. A. Nguyen, and T. N. Nguyen, “Multi- layered approach for recovering links between bug reports and fixes,” in Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering , pp. 1–11, 2012

    2012

  8. [16]

    Improving missing issue- commit link recovery using positive and unlabeled data,

    Y . Sun, C. Chen, Q. Wang, and B. Boehm, “Improving missing issue- commit link recovery using positive and unlabeled data,” in 2017 32nd IEEE/ACM International Conference on Automated Software Engineer- ing (ASE), pp. 147–152, IEEE, 2017

    2017

  9. [17]

    Deeplink: A code knowledge graph based deep learning approach for issue-commit link recovery,

    R. Xie, L. Chen, W. Ye, Z. Li, T. Hu, D. Du, and S. Zhang, “Deeplink: A code knowledge graph based deep learning approach for issue-commit link recovery,” in 2019 IEEE 26th International Conference on Software Analysis, Evolution and Reengineering (SANER) , pp. 434–444, IEEE, 2019

    2019

  10. [18]

    Promptlink: Multi-template prompt learning with adversarial training for issue-commit link recov- ery,

    Y . Deng, B. Wang, Z. Zou, and L. Ye, “Promptlink: Multi-template prompt learning with adversarial training for issue-commit link recov- ery,” in Proceedings of the 18th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement , pp. 461–467, 2024

    2024

  11. [19]

    Mplinker: Multi- template prompt-tuning with adversarial training for issue-commit link recovery,

    B. Wang, Y . Deng, R. Luo, P. Liang, and T. Bi, “Mplinker: Multi- template prompt-tuning with adversarial training for issue-commit link recovery,” Journal of Systems and Software , p. 112351, 2025

    2025

  12. [20]

    Btlink: automatic link recovery between issues and commits based on pre-trained bert model,

    J. Lan, L. Gong, J. Zhang, and H. Zhang, “Btlink: automatic link recovery between issues and commits based on pre-trained bert model,” Empirical Software Engineering , vol. 28, no. 4, p. 103, 2023

    2023

  13. [21]

    Traceability transformed: Generating more accurate links with pre-trained bert mod- els,

    J. Lin, Y . Liu, Q. Zeng, M. Jiang, and J. Cleland-Huang, “Traceability transformed: Generating more accurate links with pre-trained bert mod- els,” in 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE), pp. 324–335, IEEE, 2021

    2021

  14. [22]

    Bert: Pre-training of deep bidirectional transformers for language understanding,

    J. Devlin, M.-W. Chang, K. Lee, and K. Toutanova, “Bert: Pre-training of deep bidirectional transformers for language understanding,” in Pro- ceedings of the 2019 conference of the North American chapter of the association for computational linguistics: human language technolo...

    2019

  15. [23]

    Ealink: An efficient and accurate pre-trained framework for issue-commit link recovery,

    C. Zhang, Y . Wang, Z. Wei, Y . Xu, J. Wang, H. Li, and R. Ji, “Ealink: An efficient and accurate pre-trained framework for issue-commit link recovery,” in 2023 38th IEEE/ACM International Conference on Auto- mated Software Engineering (ASE) , pp. 217–229, IEEE, 2023

    2023

  16. [24]

    Semi-supervised pre-processing for learning-based traceability framework on real-world software projects,

    L. Dong, H. Zhang, W. Liu, Z. Weng, and H. Kuang, “Semi-supervised pre-processing for learning-based traceability framework on real-world software projects,” in Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Softw...

    2022

  17. [25]

    Tree-sitter: An incremental parsing system for programming tools

    M. Brunsfeld and G. contributors, “Tree-sitter: An incremental parsing system for programming tools.” GitHub repository at https://github.com/ tree-sitter/tree-sitter, 2018. Accessed: 22 March 2025

    2018

  18. [26]

    The initial incomplete commit in the first motivating example

    “The initial incomplete commit in the first motivating example.” at https://github.com/JuliaLang/julia/commit/ 58079819d667f832abfc6fea8210252f161387d7

  19. [27]

    The issue in the first motivating example

    “The issue in the first motivating example.” at https://github.com/ JuliaLang/julia/issues/92

  20. [28]

    The final fix commit in the first motivating ex- ample

    “The final fix commit in the first motivating ex- ample.” at https://github.com/JuliaLang/julia/commit/ ec4f20243c0807654eeeb8df343611d22c8ef404

  21. [29]

    Issue discussion example with explicit commit reference

    “Issue discussion example with explicit commit reference.” at https:// issues.apache.org/jira/browse/CALCITE-6820

  22. [30]

    Estimating the number of remaining links in traceability recovery,

    D. Falessi, M. Di Penta, G. Canfora, and G. Cantone, “Estimating the number of remaining links in traceability recovery,” Empirical Software Engineering, vol. 22, pp. 996–1027, 2017

    2017

  23. [31]

    Automatic traceability main- tenance via machine learning classification,

    C. Mills, J. Escobar-Avila, and S. Haiduc, “Automatic traceability main- tenance via machine learning classification,” in 2018 IEEE international conference on software maintenance and evolution (ICSME) , pp. 369– 380, IEEE, 2018

    2018

  24. [32]

    Advancing candidate link generation for requirements tracing: The study of methods,

    J. H. Hayes, A. Dekhtyar, and S. K. Sundaram, “Advancing candidate link generation for requirements tracing: The study of methods,” IEEE Transactions on Software Engineering , vol. 32, no. 1, pp. 4–19, 2006

    2006

  25. [33]

    Recovering traceability links between code and documentation,

    G. Antoniol, G. Canfora, G. Casazza, A. De Lucia, and E. Merlo, “Recovering traceability links between code and documentation,” IEEE transactions on software engineering, vol. 28, no. 10, pp. 970–983, 2002

    2002

  26. [34]

    On inte- grating orthogonal information retrieval methods to improve traceability recovery,

    M. Gethers, R. Oliveto, D. Poshyvanyk, and A. De Lucia, “On inte- grating orthogonal information retrieval methods to improve traceability recovery,” in 2011 27th IEEE International Conference on Software Maintenance (ICSM), pp. 133–142, IEEE, 2011

    2011

  27. [35]

    On the role of semantics in automated requirements tracing,

    A. Mahmoud and N. Niu, “On the role of semantics in automated requirements tracing,” Requirements Engineering, vol. 20, pp. 281–300, 2015

    2015

  28. [36]

    Towards feature-aware retrieval of refinement traces,

    P. Rempel, P. M ¨ader, and T. Kuschke, “Towards feature-aware retrieval of refinement traces,” in 2013 7th International Workshop on Traceabil- ity in Emerging Forms of Software Engineering (TEFSE) , pp. 100–104, IEEE, 2013

    2013

  29. [37]

    Enhancing an artefact management system with traceability recovery features,

    A. De Lucia, F. Fasano, R. Oliveto, and G. Tortora, “Enhancing an artefact management system with traceability recovery features,” in 20th IEEE International Conference on Software Maintenance, 2004. Proceedings., pp. 306–315, IEEE, 2004

    2004

  30. [38]

    Recovering documentation-to-source-code traceability links using latent semantic indexing,

    A. Marcus and J. I. Maletic, “Recovering documentation-to-source-code traceability links using latent semantic indexing,” in 25th International Conference on Software Engineering, 2003. Proceedings. , pp. 125–135, IEEE, 2003

    2003

  31. [39]

    Technique integration for requirements assessment,

    A. Dekhtyar, J. H. Hayes, S. Sundaram, A. Holbrook, and O. Dekhtyar, “Technique integration for requirements assessment,” in15th IEEE Inter- national Requirements Engineering Conference (RE 2007), pp. 141–150, IEEE, 2007

    2007

  32. [40]

    Software trace- ability with topic modeling,

    H. U. Asuncion, A. U. Asuncion, and R. N. Taylor, “Software trace- ability with topic modeling,” in Proceedings of the 32nd ACM/IEEE international conference on Software Engineering-Volume 1 , pp. 95– 104, 2010

    2010

  33. [41]

    Using consensual biterms from text structures of requirements and code to improve ir-based traceability recovery,

    H. Gao, H. Kuang, K. Sun, X. Ma, A. Egyed, P. M ¨ader, G. Rong, D. Shao, and H. Zhang, “Using consensual biterms from text structures of requirements and code to improve ir-based traceability recovery,” in Proceedings of the 37th IEEE/ACM International Conference on Automated ...

    2022

  34. [42]

    Improving traceability link recovery using fine-grained requirements-to-code relations,

    T. Hey, F. Chen, S. Weigelt, and W. F. Tichy, “Improving traceability link recovery using fine-grained requirements-to-code relations,” in 2021 IEEE International Conference on Software Maintenance and Evolution (ICSME), pp. 12–22, IEEE, 2021

    2021

  35. [43]

    Supporting requirements traceability through refactoring,

    A. Mahmoud and N. Niu, “Supporting requirements traceability through refactoring,” in 2013 21st IEEE International Requirements Engineering Conference (RE), pp. 32–41, IEEE, 2013

    2013

  36. [44]

    Using frugal user feedback with closeness analysis on code to improve ir-based traceability recovery,

    H. Kuang, H. Gao, H. Hu, X. Ma, J. L ¨u, P. M ¨ader, and A. Egyed, “Using frugal user feedback with closeness analysis on code to improve ir-based traceability recovery,” in 2019 IEEE/ACM 27th International Conference on Program Comprehension (ICPC) , pp. 369–379, IEEE, 2019

    2019

  37. [45]

    An ir-based artificial bee colony approach for traceability link recovery,

    D. V . Rodriguez and D. L. Carver, “An ir-based artificial bee colony approach for traceability link recovery,” in2020 IEEE 32nd International Conference on Tools with Artificial Intelligence (ICTAI), pp. 1145–1153, IEEE, 2020

    2020

  38. [46]

    Multi-objective information retrieval- based nsga-ii optimization for requirements traceability recovery,

    D. V . Rodriguez and D. L. Carver, “Multi-objective information retrieval- based nsga-ii optimization for requirements traceability recovery,” in 2020 IEEE International Conference on Electro Information Technology (EIT), pp. 271–280, IEEE, 2020

    2020

  39. [47]

    Semantically enhanced soft- ware traceability using deep learning techniques,

    J. Guo, J. Cheng, and J. Cleland-Huang, “Semantically enhanced soft- ware traceability using deep learning techniques,” in 2017 IEEE/ACM 39th International Conference on Software Engineering (ICSE) , pp. 3– 14, IEEE, 2017

    2017

  40. [48]

    Recovering trace links between software documentation and code,

    J. Keim, S. Corallo, D. Fuchß, T. Hey, T. Telge, and A. Koziolek, “Recovering trace links between software documentation and code,” in Proceedings of the IEEE/ACM 46th International Conference on Software Engineering, pp. 1–13, 2024

    2024

  41. [49]

    Recovering transitive traceability links among software artifacts,

    K. Nishikawa, H. Washizaki, Y . Fukazawa, K. Oshima, and R. Mibe, “Recovering transitive traceability links among software artifacts,” in 2015 IEEE International Conference on Software Maintenance and Evolution (ICSME), pp. 576–580, IEEE, 2015

    2015

  42. [50]

    Prompts matter: Insights and strategies for prompt engineering in automated software traceability,

    A. D. Rodriguez, K. R. Dearstyne, and J. Cleland-Huang, “Prompts matter: Insights and strategies for prompt engineering in automated software traceability,” in 2023 IEEE 31st International Requirements Engineering Conference Workshops (REW) , pp. 455–464, IEEE, 2023

    2023

  43. [51]

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

    Z. Feng, D. Guo, D. Tang, N. Duan, X. Feng, M. Gong, L. Shou, B. Qin, T. Liu, D. Jiang, et al., “Codebert: A pre-trained model for programming and natural languages,” arXiv preprint arXiv:2002.08155 , 2020

    2002 arXiv

  44. [52]

    Roberta: A robustly optimized bert pretraining approach,

    Y . Liu, M. Ott, N. Goyal, J. Du, M. Joshi, D. Chen, O. Levy, M. Lewis, L. Zettlemoyer, and V . Stoyanov, “Roberta: A robustly optimized bert pretraining approach,” arXiv preprint arXiv:1907.11692 , 2019

    1907 arXiv

  45. [53]

    A quantitative and qualitative evaluation of llm-based explainable fault localization,

    S. Kang, G. An, and S. Yoo, “A quantitative and qualitative evaluation of llm-based explainable fault localization,” Proceedings of the ACM on Software Engineering, vol. 1, no. FSE, pp. 1424–1446, 2024

    2024

  46. [54]

    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,” arXiv preprint arXiv:2403.17134 , 2024

    2024 arXiv

  47. [55]

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

    I. Bouzenia and M. Pradel, “You name it, i run it: An llm agent to execute tests of arbitrary projects,” arXiv preprint arXiv:2412.10133 , 2024

    2024 arXiv

  48. [56]

    Function calling

    OpenAI, “Function calling.” Online at https://platform.openai.com/docs/ guides/function-calling, 2024. Accessed: 22 March 2025. Aim for fewer than 20 functions at any one time, though this is just a soft suggestion

    2024

  49. [57]

    Codesearchnet challenge: Evaluating the state of semantic code search,

    H. Husain, H.-H. Wu, T. Gazit, M. Allamanis, and M. Brockschmidt, “Codesearchnet challenge: Evaluating the state of semantic code search,” arXiv preprint arXiv:1909.09436 , 2019

    1909 arXiv

  50. [58]

    Opportunities and challenges in code search tools,

    C. Liu, X. Xia, D. Lo, C. Gao, X. Yang, and J. Grundy, “Opportunities and challenges in code search tools,” ACM Computing Surveys (CSUR), vol. 54, no. 9, pp. 1–40, 2021

    2021

  51. [59]

    Gpt-4o model description

    OpenAI, “Gpt-4o model description.” athttps://platform.openai.com/ docs/models/gpt-4o, 2025

    2025

  52. [60]

    Openai’s gpt-4o - ai model details,

    D. AI, “Openai’s gpt-4o - ai model details,” 2024. Accessed: 2025-05- 28

    2024

  53. [61]

    OpenAI, “Tokens.” at https://platform.openai.com/docs/concepts/tokens, 2025

    2025

Pith tools

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