Pith. sign in

REVIEW 3 major objections 4 minor 49 references

Stale function references in Linux kernel comments — names of functions since renamed, split, or deleted — can be found and repaired at scale by resolving function-shaped tokens, tracing each through Git into an evolution tree, and groundin

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

ReCite detects 869 stale function references in Linux kernel v6.18-rc1 comments, with 89% of sampled repairs judged useful and 42.5% directly applicable.

T0 review reviewed 2026-08-05 challenge →

load-bearing objection Genuinely useful paper with the strongest kind of evidence in this subfield—50 accepted kernel patches—but the headline refactoring-vs-removal F1 is computed on a 191-to-7 sample where an always-'refactored' answer beats it, so the per-class story needs reporting. the 3 major comments →

arxiv 2608.03734 v1 pith:A2IFKQLV submitted 2026-08-04 cs.SE

We Must Have Missed This Comment: Detecting and Repairing Stale Function References in Linux Kernel Comments

Kexin Sun , Yunbo Lyu , Xutong Ma , Hongyu Kuang , Ratnadira Widyasari , He Zhang , Xiaoxing Ma , Julia Lawall
show 1 more author
David Lo
This is my paper
classification cs.SE
keywords code commentsstale referencesLinux kernelfunction refactoringGit history analysislarge language modelssoftware maintenancecomment repair
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

The reading

ReCite targets a kind of comment decay that prior code-comment inconsistency tools miss: a comment in the Linux kernel that names a function which has since been renamed, split, or deleted elsewhere in the codebase. The paper claims that such stale references can be found and repaired at scale by combining three stages — spotting function-shaped tokens with no matching definition, walking each one back through Git history to identify what the comment author meant and how that entity evolved, and asking an LLM to rewrite the comment with that evolution history in hand. The evidence is concrete: on kernel v6.18-rc1 the pipeline flags 869 stale references; of 200 sampled repairs, 178 gave useful guidance and 85 could be applied verbatim; and 50 of 75 submitted kernel patches were accepted. Why it matters: stale references are not merely cosmetic — in the paper's motivating example the stale comment pointed at a dead code branch, so fixing the comment and the dead code together exposed a latent defect for maintainers and security auditors. If the approach holds, it converts an unstructured documentation chore into a history-grounded maintenance tool for long-lived C codebases.

Core claim

The central claim is that externally induced staleness — where a comment is orphaned by changes to a function that lives elsewhere, often in another file or architecture — is both detectable and repairable, and that the repair depends on reconstructing the referenced function's life story. ReCite first scans all comments for function-form symbols (tokens shaped like 'name()'), keeps those that no static analysis can resolve to a definition, declaration, or function-like macro (using grep plus Coccinelle SmPL rules), and then goes back to the commit where the symbol first entered the comment to locate the entity the author actually meant — an LLM choice, since the same name often has several

What carries the argument

The load-bearing object is the evolution tree: a per-symbol record of the code entity a comment originally referenced, built by identifying the symbol-introducing commit, selecting the intended entity among same-name candidates (an LLM judgment), then walking Git history forward commit by commit. At each function-removing commit an LLM decides removed versus refactored and names successors, which are validated against the repository before being added as branches; leaves are marked 'Permanently Removed,' 'Aligned with HEAD,' or 'Depth Limit Reached.' The tree carries the argument because it is the repair prompt's core input: a surviving successor supplies a replacement function name, a remov

Load-bearing premise

The pipeline inherits whatever the LLM decides at each function-removing commit: if it misclassifies a removal as a refactoring, names the wrong successor, or — as happened in 7 of 10 sampled 'Tracing Inconclusive' failures — analyzes the wrong commit's diff, the evolution tree is built on the wrong lineage and every repair derived from it inherits that error.

What would settle it

