Pith. sign in

REVIEW 4 major objections 4 minor 36 references

Maintenance Signals in AI-Assisted GitHub Repositories: Evidence from GenAI Adopters

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

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

Pith's one-line read This paper claims that generative AI assistance in software development does not eliminate maintenance work but shifts it toward verifying AI-generated content, managing external AI dependencies, and validating AI-specific behavior, with ob

desk verdict A transparent, well-scoped observational study that finds plausible maintenance signals in visible GenAI-adopter repos, but the headline causal claim leans on a small single-annotator issue contrast that can't carry it. read the letter →

arxiv 2607.21079 v1 pith:7KKVD5Q2 submitted 2026-07-23 cs.SE

Rikuto Tsuchida , Youmei Fan , Kazumasa Shimari , Raula Gaikovina Kula , Gema Rodríguez-Pérez , Kenichi Matsumoto This is my paper
classification cs.SE
keywords GenerativeAIAI-assistedsoftwaredevelopmentGitHubrepositoryminingmaintenancecostsissueclassificationREADMEdocumentationexternalAPIdependenciesagents
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 tries to establish that using generative AI in software development redistributes maintenance effort rather than simply removing it. Studying developers who publicly signal GenAI adoption on GitHub, the authors find that repositories with visible AI-assistance configuration files have longer, more structured READMEs but fewer external links, and that issues about GenAI technology concentrate on external dependencies such as API rate limits and provider APIs. The difference in external-focused issues survives removing the single most active contributor, so it is not an artifact of one prolific user. If correct, the finding tells developers and tool builders that AI assistance creates predictable new maintenance obligations around verifying generated content, managing external AI services, and validating AI-specific behavior.

What carries the argument

The central object is the 'AI-assisted repository,' identified by committed agent configuration files (e.g., .cursorrules, CLAUDE.md, MCP server configs) or .gitignore mentions of them, matched 1:1 to traditional repositories by commit count via the Hungarian algorithm. The other load-bearing instrument is the two-layer issue taxonomy: Issue Type (Bug/Enhancement/Other) and Outcome (External/Internal/UI/UX/Developer Experience/Environment/Documentation), used to compare GenAI-related and Non-GenAI-related issues within AI-assisted repositories. These two tools convert invisible adoption into measurable repository- and issue-level signals.

What would settle it

A concrete check would be to remove from the GenAI-related issue set all issues whose text mentions API, rate limit, or a GenAI provider name (such as OpenAI or Anthropic) and see whether the External proportion drops to the Non-GenAI level; if it does, the result would be shown to be driven by provider naming rather than by maintenance behavior. Alternatively, re-running the issue classification on repositories whose AI use is detected through a different proxy, such as commit-message patterns, would test whether the External concentration is specific to configuration-file-based identificatio

Watch

Extended reading notes

Core claim

The paper claims that maintenance-cost signals in GenAI adopters' repositories concentrate where AI-generated content meets the outside world. In 248 issues from 179 AI-assisted repositories, GenAI-related issues were more likely than Non-GenAI issues to be External (third-party APIs, rate limits, output formatting): 36.3% External in the full sample, and still 28.6% vs. 8.8% after removing the dominant issue creator (Fisher's exact p=0.025). AI-assisted repositories matched traditional ones in project type, but had longer READMEs with more headers and code blocks and fewer URLs — more structure, weaker external-resource curation. The paper presents these as early signs that AI assistance sh

Load-bearing premise

The study's central assumption is that a repository with committed agent configuration files (like .cursorrules or CLAUDE.md) is genuinely AI-assisted and one without them is traditional; chat-based assistants leave no such repository trace, so a large share of actual AI usage is likely misclassified, and this could bias both the README comparison and the issue analysis.

Editorial extensions

If this is right

  • Developers using GenAI should expect and budget for maintenance work around external provider APIs: rate limits, authentication, model availability, and output-format changes.
  • README structure can be improved by AI assistance, but external-resource curation — choosing and maintaining URLs — still requires human judgment, so tooling should not claim to automate it.
  • Early AI-assisted projects look feature-oriented rather than stabilization-oriented, with more Enhancement than Bug issues in both GenAI-related and Non-GenAI-related issues.
  • The concentration of GenAI-related issues in External outcomes is robust to removing the single most active issue creator, strengthening the claim that it reflects a general pattern rather than one project's experience.
  • Repository classification alone will not separate AI-assisted from traditional development; visible AI assistance spreads across all five software categories, so studies should not treat it as a single application domain.