Re-run the 130 'Tracing Inconclusive' cases with oracle-correct removing commits identified by manual inspection: if repair quality does not improve, the evolution tree is not the load-bearing component. Or apply the pipeline to the next Linux kernel release and have an independent maintainer panel rate the 'Acceptable' repairs: if the directly-applicable rate falls far below the reported 42.5%, or if repairs traced through mislocated removing commits are systematically rejected, the central claim that history-grounded tracing produces reliable repairs fails.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • History-grounded repair is what carries the quality: the rule-based baseline reproduces ReCite's repair in only 260 of 869 cases (29.9%) and the no-history LLM variant in only 110 of 869 (12.6%), so the evolution tree, not the LLM alone, is doing the work.
  • Cross-file references dominate — 60.5% of the 999 traceable entities live in a different file from the comment — so any tool that checks only a function against its own comment (the Javadoc-style setting of prior work) will miss most kernel staleness; the end-to-end comparison has the C4RLLaMA baseline flagging 335 of 400 (83.8%) balanced-sample mentions as inconsistent while ReCite reaches F1 = 0
  • Most comment tokens that look like functions never were functions: of 8,258 unresolved mentions, 86.9% were already unresolvable at introduction, and among those only 17.3% are genuinely missing functions — the rest are non-kernel entities, kernel concepts used non-literally, abbreviations or wildcard patterns, typos, and tool false positives; repair-worthy staleness is a narrow, identifiable subs
  • Stale comments can flag deeper defects: the motivating hw_perf_group_sched_in case left an unreachable 'if (!n_ev) return 0' branch, and the maintainer response to the _decode_session6 patch questioned whether the removed ordering constraint made surrounding code redundant — so repairs can double as debloating leads.
  • The authors expect the approach to generalize to other large, long-lived C projects with a Git history, since the mechanism (static resolution, history tracing, LLM repair) is not Linux-specific, with validation on other languages and codebases still open.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • If the 86.9% figure holds, a cheaper production pipeline could apply the expensive Git-tracing and LLM steps only to mentions that were resolvable at introduction, and use lightweight heuristics (the comment's era, the symbol's suffix patterns) to pre-filter abbreviations, verbs, and compiler built-ins before any LLM call.
  • The stale-comment-to-dead-code link in the motivating example is asserted for one case but not measured; a systematic check — whether unresolved references sit near unreachable branches across the kernel — would tell whether ReCite doubles as a dead-code detector, a testable extension the paper does not run.
  • The repair rubric's 'Partial' bucket (46.5%) is mostly residual wording drift and natural-language substitutes where a concrete function name exists; that gap points to a next step of checking whether the comment's stated constraint still holds (as in the _decode_session6 case), which would turn comment repairs into refactoring suggestions.
  • A natural stress test the paper doesn't run: apply ReCite to a second kernel release and check how many of the 869 repairs recur — if the same comment goes stale again after a later refactor, the tool's value shifts from one-shot repair to continuous monitoring.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 4 minor

Summary. The paper proposes ReCite, a three-stage pipeline for detecting and repairing stale function references in Linux kernel comments: (1) extract function-form symbols from comments and resolve them against the current codebase with grep + Coccinelle; (2) trace each unresolved symbol's evolution through Git history, using an LLM to select the originally referenced entity and to classify function-removing commits as refactoring or removal; and (3) generate repair suggestions from the reconstructed evolution tree and current code context. On Linux kernel v6.18-rc1, the pipeline yields 869 repair-worthy stale references. A manual evaluation of 200 sampled repairs reports 89.0% useful guidance, 42.5% directly applicable repairs, and 0% incorrect repairs; 50 of 75 submitted kernel patches have been accepted. The paper also provides a taxonomy of all unresolved function-form mentions.

Significance. If the evaluation is sound, this is a useful contribution to code-comment maintenance. The problem is real and prior CCI work largely targets local Javadoc-style inconsistencies; the paper's focus on externally induced, cross-file stale references in C is a genuine gap. The evaluation has notable strengths: multiple independently annotated datasets with agreement metrics, a baseline comparison against RefDiff, ablations for rule-based repair and no-history variants, sensitivity checks for the Jaccard threshold, and external validation through 50 accepted kernel patches. The replication package is a plus. However, two load-bearing evaluation points—the removed/refactored classification metric and the end-to-end recall estimate—need rework before the central claims can be accepted at face value.

major comments (3)
  1. [Section 4.4, Table 5] The Repair-Worthy Detection 400 dataset is a disproportionate stratified sample: 200 predicted-positive cases are drawn from ReCite's own output and 200 predicted-negative cases are drawn from the 82,372 unflagged mentions. Precision on the positive stratum is estimable, but the 'Balanced Full' recall/F1 is not. The reported recall 178/(178+2)=98.9% is an artifact of oversampling positives. Combining the stratum sizes in Figure 5 gives an estimated 82,372 x (2/200) ≈ 824 missed true positives versus 869 x 0.89 ≈ 773 true positives found, i.e., an estimated population recall of roughly 48%, not 98.9%. Please report stratified estimates (precision from the positive sample, recall estimated by applying the false-negative rate to the negative stratum), or explicitly restrict the claim to precision on predicted positives.
  2. [Section 5.2.2, Table 3] The removed/refactored binary classification is evaluated on 191 refactored vs 7 removed cases with 'refactored' as the positive class. An always-refactored baseline achieves precision 191/198, recall 1.0, F1≈0.982, which is actually higher than ReCite's reported 0.974. The paper reports no confusion matrix and no per-class recall, so the results do not establish that ReCite can detect the rare 'removed' class. This is load-bearing because 335/869 (38.6%) evolution trees end with no surviving successor, and for those cases ReCite's repair is deletion/rephrasing. If 'removed' is routinely confused with 'refactored', those repairs may be grounded in the wrong lineage. The successor-identification F1=0.812 is computed only on cases where both tool and annotator already agree on 'refactored', so it cannot detect this confusion. Please provide the confusion matrix, per-class precision/recall,
  3. [Section 5.3] The repair evaluation reports 0 'Incorrect' suggestions out of 200, which is surprising given the tracing errors documented in Section 5.2.2 (e.g., 7 of 10 sampled localization failures) and the fact that 38.6% of evolution trees are dead ends. Without a breakdown of Acceptable/Partial/Off-Target by evolution-tree outcome (survivor vs no survivor) and by whether the LLM's stated evolution analysis was correct, it is hard to exclude the possibility that wrong-lineage deletion/rephrasing suggestions were absorbed into the 'Partial' category. Please define how an 'Incorrect' repair is distinguished from a 'Partial' one when the evolution history is wrong, and stratify the repair results accordingly.
minor comments (4)
  1. [Abstract and Section 5.3, Table 4] The abstract states 'Of our 75 submitted patches, 50 have been accepted' without noting that 24 of those 75 are manual patches. The ReCite-specific acceptance rate is 31/51; please state this qualification in the abstract or introduction.
  2. [Section 3.2.2, Algorithm 1] The text says the maximum depth is five, but Section 5.2.2 reports the deepest trees reach depth 6. Please clarify whether the root is counted as depth 0 or depth 1, and why the reported depth can exceed the limit.
  3. [Section 5.3] The quoted changelog comment 'Madenbd_end_request()' appears to contain a typo ('Maden' should likely be 'Made n...' or similar); please check the source quotation.
  4. [Section 7] The sensitivity analysis varies the Jaccard threshold (0.6 and 0.8) but not the maximum tracing depth. Since depth limit contributes to Tracing Inconclusive cases, a one-step sensitivity check would be useful.

Circularity Check

0 steps flagged

No significant circularity; central claims are grounded in manual labels and external maintainer acceptance.

full rationale

I found no load-bearing circular dependency in ReCite's derivation chain. Stage 1 (unresolved-symbol detection) is evaluated against manually annotated labels on 200 disagreement cases (Section 4.1), not against ReCite's own outputs. Stage 2 (evolution tracing) is validated with git existence checks (Exists at the removing commit and at HEAD) and is compared with the external baseline RefDiff; the ground truth for refactored/removed and successor identification is manual annotation (Section 4.2). Stage 3 (repair) is manually scored on 200 sampled repairs (Section 5.3) and additionally corroborated by 50/75 accepted Linux kernel patches (Table 4), an external outcome. RQ4 reuses the manually labeled Repair Quality 200 as predicted positives, but the labels are independent of the tool; the two false negatives were also manually identified. The ablation comparing ReCite with rule-based and no-history variants measures agreement with ReCite's own repairs, so it is an internal consistency check rather than external evidence, but it is not the basis for the headline repair-quality claim. The main evaluation-design weakness is not circularity: the Refactoring Analysis 200 dataset is imbalanced (191 refactored vs. 7 removed), so the aggregate F1=0.974 does not by itself demonstrate that the rare 'removed' class is detectable, and successor identification is measured only on cases where tool and annotator already agree on refactored. These are correctness/validity concerns, not reductions of predictions to inputs. Existing self-citations ([16], [19], [20], [22], [25]) are background, tool citations, or non-load-bearing support; none is used as an external 'uniqueness theorem' or to forbid alternative approaches. The derivation is therefore self-contained with respect to circularity, and the score is low.