Reading between the lines

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

  • If the External-concentration result generalizes beyond visible early adopters, the cost picture for AI assistance is not 'less work' but 'different work': organizations will need monitoring, abstraction layers, and retry/fallback strategies around AI provider APIs.
  • A testable extension would be to examine repositories where AI use is evidenced by commit messages or code patterns rather than configuration files, and ask whether the same External concentration appears.
  • The finding that AI-assisted READMEs are longer but have fewer URLs suggests generated documentation may systematically under-cite external resources; a direct follow-up would check whether URLs in AI-assisted READMEs are more likely to be broken or hallucinated than those in traditional ones.
  • Since GenAI-related issues cluster on API rate limits and output parsing, tool builders might invest more in caching, request batching, and schema validation for AI responses than in better code completion.
Share X Bluesky LinkedIn Reddit HN

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. The paper investigates whether visible GenAI adoption on GitHub is associated with observable maintenance-cost signals. The authors identify 622 adopters via profile keywords, detect 179 'AI-assisted' repositories through committed agent-configuration files (e.g., .cursorrules, CLAUDE.md, MCP configs), match them to 179 traditional repositories by commit count, and analyze 248 issues created by the adopters in the AI-assisted repositories. RQ1 finds no significant category difference but longer READMEs and more headers/code blocks in AI-assisted repositories. RQ2 finds that GenAI-related issues are more often classified as External (API and third-party service issues) than Non-GenAI-related issues, with the difference surviving removal of a dominant contributor (28.6% vs 8.8%, Fisher's exact p=0.025, OR 4.16). The abstract concludes that AI assistance shifts maintenance costs toward verifying generated content, managing external AI dependencies, and validating AI-specific behavior.

Significance. If the central association is validated and interpreted carefully, this would be a useful early empirical contribution to understanding GenAI adoption in open-source maintenance. The paper's strengths include a public replication package, a clearly documented data-collection funnel, Bonferroni-corrected statistical tests, and a sensitivity analysis removing the dominant issue contributor. However, the headline causal claim is not supported by the cross-sectional design: the RQ2 comparison lacks any baseline from traditional repositories or from the same repositories before GenAI adoption, and the exposure measure captures only repository-visible agent configurations. The paper is transparent about several of these limitations, but the abstract and implications overstate what the evidence can establish.

major comments (4)
  1. [Abstract; §3.2; §7] The paper's central claim—that AI assistance 'shifts maintenance costs'—is causal, but the RQ2 design compares GenAI-related vs Non-GenAI-related issues only within AI-assisted repositories. There is no comparison with issues from matched traditional repositories (Table 1) or from the same repositories before GenAI adoption. The External concentration (36.3% vs 16.7% full sample; 28.6% vs 8.8% after dominant-contributor removal, §5) may simply reflect that GenAI applications are architecturally dependent on remote provider APIs, independent of whether the repository uses AI assistance. The causal 'shifts' language should be replaced with associational wording, or a control comparison must be added.
  2. [§3.2; §5 Internal Validity] All 248 issues were labeled by a single annotator with no inter-rater reliability measure. The key RQ2 contrast after removing the dominant contributor rests on 8 GenAI-related External issues versus 5 Non-GenAI External issues; changing a small number of labels could erase the Fisher exact p=0.025. The authors also acknowledge that GenAI-relatedness and Outcome are 'not fully independent' (§5). A second annotator on a sample (with Cohen's kappa) or a sensitivity analysis with conservative relabeling is needed before this result can be treated as robust.
  3. [§3.1; §5 Construct Validity] AI assistance is operationalized solely through committed agent-configuration files (.cursorrules, CLAUDE.md, MCP server configs) or .gitignore references. This misses chat-based assistants such as Copilot or ChatGPT, which leave no repository trace. Consequently, some 'traditional' repositories may be AI-assisted, and RQ2's issue set comes only from the agent-config subset. The authors disclose this in §5, but it is load-bearing: the RQ1 and RQ2 comparisons may not generalize to the broader population of AI-assisted development. Please test an alternative exposure definition or explicitly restrict all claims to 'repository-visible agent-config AI assistance.'
  4. [Abstract; §3.1; §4.1] The abstract's first element—'verifying generated content'—is not operationalized anywhere in the study. README length, header density, and code-block density (Table 4) are structural proxies, not evidence of verification effort. The issue taxonomy has no verification category. If output-format parsing issues are intended to stand for 'verifying generated content,' the authors should make that mapping explicit; otherwise the claim should be dropped or narrowed to 'external dependencies and AI-specific behavior,' which are actually measured.
minor comments (4)
  1. [Figure 3] The figure's percentages are difficult to parse: outcome percentages are shown within each issue type, while the caption cites group-level percentages (36.3% External, 45.8% UI/UX). Please redraw or annotate to make the group-level totals clear.
  2. [Table 4] Raw p-values are shown for all six tests, but only three pass the Bonferroni-adjusted threshold (α≈0.0083). Mark the surviving tests explicitly (e.g., with an asterisk) to avoid over-reading the URL and image results.
  3. [§2.2] The adopter keyword set ('AI Agent', 'AI App', 'Vibe Coding') is presented as a team decision with no validation. Since the whole sample depends on this set, a brief justification or sensitivity check with tool-name keywords would strengthen the paper.
  4. [§4.1] The claim that AI-assisted repositories are 'feature-centric' based on the Enhancement-to-Bug ratio (6.0 vs 4.0 after removing the dominant contributor) is weak: issues created by the repository owner in their own repository may not reflect broader project maturity. Consider softening this implication.

Circularity Check

1 steps flagged · score 3.0 of 10

RQ2 'GenAI-related issues are more External' result is partially definitional: 'GenAI-related' and 'External' labels overlap by construction; authors disclose the non-independence. No fitted parameters or load-bearing self-citation elsewhere.

  1. self definitional [Section 3.2 (classification procedure and Table 5); Section 5 (Internal Validity, fourth factor)]
    "we labeled each issue as GenAI-related or Non-GenAI-related according to whether the issue itself concerned GenAI technology. ... Fourth, the GenAI-relatedness and Outcome dimensions are not fully independent. Because user-interface issues rarely concern GenAI technology, they tend to be labeled Non-GenAI-related, so we treat the Outcome distribution as descriptive rather than as a strong contrast between the two issue groups."

    The Outcome category 'External' is defined in Table 5 as 'Affects external interfaces such as third-party APIs', and the GenAI-related label is assigned when an issue 'concerned GenAI technology'. Because GenAI functionality is predominantly consumed through third-party provider APIs, an issue such as '429 Too Many Requests for OpenAI Embeddings' is both GenAI-related by definition and External by definition. The RQ2 finding that GenAI-related issues concentrate in External (36.3% vs. lower for Non-GenAI; still significant at 28.6% vs. 8.8% after dominant-contributor removal) is thereby partly produced by the overlap of the two labeling schemes rather than by independent measurement. The paper concedes this in Section 5, explicitly treating the Outcome distribution as only descriptive, whi

full rationale

The paper is a self-contained observational study: no equations, no fitted parameters, and no 'prediction' that reduces to an input. RQ1 findings (longer READMEs with more headers/code blocks in AI-assisted repos; more URLs in traditional repos) are direct comparisons of independently measured repository content. The only overlapping-author citation, Ref [26] (Xiao, Fan, ...), is a related-work entry on self-admitted GenAI usage and is not load-bearing for the central claims. The one genuinely circular element is the RQ2 issue classification: 'GenAI-related' and 'External' are defined in ways that overlap by construction, since GenAI technology is mostly delivered via external provider APIs, so the 'GenAI-related issues are more External' result is partly a consequence of the classification scheme itself. The authors explicitly disclose this in Section 5, stating that the two dimensions 'are not fully independent' and treating the Outcome distribution as descriptive. That disclosure, plus the fact that only about a third of GenAI-related issues are External (so the categories do not fully coincide), keeps the circularity partial rather than structural. The causal framing in the abstract ('AI assistance shifts maintenance costs toward ... external AI dependencies') does outrun the observational design, but that is a correctness/validity concern, not circularity. The remaining limitations (single annotator, no inter-rater reliability, proxy-based repo labeling) are also validity issues, not circularity. Overall: one acknowledged definitional overlap producing a headline RQ2 contrast; everything else is independent empirical counting. Score 3.

Assumptions & free parameters 3 free parameters · 6 assumptions · 0 invented entities

No mathematical derivation is attempted; the empirical claims rest on sampling and classification assumptions listed above. The only free parameters are hand-selected sampling thresholds and significance corrections; none are fitted to the outcome.

free parameters (3)
  • Profile keyword set = "AI Agent", "AI App", "Vibe Coding"
    Gates the adopter sample; selected through team discussion, not derived from data (Section 2.2).
  • Activity thresholds = >=10 public repos, >=10 commits/year, 1-month update window
    Hand-chosen filters to exclude inactive or new accounts; directly affect sample composition (Table 2).
  • Significance threshold = alpha = 0.0083 (Bonferroni over six tests)
    Standard multiple-comparison correction, but the choice determines which README metrics count as significant (Table 4).
assumptions (6)
  • domain assumption Committed AI-agent configuration files (.cursorrules, CLAUDE.md, MCP configs) and .gitignore references identify AI-assisted repositories; absence identifies traditional repositories.
    Entry point for both RQ1 samples and the RQ2 issue set; disclosed as a limitation in Section 5 (Construct Validity).
  • domain assumption The English profile phrases 'AI Agent', 'AI App', and 'Vibe Coding' identify GenAI adopters.
    Section 2.2; tool-name-only or non-English adopters are missed, as the authors acknowledge.
  • domain assumption Single-annotator issue labels for GenAI-relatedness and Outcome are valid without inter-rater agreement.
    Section 3.2 and Section 5 (Internal Validity); all 248 issues labeled by the first author, with team discussion for ambiguous cases but no IRR measure.
  • domain assumption Commit-count matching is a sufficient proxy for repository scale and comparability.
    Section 3.1 and Section 5 (Internal Validity); matching ignores domain, age, and team size.
  • domain assumption Zanartu et al.'s automated repository classifier applies validly to these repositories.
    Section 3.1 (RQ1.1) relies on the classifier for the five-category taxonomy.
  • standard math Statistical test assumptions for Mann-Whitney U, Chi-square, and Fisher's exact tests hold on these samples.
    Standard tests invoked in Sections 3.1 and 3.2.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Maintenance Signals in AI-Assisted GitHub Repositories: Evidence from GenAI Adopters." pith.science (2026). https://pith.science/paper/7KKVD5Q2

@misc{pith2026260721079,
  author       = {Pith},
  title        = {Pith review of: Maintenance Signals in AI-Assisted GitHub Repositories: Evidence from GenAI Adopters},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7KKVD5Q2}},
  note         = {Machine review of arXiv:2607.21079}
}
read the original abstract

Generative artificial intelligence (GenAI) can reduce code-generation effort, but it may shift work to documentation, validation, debugging, and maintenance. We study observable maintenance-cost signals among GenAI adopters on GitHub by analyzing 622 users who publicly signal adoption, 179 repositories with visible AI-assistance configuration files, 179 matched traditional repositories, and 248 issues created in AI-assisted repositories. AI-assisted repositories span diverse project types and contain longer README files with more headers and code blocks, while traditional repositories contain more external URLs. Issues concerning GenAI technology often involve external dependencies, such as API rate limits and reliance on GenAI provider APIs. These findings suggest that AI assistance shifts maintenance costs toward verifying generated content, managing external AI dependencies, and validating AI-specific behavior.

Figures

Figures reproduced from arXiv: 2607.21079 by the authors.

Figure 1
Figure 1. Repository category distribution comparing 179 AI-assisted and 179 traditional [PITH_FULL_IMAGE:figures/full_fig_p009_1.png] view at source ↗
Figure 2
Figure 2. README quality comparison across six metrics: Character Count, H1 per 1k [PITH_FULL_IMAGE:figures/full_fig_p009_2.png] view at source ↗
Figure 3
Figure 3. Issue classification comparing GenAI-related issues with N=80 and Non-GenAI￾related issues with N=168. Blue represents GenAI-related issues and gray represents Non￾GenAI-related issues. GenAI-related issues show a higher proportion of External at 36.3%, whereas Non-GenAI-related issues predominantly focus on UI/UX at 45.8%. In the figure, issue-type percentages are of each group’s total, while outcome percentages ar… view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