Axiom & Free-Parameter Ledger

6 free parameters · 4 axioms · 0 invented entities

ReCite's central results rest on hand-chosen thresholds and domain assumptions about git history and comment-form coverage rather than on fitted physical parameters. The main risk is that the pipeline's scope is defined by the regex and the resolvable-at-introduction filter, which excludes already-stale-at-introduction references (Section 6.1). No invented entities are introduced.

free parameters (6)
  • Jaccard similarity threshold for symbol-introducing commit = 0.7
    Used in Section 3.2.1 to decide whether a historical comment line is the origin of the current symbol-bearing comment. Sensitivity analysis (0.6 vs 0.8) changes only ~0.85% of commits, so it is not highly sensitive, but it is hand-chosen.
  • Maximum evolution tracing depth = 5
    Algorithm 1 stops recursing after depth 5; cases reaching the limit are marked 'Tracing Inconclusive', e.g., ctl_clear_bit() in Section 5.2.2. No sensitivity analysis is reported.
  • LLM retry limit = 2
    Used in entity selection and change analysis to retry after invalid outputs (Sections 3.2.1, 3.2.2).
  • LLM temperature = 0
    Set to 0 for stability (Section 4).
  • Path edit distance ordering of candidate entities = nearest first
    LLM sees candidates ordered by path edit distance to the comment's file; affects entity selection (Section 3.2.1).
  • Diff hunk filter sub-token overlap = at least one '_' split subtoken
    Prunes diffs when the full diff exceeds the token limit (Section 3.2.2).
axioms (4)
  • domain assumption Git history from 2005 onward contains the complete evolution of every resolvable referenced entity; any relevant pre-Git evolution is inaccessible.
    Section 6.2 acknowledges the kernel only adopted Git in 2005, so older history is 'difficult to access'; the pipeline depends on git history for tracing.
  • domain assumption The regex '[A-Za-z_][A-Za-z0-9_]*()' captures all relevant function-form references; comments with abbreviated names, wildcard patterns, or omitted parentheses are out of scope.
    Section 3.1 defines extraction; Section 6.2 lists abbreviations/wildcards/typos as escaping coverage.
  • domain assumption Resolution to any function definition, declaration, or function-like macro in any architecture file means the symbol 'exists'; the comment's intended entity is inferred by the LLM among same-name candidates.
    Section 3.1 includes declarations to cover assembly-defined functions; Section 3.2.1 delegates intent to the LLM.
  • ad hoc to paper LLM judgments on intended entity and removed/refactored classification are reliable once validated by file-existence and entity-membership checks.
    Section 3.2.2 uses LLM analysis with validation and retries; the pipeline's accuracy depends on this validity, though the paper measures it on 200-case datasets.

reviewed 2026-08-05 · how reviews work

0 comments
Cite this review

Pith. "Pith review of We Must Have Missed This Comment: Detecting and Repairing Stale Function References in Linux Kernel Comments." pith.science (2026). https://pith.science/paper/A2IFKQLV

@misc{pith2026260803734,
  author       = {Pith},
  title        = {Pith review of: We Must Have Missed This Comment: Detecting and Repairing Stale Function References in Linux Kernel Comments},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/A2IFKQLV}},
  note         = {Machine review of arXiv:2608.03734}
}
Share X Bluesky LinkedIn Reddit HN
read the original abstract