36 extracted references · 6 linked inside Pith

  1. [1]

    A. E. Hassan, H. Li, D. Lin, B. Adams, T.-H. Chen, Y. Kashiwa, D. Qiu, Agentic software engineering: Foundational pillars and a re- search roadmap (2026).arXiv:2509.06216. URLhttps://arxiv.org/abs/2509.06216

    arXiv 2026

  2. [2]

    Roychoudhury, Agentic ai for software: thoughts from software engi- neering community (2025).arXiv:2508.17343

    A. Roychoudhury, Agentic ai for software: thoughts from software engi- neering community (2025).arXiv:2508.17343. URLhttps://arxiv.org/abs/2508.17343

    arXiv 2025

  3. [3]

    H. Li, H. Zhang, A. E. Hassan, The rise of ai teammates in software engineering (se) 3.0: How autonomous coding agents are reshaping soft- ware engineering (2025).arXiv:2507.15003. URLhttps://arxiv.org/abs/2507.15003

    arXiv 2025

  4. [4]

    Watanabe, H

    M. Watanabe, H. Li, Y. Kashiwa, B. Reid, H. Iida, A. E. Hassan, On the use of agentic coding: An empirical study of pull requests on github, ACM Trans. Softw. Eng. Methodol.Just Accepted (Mar. 2026).doi: 10.1145/3798166. URLhttps://doi.org/10.1145/3798166

    doi:10.1145/3798166 2026

  5. [5]

    K. E. Haji, C. Brandt, A. Zaidman, Using github copilot for test gener- ation in python: An empirical study, in: 2024 IEEE/ACM International Conference on Automation of Software Test (AST), 2024, pp. 45–55. 21

    2024

  6. [6]

    Sergeyuk, Y

    A. Sergeyuk, Y. Golubev, T. Bryksin, I. Ahmed, Using ai-based coding assistants in practice: State of affairs, perceptions, and ways forward, Information and Software Technology 178 (2025) 107610. doi:https://doi.org/10.1016/j.infsof.2024.107610. URLhttps://www.sciencedirect.com/science/article/pii/ S0950584924002155

    arXiv 2025

  7. [7]

    Z. S. Li, N. N. Arony, A. M. Awon, D. Damian, B. Xu, Ai tool use and adoption in software development by individuals and organizations: A grounded theory study (2024).arXiv:2406.17325. URLhttps://arxiv.org/abs/2406.17325

    arXiv 2024

  8. [8]

    J. T. Liang, C. Yang, B. A. Myers, A large-scale survey on the usability of ai programming assistants: Successes and challenges, in: Proceedings of the IEEE/ACM 46th International Conference on Software Engineer- ing, ICSE ’24, Association for Computing Machinery, New York, NY, USA, 2024.doi:10.1145/3597503.3608128. URLhttps://doi.org/10.1145/3597503.3608128

    arXiv 2024