As the Linux kernel evolves, code comments may become outdated, as the functions they reference can be refactored or removed independently without corresponding updates to the comments. Such stale function references can mislead maintainers and thus hinder code comprehension. Prior work on detecting code-comment inconsistency mainly focused on addressing semantic misalignment between Javadoc comments and their directly annotated functions, making them inapplicable to this type of externally induced staleness in the Linux kernel. Therefore, we propose ReCite, a three-stage approach to identify and repair such stale references: (1) detecting unresolved function-form symbols -- symbols in comments that appear to reference functions but for which no matching function can be found in the current codebase, (2) tracing the evolution history of each unresolved symbol through the Git history, and (3) generating LLM-based repair suggestions grounded in the evolution history and current code context. On Linux kernel v6.18-rc1, ReCite detects 869 stale references with generated repair suggestions. A manual evaluation on 200 sampled repairs shows that 178 (89.0%) provide useful repair guidance, with 85 (42.5%) directly applicable. Of our 75 submitted patches, 50 have been accepted. We also empirically study all unresolved function-form symbols.

Figures

Figures reproduced from arXiv: 2608.03734 by David Lo, He Zhang, Hongyu Kuang, Julia Lawall, Kexin Sun, Ratnadira Widyasari, Xiaoxing Ma, Xutong Ma, Yunbo Lyu.

Figure 1
Figure 1. Figure 1: Prior CCI work vs. our focus. Prior work detects [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: A motivating example of a stale function reference [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Overview of ReCite for identifying and repairing stale function references in Linux kernel comments. evolving code and its accompanying documentation are pervasive across software artifacts. Prior work has studied outdated code names or samples in API documentation [12, 13, 47], stale code references in README files [39, 40] and outdated code snippets on Q&A posts [30]. With the growing capability of large… view at source ↗
Figure 4
Figure 4. Figure 4: Evolution trees of two code entities. Green marks [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Attrition flow of ReCite’s stale-function-reference detection and repair pipeline. reasons can also be understood through the taxonomy established in Section 6.1. We summarize the above attrition flow in [PITH_FULL_IMAGE:figures/full_fig_p006_5.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

49 extracted references · 36 canonical work pages · 2 internal anchors

  1. [1]

    2026. Claude. https://claude.ai

    work page 2026

  2. [2]

    Max Brunsfeld et al. 2026. Tree-sitter: A Parser Generator Tool and an Incremental Parsing Library. https://tree-sitter.github.io/tree-sitter/. Accessed: 2026-03

    work page 2026

  3. [4]

    Beat Fluri, Michael Wursch, Martin PInzger, and Harald Gall. 2007. Change distilling: Tree differencing for fine-grained source code change extraction.IEEE Transactions on software engineering33, 11 (2007), 725–743

    2007

  4. [5]

    2018.Refactoring: improving the design of existing code

    Martin Fowler. 2018.Refactoring: improving the design of existing code. Addison- Wesley Professional

    2018

  5. [6]

    Haoyu Gao, Hong Yi Lin, Christoph Treude, Gregory Gay, and Mansooreh Zahedi

    work page

  6. [7]

    Yuan Huang, Yinan Chen, Xiangping Chen, and Xiaocong Zhou. 2025. Are your comments outdated? Toward automatically detecting code-comment consistency. Journal of Software: Evolution and Process37, 1 (2025), e2718. doi:10.1002/smr.2718

    work page doi:10.1002/smr.2718 2025

  7. [8]

    Walid M Ibrahim, Nicolas Bettenburg, Bram Adams, and Ahmed E Hassan. 2012. On the relationship between comment update practices and software bugs.Jour- nal of Systems and Software85, 10 (2012), 2293–2304

    work page 2012

  8. [9]

    James Ivers, Robert L Nord, Ipek Ozkaya, Chris Seifried, Christopher S Timperley, and Marouane Kessentini. 2022. Industry experiences with large-scale refactoring. InProceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering. 1544–1554

    work page 2022

  9. [10]

    Anil Kurmus, Reinhard Tartler, Daniela Dorneanu, Bernhard Heinloth, Valentin Rothberg, Andreas Ruprecht, Wolfgang Schröder-Preikschat, Daniel Lohmann, and Rüdiger Kapitza. 2013. Attack Surface Metrics and Automated Compile-Time OS Kernel Tailoring. InNDSS

    work page 2013

  10. [11]

    Hyeonseok Lee, Gabin An, and Shin Yoo. 2025. METAMON: Finding Inconsisten- cies between Program Documentation and Behavior using Metamorphic LLM Queries. arXiv:2502.02794 [cs.SE] https://arxiv.org/abs/2502.02794

    work page internal anchor Pith review Pith/arXiv arXiv 2025

  11. [12]

    Seonah Lee, Jueun Heo, and Katherine R Dearstyne. 2025. Can LLMs Update API Documentation?. In2025 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 1–12

    work page 2025

  12. [13]

    Seonah Lee, Rongxin Wu, Shing-Chi Cheung, and Sungwon Kang. 2019. Auto- matic detection and update suggestion for outdated API names in documentation. IEEE Transactions on Software Engineering47, 4 (2019), 653–675

    work page 2019

  13. [14]

    Bo Lin, Shangwen Wang, Zhongxin Liu, Yepang Liu, Xin Xia, and Xiaoguang Mao. 2023. Cct5: A code-change-oriented pre-trained model. InProceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering. 1509–1521

    work page 2023

  14. [15]

    Aixin Liu, Aoxue Mei, Bangcai Lin, Bing Xue, Bingxuan Wang, Bingzheng Xu, Bochao Wu, Bowei Zhang, Chaofan Lin, Chen Dong, et al . 2025. Deepseek- v3. 2: Pushing the frontier of open large language models.arXiv preprint arXiv:2512.02556(2025)

    Pith/arXiv arXiv 2025

  15. [16]

    Yue Liu, Thanh Le-Cong, Ratnadira Widyasari, Chakkrit Tantithamthavorn, Li Li, Xuan-Bach D Le, and David Lo. 2024. Refining ChatGPT-generated code: Characterizing and mitigating code quality issues.ACM Transactions on Software Engineering and Methodology33, 5 (2024), 1–26

    work page 2024

  16. [17]

    Zhiyong Liu, Huanchao Chen, Xiangping Chen, Xiaonan Luo, and Fan Zhou

    work page

  17. [18]

    Zhongxin Liu, Xin Xia, Meng Yan, and Shanping Li. 2021. Automating just- in-time comment updating. InProceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering(Virtual Event, Australia)(ASE ’20). Association for Computing Machinery, New York, NY, USA, 585–597. doi:10. 1145/3324884.3416581

    work page arXiv 2021

  18. [19]

    Yunbo Lyu, Hong Jin Kang, Ratnadira Widyasari, Julia Lawall, and David Lo. 2024. Evaluating SZZ Implementations: An Empirical Study on the Linux Kernel.IEEE Trans. Softw. Eng.50, 9 (Sept. 2024), 2219–2239. doi:10.1109/TSE.2024.3406718

    arXiv 2024

  19. [20]

    Yunbo Lyu, Jieke Shi, Hong Jin Kang, Ratnadira Widyasari, Junda He, Yuqing Niu, Chengran Yang, Junkai Chen, Zhou Yang, Julia Lawall, et al. 2026. AgentSZZ: Teaching the LLM Agent to Play Detective with Bug-Inducing Commits.arXiv preprint arXiv:2604.02665(2026)

    Pith/arXiv arXiv 2026

  20. [21]

    Yunbo Lyu, David Williams, Jieke Shi, Zhensu Sun, Chao Peng, Zhou Yang, Federica Sarro, and David Lo. 2026. How Do Practitioners Build SE Agents? Insights from a Mixed-Methods Study.arXiv preprint arXiv:2607.10856(2026)

    work page internal anchor Pith review Pith/arXiv arXiv 2026

  21. [22]

    My productivity is boosted, but

    Yunbo Lyu, Zhou Yang, Jieke Shi, Jianming Chang, Yue Liu, and David Lo. 2025. "My productivity is boosted, but . . . " Demystifying Users’ Perception on AI Coding Assistants. In2025 40th IEEE/ACM International Conference on Automated Software Engineering (ASE). 191–203. doi:10.1109/ASE63991.2025.00024

    arXiv 2025

  22. [23]

    Phong Nguyen, Anh M. T. Bui, and Phuong T. Nguyen. 2026. Larger Is Not Always Better: Leveraging Structured Code Diffs for Comment Inconsistency Detection. In2026 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER)

    work page 2026

  23. [24]

    Shuyin Ouyang, Jie M Zhang, Mark Harman, and Meng Wang. 2025. An empirical study of the non-determinism of ChatGPT in code generation.ACM Transactions on Software Engineering and Methodology34, 2 (2025), 1–28

    work page 2025

  24. [25]

    Yoann Padioleau, Julia Lawall, René Rydhof Hansen, and Gilles Muller. 2008. Documenting and automating collateral evolutions in linux device drivers. In Proceedings of the 3rd ACM SIGOPS/EuroSys European Conference on Computer Systems 2008(Glasgow, Scotland UK)(Eurosys ’08). Association for Computing Machinery, New York, NY, USA, 247–260. doi:10.1145/1352...

    work page arXiv 2008

  25. [26]

    Sheena Panthaplackel, Junyi Jessy Li, Milos Gligoric, and Raymond J Mooney

    work page

  26. [27]

    Sheena Panthaplackel, Pengyu Nie, Milos Gligoric, Junyi Jessy Li, and Raymond Mooney. 2020. Learning to update natural language comments based on code changes. InProceedings of the 58th Annual Meeting of the Association for Compu- tational Linguistics. 1853–1868

    2020

  27. [28]

    Anh Quach, Aravind Prakash, and Lok Yan. 2018. Debloating software through {Piece-Wise} compilation and loading. In27th USENIX security symposium (USENIX Security 18). 869–886

    work page 2018

  28. [29]

    Fazle Rabbi and Md Saeed Siddik. 2020. Detecting code comment inconsistency us- ing siamese recurrent network. InProceedings of the 28th international conference on program comprehension. 371–375

    work page 2020

  29. [30]

    Chaiyong Ragkhitwetsagul, Jens Krinke, Matheus Paixao, Giuseppe Bianco, and Rocco Oliveto. 2019. Toxic code snippets on stack overflow.IEEE Transactions on Software Engineering47, 3 (2019), 560–581

    work page 2019

  30. [31]

    Robillard

    Inderjot Kaur Ratol and Martin P. Robillard. 2017. Detecting fragile comments. In 2017 32nd IEEE/ACM International Conference on Automated Software Engineering (ASE). 112–122. doi:10.1109/ASE.2017.8115624

    arXiv 2017

  31. [32]

    Guoping Rong, Yongda Yu, Song Liu, Xin Tan, Tianyi Zhang, Haifeng Shen, and Jidong Hu. 2025. Code Comment Inconsistency Detection and Rectification Using a Large Language Model. InProceedings of the IEEE/ACM 47th International Conference on Software Engineering(Ottawa, Ontario, Canada)(ICSE ’25). IEEE Press, 1832–1843. doi:10.1109/ICSE55347.2025.00035

    arXiv 2025

  32. [33]

    Danilo Silva, João Paulo da Silva, Gustavo Santos, Ricardo Terra, and Marco Tulio Valente. 2020. RefDiff 2.0: A multi-language refactoring detection tool.IEEE Transactions on Software Engineering47, 12 (2020), 2786–2802

    work page 2020

  33. [34]

    Danilo Silva, Nikolaos Tsantalis, and Marco Tulio Valente. 2016. Why we refactor? confessions of GitHub contributors. InProceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering(Seattle, WA, USA)(FSE 2016). Association for Computing Machinery, New York, NY, USA, 858–870. doi:10.1145/2950290.2950305

    work page arXiv 2016

  34. [35]

    Tama Communications Corporation. 2026. GNU GLOBAL Source Code Tagging System. https://www.gnu.org/software/global/. Accessed: 2026-03

    work page 2026

  35. [36]

    Lin Tan, Ding Yuan, Gopal Krishna, and Yuanyuan Zhou. 2007. /*icomment: bugs or bad comments?*/. InProceedings of Twenty-First ACM SIGOPS Sym- posium on Operating Systems Principles(Stevenson, Washington, USA)(SOSP ’07). Association for Computing Machinery, New York, NY, USA, 145–158. doi:10.1145/1294261.1294276

    arXiv 2007

  36. [37]

    Lin Tan, Yuanyuan Zhou, and Yoann Padioleau. 2011. aComment: mining anno- tations from comments and code to detect interrupt related concurrency bugs. In Proceedings of the 33rd international conference on software engineering. 11–20

    work page 2011

  37. [38]

    Shin Hwei Tan, Darko Marinov, Lin Tan, and Gary T Leavens. 2012. @ tcomment: Testing javadoc comments to detect comment-code inconsistencies. In2012 IEEE Fifth International Conference on Software Testing, Verification and Validation. IEEE, 260–269

    work page 2012

  38. [39]

    Wen Siang Tan, Markus Wagner, and Christoph Treude. 2023. Wait, wasn’t that code here before? Detecting Outdated Software Documentation. In2023 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 553–557

    work page 2023

  39. [40]

    Wen Siang Tan, Markus Wagner, and Christoph Treude. 2024. Detecting out- dated code element references in software repository documentation.Empirical Software Engineering29, 1 (2024), 5

    work page 2024

  40. [41]

    Ye Tang, Aoyang Yan, Hui Liu, Na Meng, and Hao Zhong. 2026. Detecting out- dated screenshot from GUI document.ACM Transactions on Software Engineering and Methodology35, 5 (2026), 1–26

    work page 2026

  41. [42]

    The Linux Kernel Community. 2024. How the Development Process Works. The Linux Kernel Documentation. Accessed: 2026. https://docs.kernel.org/process/2. Process.html

    work page 2024

  42. [43]

    Universal Ctags Team. 2026. Universal Ctags: A Maintained Ctags Implementa- tion. https://ctags.io/. Accessed: 2026-03

    work page 2026

  43. [44]

    Fengcai Wen, Csaba Nagy, Gabriele Bavota, and Michele Lanza. 2019. A large- scale empirical study on code-comment inconsistencies. InProceedings of the 27th International Conference on Program Comprehension(Montreal, Quebec, Canada) (ICPC ’19). IEEE Press, 53–64. doi:10.1109/ICPC.2019.00019 We Must Have Missed This Comment: Detecting and Repairing Stale F...

    arXiv 2019

  44. [45]

    Xiaomeng Xu, Zahin Wahab, Reid Holmes, and Caroline Lemieux. 2025. DocPrism: Local Categorization and External Filtering to Identify Relevant Code- Documentation Inconsistencies. arXiv:2511.00215 [cs.SE] https://arxiv.org/abs/ 2511.00215

    Pith/arXiv arXiv 2025

  45. [46]

    Zhengkang Xu, Shikai Guo, Yumiao Wang, Rong Chen, Hui Li, Xiaochen Li, and He Jiang. 2024. Code Comment Inconsistency Detection Based on Confidence Learning.IEEE Transactions on Software Engineering50, 3 (2024), 598–617. doi:10. 1109/TSE.2024.3358489

    work page arXiv 2024

  46. [47]

    Hao Zhong and Zhendong Su. 2013. Detecting API documentation errors. In Proceedings of the 2013 ACM SIGPLAN International Conference on Object Ori- ented Programming Systems Languages & Applications(Indianapolis, Indiana, USA)(OOPSLA ’13). Association for Computing Machinery, New York, NY, USA, 803–816. doi:10.1145/2509136.2509523

    work page arXiv 2013

  47. [2018]

    In2018 IEEE 42nd Annual Computer Software and Applications Conference (COMPSAC), Vol

    Automatic detection of outdated comments during code changes. In2018 IEEE 42nd Annual Computer Software and Applications Conference (COMPSAC), Vol. 1. IEEE, 154–163

    work page

  48. [2021]

    InProceedings of the AAAI conference on artificial intelligence, Vol

    Deep just-in-time inconsistency detection between comments and source code. InProceedings of the AAAI conference on artificial intelligence, Vol. 35. 427– 435

    work page

  49. [2026]

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

    Does My README File Need To Be Updated? Exploring LLM-Based README Maintenance. arXiv:2603.00489 [cs.SE] https://arxiv.org/abs/2603. 00489

    arXiv

This paper was first reviewed by deepseek-v4-flash on August 5, 2026.