Show all 36 references
  1. [9]

    A. E. Hassan, G. A. Oliva, D. Lin, B. Chen, Z. M. J. Jiang, Towards ai- native software engineering (se 3.0): A vision and a challenge roadmap, ACM Trans. Softw. Eng. Methodol.Just Accepted (Apr. 2026).doi: 10.1145/3807901. URLhttps://doi.org/10.1145/3807901

    2026 doi

  2. [10]

    Zanartu, C

    F. Zanartu, C. Treude, B. Cartaxo, H. S. Borges, P. Moura, M. Wagner, G. Pinto, Automatically categorising github repositories by application domain (2022).arXiv:2208.00269. URLhttps://arxiv.org/abs/2208.00269

    2022 arXiv

  3. [11]

    vibe coding

    A. Karpathy, There’s a new kind of coding i call “vibe coding”, X, [Ac- cessed: Dec. 19, 2025] (2025). URLhttps://x.com/karpathy/status/1886192184808149383

    2025

  4. [12]

    Y. Zhao, A. Serebrenik, Y. Zhou, V. Filkov, B. Vasilescu, The impact of continuous integration on other software development practices: A large-scale empirical study, in: 2017 32nd IEEE/ACM International Conference on Automated Software Engineering (ASE), 2017, pp. 60–71. doi:...

    2017

  5. [13]

    H. W. Kuhn, The hungarian method for the assignment problem, Naval Research Logistics Quarterly 2 (1-2) (1955) 83–97.arXiv:https: //onlinelibrary.wiley.com/doi/pdf/10.1002/nav.3800020109, doi:https://doi.org/10.1002/nav.3800020109. URLhttps://onlinelibrary.wiley.com/doi/abs/10...

    1955 doi

  6. [14]

    H. B. Mann, D. R. Whitney, On a test of whether one of two random variables is stochastically larger than the other, The annals of mathe- matical statistics (1947) 50–60

    1947

  7. [15]

    Cliff, Dominance statistics: Ordinal analyses to answer ordinal ques- tions., Psychological bulletin 114 (3) (1993) 494

    N. Cliff, Dominance statistics: Ordinal analyses to answer ordinal ques- tions., Psychological bulletin 114 (3) (1993) 494

    1993

  8. [16]

    Romano, J

    J. Romano, J. D. Kromrey, J. Coraggio, J. Skowronek, L. Devine, Exploring methods for evaluating group differences on the nsse and other surveys: Are the t-test and cohen’sd indices the most appropriate choices, in: annual meeting of the Southern Association for Institutional ...

    2006

  9. [17]

    Kallis, O

    R. Kallis, O. Chaparro, A. Di Sorbo, S. Panichella, Nlbse’22 tool com- petition, in: 2022 IEEE/ACM 1st International Workshop on Natu- ral Language-Based Software Engineering (NLBSE), 2022, pp. 25–28. doi:10.1145/3528588.3528664

    2022

  10. [18]

    X. Chen, C. Gao, C. Chen, G. Zhang, Y. Liu, An empirical study on challenges for llm application developers, ACM Trans. Softw. Eng. Methodol. 34 (7) (Aug. 2025).doi:10.1145/3715007. URLhttps://doi.org/10.1145/3715007

    2025 doi

  11. [19]

    Y. Liu, E. Noei, K. Lyons, How readme files are structured in open source java projects, Information and Software Technology 148 (2022) 106924.doi:https://doi.org/10.1016/j.infsof.2022.106924. URLhttps://www.sciencedirect.com/science/article/pii/ S0950584922000775

    2022

  12. [20]

    T. Wang, S. Wang, T.-H. P. Chen, Study the correlation between the readme file of github projects and their popu- larity, Journal of Systems and Software 205 (2023) 111806. doi:https://doi.org/10.1016/j.jss.2023.111806. 23 URLhttps://www.sciencedirect.com/science/article/pii/ ...

    2023

  13. [21]

    S. S. Dvivedi, V. Vijay, S. L. R. Pujari, S. Lodh, D. Kumar, A compara- tiveanalysisoflargelanguagemodelsforcodedocumentationgeneration (2024).doi:10.1145/3664646.3664765. URLhttps://doi.org/10.1145/3664646.3664765

    2024

  14. [22]

    Feldman, J

    P. Feldman, J. R. Foulds, S. Pan, Trapping llm hallucinations using tagged context prompts (2023).arXiv:2306.06085. URLhttps://arxiv.org/abs/2306.06085

    2023 arXiv

  15. [23]

    Perumalla, A

    K. Perumalla, A. Soni, R. Dey, S. Rich, Zeroin: Characterizing the data distributions of commits in software repositories (2022).arXiv: 2204.07863. URLhttps://arxiv.org/abs/2204.07863

    2022 arXiv

  16. [24]

    X. Hou, Y. Zhao, Y. Liu, Z. Yang, K. Wang, L. Li, X. Luo, D. Lo, J. Grundy, H. Wang, Large language models for software engineering: A systematic literature review, ACM Trans. Softw. Eng. Methodol. 33 (8) (Dec. 2024).doi:10.1145/3695988. URLhttps://doi.org/10.1145/3695988

    2024 doi

  17. [25]

    J. He, C. Treude, D. Lo, Llm-based multi-agent systems for software engineering: Literature review, vision, and the road ahead, ACM Trans. Softw. Eng. Methodol. 34 (5) (May 2025).doi:10.1145/3712003. URLhttps://doi.org/10.1145/3712003

    2025 doi

  18. [26]

    T. Xiao, Y. Fan, F. Calefato, C. Treude, R. G. Kula, H. Hata, S. Baltes, Self-admitted genai usage in open-source software (2026)

    2026

  19. [27]

    Giray, O

    G. Giray, O. Demirörs, M. Kalinowski, D. Mendez, An empirical study of generative ai adoption in software engineering (2026).arXiv:2512. 23327. URLhttps://arxiv.org/abs/2512.23327

    2026

  20. [28]

    T. Xiao, C. Treude, H. Hata, K. Matsumoto, Devgpt: Studying developer-chatgpt conversations, in: Proceedings of the 21st Interna- tional Conference on Mining Software Repositories, MSR ’24, Associa- tion for Computing Machinery, New York, NY, USA, 2024, p. 227–230. 24 doi:10.1...

    2024

  21. [29]

    W. Wang, H. Ning, S. Qian, G. Zhang, Y. Wang, Characterizing de- velopers’ behaviors in llm -supported software development, in: 2024 IEEE 48th Annual Computers, Software, and Applications Confer- ence (COMPSAC), 2024, pp. 1168–1177.doi:10.1109/COMPSAC61105. 2024.00156

    2024

  22. [30]

    Barke, M

    S. Barke, M. B. James, N. Polikarpova, Grounded copilot: How pro- grammers interact with code-generating models, Proc. ACM Program. Lang. 7 (OOPSLA1) (Apr. 2023).doi:10.1145/3586030. URLhttps://doi.org/10.1145/3586030

    2023 doi

  23. [31]

    Daigle, GitHub Staff, Survey: The ai wave continues to grow on software development teams, GitHub Blog, [Accessed: Oct

    K. Daigle, GitHub Staff, Survey: The ai wave continues to grow on software development teams, GitHub Blog, [Accessed: Oct. 16, 2025] (2024). URLhttps://github.blog/news-insights/research/ survey-ai-wave-grows/

    2025

  24. [32]

    Murali, C

    V. Murali, C. Maddila, I. Ahmad, M. Bolin, D. Cheng, N. Ghorbani, R. Fernandez, N. Nagappan, P. C. Rigby, Ai-assisted code authoring at scale: Fine-tuning, deploying, and mixed methods evaluation, Proc. ACM Softw. Eng. 1 (FSE) (Jul. 2024).doi:10.1145/3643774. URLhttps://doi.or...

    2024 doi

  25. [33]

    J. D. Weisz, S. V. Kumar, M. Muller, K.-E. Browne, A. Goldberg, K. E. Heintze, S. Bajpai, Examining the use and impact of an ai code assistant on developer productivity and experience in the enterprise, in: Proceed- ingsoftheExtendedAbstractsoftheCHIConferenceonHumanFactors in...

    2025

  26. [34]

    Z. Yang, C. Wang, J. Shi, T. Hoang, P. Kochhar, Q. Lu, Z. Xing, D. Lo, What do users ask in open-source ai repositories? an empirical study of github issues, in: 2023 IEEE/ACM 20th International Conference on Mining Software Repositories (MSR), 2023, pp. 79–91.doi:10.1109/ MSR...

    2023

  27. [36]

    M. L. Siddiq, L. Roney, J. Zhang, J. C. D. S. Santos, Quality assessment of chatgpt generated code and their use by developers, in: Proceedings of the 21st International Conference on Mining Software Repositories, MSR ’24, Association for Computing Machinery, New York, NY, USA...

    2024

  28. [37]

    Y. Cai, P. Liang, Y. Wang, Z. Li, M. Shahin, Demystifying issues, causes and solutions in llm open-source projects, J. Syst. Softw. 227 (C) (Sep. 2025).doi:10.1016/j.jss.2025.112452. URLhttps://doi.org/10.1016/j.jss.2025.112452 26

    2025

Pith tools

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