Pith. sign in

REVIEW 5 major objections 5 minor 86 references

A Study of Cursorrules Files in GitHub Open Source Projects

T0 review · 5 major / 5 minor · reviewed 2026-08-12 · deepseek-v4-flash

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

Pith's one-line read Cursor rule files cluster in small hobby repos, study finds

desk verdict A useful first empirical baseline for .cursorrules files, but the temporal and 'toy project' claims should be softened given survivorship bias and an unquantified search cap. read the letter →

arxiv 2608.10622 v1 pith:JPNMERVJ submitted 2026-08-11 cs.SE

Shuang Sun , Jafar Akhoundali , Arina Kudriavtseva , Sengim Karayalcin , Olga Gadyatskaya This is my paper · ORCID
classification cs.SE
keywords CursorcursorrulespromptengineeringconfigurationfilesminingsoftwarerepositoriesGitHubthematicanalysissecuritysmells
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 where Cursor's project-level prompt configuration files actually live and what they say. The authors collected 12,110 .cursorrules files from 11,427 GitHub repositories and found that the format spread rapidly from mid-2024, then settled into small, low-activity, single-maintainer repositories that look more like toy projects than production codebases. A thematic analysis of 65 sampled files shows that developer instructions focus on code quality, engineering practices, project structure, and maintainability, while security content is rare and potential security smells appear in about 1.5% of coded instances. The study also argues that the themes in the legacy .cursorrules format carry over to the newer .mdc files, so the findings are not just about an outdated format.

What carries the argument

The central object is the .cursorrules file: a free-form, metadata-free text file that Cursor injects into the model context so that its instructions persist across all sessions in a project. The argument is carried by a mixed-methods pipeline: a keyword-partitioned GitHub Code Search query that assembled 12,110 unique files, GitHub API metadata on repository activity and commit history, and an inductively built 65-code codebook applied to a random sample of 65 prompt files. The quantitative metadata grounds the claims about where the files appear and how they evolve, while the codebook's ten themes, anchored by codes such as Languages, Stacks & Usage Guidance and Security Awareness, Mechanisms & Practices, grounds the claims about content priorities.

What would settle it

Compute a complete census of public .cursorrules files from a full GitHub archive rather than keyword-partitioned search queries; if most files turn out to live in large, multi-contributor, actively committed repositories, the paper's toy-project claim collapses. The security claim could be tested separately by measuring whether code generated with security-themed prompt files has a lower vulnerability density than code generated without them.

Watch

Extended reading notes

Core claim

The central discovery is that the free-form .cursorrules file functioned as a first-wave prompt-file format whose real-world footprint is concentrated outside professional development. Quantitatively, 68.5% of hosting repositories have a single contributor, 62.5% have at most fifty commits, and 75.0% are under 11 MB; 67.3% of the files were never changed after creation, and when they are changed, over half of the modifications touch fewer than ten lines. Qualitatively, the largest theme is Code Quality and Engineering Practices (30.4% of coded instances), followed by Project Structure and Configuration (18.3%) and Maintainability and Evolution (14.4%), while Security accounts for only about 4.4% when access-control content is included. The authors read this as evidence that prompt files in the wild are mostly informal, style-oriented guidance, and that security is not yet a systematic part of how developers configure AI coding assistants.

Load-bearing premise

The load-bearing premise is that keyword-partitioned GitHub Code Search gives a representative sample of all public .cursorrules files; if files in large, active, or security-conscious repositories are systematically missed, the toy-project and low-security conclusions would be biased.

Editorial extensions

If this is right

  • Prompt-file adoption studies that sample only mature, popular open-source projects will systematically miss the bulk of the phenomenon, because most .cursorrules files sit in small single-maintainer repositories.
  • Project-level prompt files in the wild are unlikely to act as security guardrails for AI-generated code, since security-related guidance accounts for only about 4.4% of coded content.
  • The topical continuity between .cursorrules and .mdc files means the qualitative findings likely transfer to current Cursor rule formats and to related agent rule files such as AGENTS.md.
  • The format's rapid rise and decline after Cursor deprecated it in February 2025 shows that prompt-file ecosystems track tooling decisions closely.
  • Repository setup is a key adoption moment: 40.7% of .cursorrules files appear within 24 hours of repository creation, often within minutes.

Reading between the lines

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

  • As an inference beyond the paper's claims, if most .cursorrules files are boilerplate or template-like guidance, the content priorities may reflect what prompt templates recommend rather than what individual developers need; clustering near-duplicate files would test this directly.
  • Because the GitHub Code Search pipeline is keyword-partitioned and API-capped, it may undercount files in large repositories; a complete archive census could overturn the toy-project characterization if those files prove numerous.
  • The low security content suggests a concrete experiment: generating the same feature with and without a security-focused prompt file and comparing vulnerability density would show whether prompt files can meaningfully add security assurance.
  • The same mixed-methods design applied to AGENTS.md, CLAUDE.md, or copilot-instructions.md would reveal whether the toy-project concentration and security neglect persist as prompt-file formats mature.
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

5 major / 5 minor

Summary. This paper presents a mixed-methods empirical study of .cursorrules files in public GitHub repositories. The authors collect 12,110 such files from 11,427 repositories using keyword-partitioned GitHub Code Search across two snapshots (April and October 2025), analyze file and repository metadata to address RQ1-RQ2, and perform thematic analysis on 65 files (51 .cursorrules and 14 .mdc) to address RQ3-RQ4. The main claims are that .cursorrules adoption rose rapidly from mid-2024, is concentrated in small, low-activity, single-maintainer repositories, that file content is dominated by code quality and engineering practices, and that security receives little attention. The paper also reports thematic continuity with the newer .mdc format.

Significance. If the findings hold, this is one of the first large-scale empirical characterizations of Cursor's legacy prompt configuration files, and the codebook plus the anonymous replication package are reusable assets for future research on prompt-file engineering. The quantitative dataset is substantial, and the qualitative analysis follows a systematic thematic-analysis procedure with inter-coder reliability reporting. The main caveats are that the sampling strategy and the survivorship of files are not fully accounted for, which may bias the prevalence and temporal claims, and that the 'toy projects' interpretation goes beyond what the repository metrics can establish.

major comments (5)
  1. [§3.1, Data Collection] The keyword-partitioned GitHub Code Search strategy is not described with enough detail to assess representativeness. The paper never lists the keywords used, nor does it report how many queries hit the 1,000-result cap or whether saturation was reached. Because GitHub Code Search returns at most 1,000 results per query, any .cursorrules file whose content matches none of the chosen keywords is invisible to the search, so the 12,110-file corpus is not necessarily a random or complete sample of public .cursorrules files. The abstract's quantitative generalizations (e.g., 51.7% web languages, 68.5% single-maintainer repositories) are conditional on this sampling frame. The authors should publish the full query list and provide a coverage analysis, for example by comparing keyword-based retrieval against a sample from an independent source or by measuring the number of queries that hit the result cap.
  2. [§3.1 and §5, Threats to Validity] The dataset is built from two snapshots (April and October 2025) of files present on the default branch at query time. Any .cursorrules file created and deleted before April 2025 is unobservable, and files deleted between snapshots are only represented if they survived to April. The February 2025 deprecation announced in §2 provides a concrete mechanism for such deletion: active projects migrating to .cursor/rules or AGENTS.md would remove .cursorrules, while abandoned projects would leave them in place. Consequently, the emergence timeline in Figure 3 and RQ1.1 and the characterization of host repositories as small, low-activity, single-maintainer (Sections 4.1.1 and 5) may reflect survivor bias rather than the true population. This threat is not mentioned in §5, which only notes API incompleteness and snapshot uncertainty. The authors should quantify the extent of deletion where possible (e.g., by tracking repositories that had a .cursorrules file at the April snapshot but not in October) or substantially soften the causal and prevalence claims.
  3. [§4.1.1 (RQ1.3) and §5] The inference from repository size, commit counts, and contributor counts to "toy projects rather than professional development" is not supported. Small repositories with few commits and a single maintainer are common for legitimate personal projects, libraries, and early-stage startups; low activity does not imply non-professional or educational use. This is a value-laden interpretation of a structural proxy. The data support only the descriptive statement "mostly small, low-activity, single-maintainer repositories." The abstract and §5 should be reworded to avoid the "toy projects" characterization, or the authors should provide additional evidence (e.g., repository descriptions, README content, or package publication status) to justify it.
  4. [§3.1, Metadata Collection] There is an internal inconsistency about how repository counts were obtained. The text first states that counts such as commits, releases, pull requests, and contributors were capped at 100 and recorded as 101 when exceeding the threshold, but then states that the same attributes were retrieved via the GitHub GraphQL API, which exposes totalCount fields and reduces the number of API calls. If GraphQL totalCount was used, the counts are exact and the 101-cap does not apply. This matters because RQ1.3's activity tiers (e.g., 62.5% with 50 or fewer commits, 68.5% single-maintainer) and the commit-interval analysis in RQ2.2 depend on these counts. Please clarify which mechanism was actually used, and if the 100-cap was applied to some attributes, state which ones and re-analyze the affected distributions with exact counts.
  5. [§3.3, Qualitative Analysis] The 14 .mdc files used for the cross-type comparison are not clearly sampled. The text says "we randomly selected 65 prompt files – 51 .cursorrules and 14 newer .mdc files," but it does not state whether the .mdc files were drawn from the same random procedure or from a separate convenience sample, nor does it describe the sampling frame for .mdc files. Since the qualitative claim of "continuity of themes and topics" between .cursorrules and .mdc (abstract, RQ3) rests on comparing 51 and 14 files, the authors should specify the .mdc selection process and acknowledge that 14 files cannot establish generalizable continuity. The existing caveat that the qualitative sample is not representative is helpful, but it should be connected explicitly to the .mdc comparison.
minor comments (5)
  1. [Abstract and §3.3.1] The paper reports a "65-code codebook," but §3.3.1 states that after cross-type coding of .mdc files two new codes were added (Rule File Description, Scopes & Nested Structures; Prompt/Rule Example/Template). If these are included in the final codebook, the count should be 67; if not, the abstract's "65-code" claim should be clarified.
  2. [§3.1 and §4.1.1] The dataset is described as covering "15 April 2024 to 30 September 2025," yet §4.1.1 reports an outlier file created on May 29, 2023. Please state explicitly whether the outlier is excluded from all analyses and whether Figure 3's time axis is truncated accordingly.
  3. [Figure 8] The legend label "t category" appears truncated; it should read "Δt category" to match the text.
  4. [§4.2.1 and Table 5] The prose reports the Security theme as 4.2% in Table 5, then states that Security Awareness, Mechanisms & Practices combined with Access Control reaches roughly 4.4%. Please reconcile these percentages and state explicitly whether Access Control is included in the Security theme in Table 5.
  5. [§5 and Conclusion] The term "toy projects" should be removed or replaced with descriptive language throughout the paper, including the abstract and conclusion, for the reasons given in Major Comment 3.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the study is observational and its central claims are descriptive summaries of collected data, not derivations equivalent to the inputs.

full rationale

This is an empirical mining-software-repositories study, not a derivation chain, so the circularity patterns do not apply. The central claims—file emergence timing, repository profiles, maintenance patterns, and content themes—are direct descriptive statistics or human qualitative coding of the collected files. The thematic codebook was induced from the 51 sampled .cursorrules files and then applied to 14 .mdc files; this is standard inductive thematic analysis and transferability checking, not a prediction that reduces to its own inputs. The 'continuity of themes' claim is a qualitative comparison, not a mathematically forced equivalence. The only self-citation (Akhoundali et al., 2025) appears in the threats-to-validity section to support the statement that the GitHub API does not return complete results; that citation is not load-bearing for any quantitative or qualitative result, and the paper independently documents its own 1,000-result query cap and snapshot merging limitations. Survivorship bias and sample-coverage concerns are genuine threats to validity, but they are not circularity: the dataset is the object of study, not a fitted parameter renamed as a prediction. No equation or definition in the paper makes a result true by construction. Therefore the appropriate finding is no significant circularity.

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

This is an observational study, so there are no fitted equations. The listed parameters are analysis design choices that affect the reported numbers. The assumptions concern data collection and qualitative saturation, which are the main load-bearing premises.

free parameters (3)
  • Qualitative sample size = 65 files (51 .cursorrules, 14 .mdc)
    The random sample size drives the thematic analysis and codebook saturation claims (§3.3). A larger sample might reveal additional codes or change theme proportions.
  • GitHub API count cap = 100
    Repository attribute counts are capped at 100 by the GitHub API, so highly active repositories are recorded as 101. This lower-bounds activity metrics and affects the characterization of hosting repositories (§3.1).
  • 30-day observation window = 30 days
    Used for commit interval analysis and repository lifecycle comparisons to control censoring (§3.2.2). The choice influences median interval and activity-after-update statistics.
assumptions (3)
  • domain assumption GitHub Code Search with keyword partitioning can enumerate a representative sample of public .cursorrules files.
    Assumed in §3.1; GitHub restricts queries to 1,000 results, so the authors partition by keywords. If some files are systematically missed, the quantitative results are biased.
  • domain assumption GitHub API metadata accurately reflects repository and file history.
    All repository-level attributes come from the GitHub API (§3.1). The authors note incomplete attributes and caps, so some measurements are lower bounds.
  • domain assumption Thematic saturation reached with 65 files supports the codebook's completeness.
    The authors report no new codes emerged after the initial sample (§3.3), but they acknowledge the sample is not representative and further files could reveal new themes.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Study of Cursorrules Files in GitHub Open Source Projects." pith.science (2026). https://pith.science/paper/JPNMERVJ

@misc{pith2026260810622,
  author       = {Pith},
  title        = {Pith review of: A Study of Cursorrules Files in GitHub Open Source Projects},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/JPNMERVJ}},
  note         = {Machine review of arXiv:2608.10622}
}
read the original abstract

Prompts are the primary mechanism for communicating with AI agents, and they directly influence the quality and reliability of AI-generated code. As AI-assisted programming becomes widely adopted, modern tools increasingly combine dynamic conversational prompts with static configuration-like prompt files. Despite the growing focus on prompt engineering, prior research has primarily focused on conversational prompts, while prompt files remain understudied. To address this gap, we conduct an empirical study of configuration prompt files in Cursor, a widely used AI-assisted code editor. We collect and analyze over 12,110 .cursorrules files from 11,427 GitHub repositories to characterize their distribution, evolution, and maintenance. Complementing this, we perform qualitative analysis on a random sample of 65 prompt files and develop a 65-code codebook capturing how developers express programming intent, project context, engineering practices, and security considerations. Our results show that .cursorrules files emerged rapidly from mid-2024. Their adoption is concentrated in small-scale, low-activity, single-maintainer repositories, suggesting toy projects rather than professional development. The content of prompt files is dominated by guidance on code quality and engineering practices, project structure and configuration, and maintainability, while security-related content appears less frequently. Our analysis shows that there is a continuity of themes and topics between the now-legacy .cursorrules files and the current standard .mdc files.

Figures

Figures reproduced from arXiv: 2608.10622 by the authors.

Figure 1
Figure 1. Example of a .cursorrules file. files have been designed by developers in the wild, since the emergence of the AI coding assistants using such files. To better understand how such prompt configura￾tion files have been used in practice, we examine the prompt-file ecosystem of Cursor, a widely used code editor built for AI-assisted programming (Cursor, 2025). In our work, we conduct both qualitative and quantitative a… view at source ↗
Figure 2
Figure 2. Our study methodology. nitude of changes. We compute the proportion of each status (added, modified, renamed, and removed). We quantify modification extent by examining line changes in modified commits and computing a rela￾tive change ratio, defined as lines changed divided by total lines before the commit. For RQ2.4, we examine whether .cursorrules additions and modifications occur alone or with other files by coun… view at source ↗
Figure 3
Figure 3. Monthly counts of commits and .cursorrules file creations in open-source GitHub repositories. 4.1 Quantitative Analysis Results 4.1.1 RQ1: What are .cursorrules files and in which open source projects they appear RQ1.1: .cursorrules files creation [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (4 more)
Figure 5
Figure 5. Figure 5: Programming language distribution across repos [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]
Figure 6
Figure 6. Figure 6: Distribution of the number of lines changed per [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]
Figure 7
Figure 7. Figure 7: Monthly distribution of .cursorrules commits by relative change ratio. Each color interval represents a ratio range. tus distribution shows that most updates were new file additions or modifications to existing ones, with few deletions or renames.Specifically, 50.2% of…
Figure 8
Figure 8. Figure 8: Monthly trend of creation-timing categories ( [PITH_FULL_IMAGE:figures/full_fig_p007_8.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

86 extracted references · 74 canonical work pages

  1. [1]

    2025 , note =

    World Economic Forum , title =. 2025 , note =

    2025

  2. [2]

    2025 , howpublished =

    2025

  3. [3]

    Eradicating the unseen:

    Akhoundali, Jafar and Hamidi, Hamidreza and Rietveld, Kristian and Gadyatskaya, Olga , booktitle=. Eradicating the unseen:

  4. [4]

    2025 , howpublished =

    Rohit Dalvi , title =. 2025 , howpublished =

    2025

  5. [5]

    From prompts to templates:

    Mao, Yuetian and He, Junjie and Chen, Chunyang , booktitle=. From prompts to templates:

  6. [6]

    Code with me or for me?

    Chen, Valerie and Talwalkar, Ameet and Brennan, Robert and Neubig, Graham , journal=. Code with me or for me?

  7. [7]

    Security Degradation in Iterative

    Shukla, Shivani and Joshi, Himanshu and Syed, Romilla , journal=. Security Degradation in Iterative

    work page

  8. [8]

    IEEE Transactions on Software Engineering , year=

    The impact of prompt programming on function-level code generation , author=. IEEE Transactions on Software Engineering , year=

Show all 86 references
  1. [9]

    Acecoder:

    Li, Jia and Zhao, Yunfei and Li, Yongmin and Li, Ge and Jin, Zhi , journal=. Acecoder:. 2024 , publisher=

    2024

  2. [10]

    Xiao, Tao and Treude, Christoph and Hata, Hideaki and Matsumoto, Kenichi , booktitle=. Dev

  3. [11]

    Developer-

    Zhong, Suzhen and Zou, Ying and Adams, Bram , journal=. Developer-

  4. [12]

    Prompting in Practice:

    Otten, Daniel and Stalnaker, Trevor and Wintersgill, Nathan and Chaparro, Oscar and Poshyvanyk, Denys , journal=. Prompting in Practice:

  5. [13]

    arXiv preprint arXiv:2508.13948 , year=

    Prompt orchestration markup language , author=. arXiv preprint arXiv:2508.13948 , year=

    arXiv

  6. [14]

    Patterns , year=

    Unleashing the potential of prompt engineering for large language models , author=. Patterns , year=

  7. [15]

    arXiv preprint arXiv:2403.08950 , year=

    Exploring prompt engineering practices in the enterprise , author=. arXiv preprint arXiv:2403.08950 , year=

    arXiv

  8. [16]

    Software testing with large language models:

    Wang, Junjie and Huang, Yuchao and Chen, Chunyang and Liu, Zhe and Wang, Song and Wang, Qing , journal=. Software testing with large language models:. 2024 , publisher=

    2024

  9. [17]

    Developer Prompts in Practice:

    Rzig, Dhia Elhaq and Paul, Dhruba Jyothi and Pister, Kaiser and Henkel, Jordan and Hassan, Foyzul , booktitle =. Developer Prompts in Practice:

  10. [18]

    Prompts as Software Engineering Artifacts:

    Villamizar, Hugo and Fischbach, Jannik and Korn, Alexander and Vogelsang, Andreas and Mendez, Daniel , booktitle=. Prompts as Software Engineering Artifacts:. 2025 , organization=

    2025

  11. [19]

    Pister, Kaiser and Paul, Dhruba Jyoti and Joshi, Ishan and Brophy, Patrick , booktitle=

  12. [20]

    A systematic survey of prompt engineering in large language models:

    Sahoo, Pranab and Singh, Ayush Kumar and Saha, Sriparna and Jain, Vinija and Mondal, Samrat and Chadha, Aman , journal=. A systematic survey of prompt engineering in large language models:

  13. [21]

    Sander Schulhoff and Michael Ilie and Nishant Balepur and Konstantine Kahadze and Amanda Liu and Chenglei Si and Yinheng Li and Aayush Gupta and HyoJung Han and Sevien Schulhoff and Pranav Sandeep Dulepet and Saurav Vidyadhara and Dayeon Ki and Sweta Agrawal and Chau Pham and ...

    arXiv

  14. [22]

    What makes good in-context demonstrations for code intelligence tasks with

    Gao, Shuzheng and Wen, Xin-Cheng and Gao, Cuiyun and Wang, Wenxuan and Zhang, Hongyu and Lyu, Michael R , booktitle=. What makes good in-context demonstrations for code intelligence tasks with. 2023 , organization=

    2023

  15. [23]

    The rise of

    Li, Hao and Zhang, Haoxiang and Hassan, Ahmed E , journal=. The rise of

  16. [24]

    Chatlatanagulchai, Worawalan and Li, Hao and Kashiwa, Yutaro and Reid, Brittany and Thonglek, Kundjanasith and Leelaprute, Pattara and Rungsawang, Arnon and Manaskasemsak, Bundit and Adams, Bram and Hassan, Ahmed E and others , journal=. Agent

  17. [25]

    An Empirical Study of Developer-Provided Context for

    Jiang, Shaokang and Nam, Daye , journal=. An Empirical Study of Developer-Provided Context for

  18. [26]

    The fault in our stars:

    Siddiq, Mohammed Latif and Dristi, Simantika and Saha, Joy and Santos, Joanna CS , booktitle=. The fault in our stars:. 2024 , organization=

    2024

  19. [27]

    Quality assessment of

    Siddiq, Mohammed Latif and Roney, Lindsay and Zhang, Jiahao and Santos, Joanna Cecilia Da Silva , booktitle=. Quality assessment of

  20. [28]

    A survey on code generation with

    Dong, Yihong and Jiang, Xue and Qian, Jiaru and Wang, Tian and Zhang, Kechi and Jin, Zhi and Li, Ge , journal=. A survey on code generation with

  21. [29]

    Euromicro Conf

    Prompt engineering guidelines for using large language models in requirements engineering , author=. Euromicro Conf. on Soft. Eng. and Adv. Applications , pages=. 2025 , organization=

    2025

  22. [30]

    Lyu, Yunbo and Yang, Zhou and Shi, Jieke and Chang, Jianming and Liu, Yue and Lo, David , journal=. ``

  23. [31]

    My Code Is Less Secure with

    Kudriavtseva, Arina and Hotak, Nisar Ahmad and Gadyatskaya, Olga , booktitle=. My Code Is Less Secure with

  24. [32]

    ACM Transactions on Software Engineering and Methodology , year=

    Do advanced language models eliminate the need for prompt engineering in software engineering? , author=. ACM Transactions on Software Engineering and Methodology , year=

  25. [34]

    Promptware engineering:

    Chen, Zhenpeng and Wang, Chong and Sun, Weisong and Yang, Guang and Liu, Xuanzhe and Zhang, Jie M and Liu, Yang , journal=. Promptware engineering:

  26. [35]

    Software Composition Analysis and Supply Chain Security in

    Nocera, Sabato and Vegas, Sira and Scanniello, Giuseppe and Juristo, Natalia , booktitle=. Software Composition Analysis and Supply Chain Security in. 2025 , organization=

    2025

  27. [36]

    Sergeyuk, Agnia and Zakharov, Ilya and Koshchenko, Ekaterina and Izadi, Maliheh , journal=. Human-. 2026 , publisher=

    2026

  28. [37]

    ACM Transactions on Software Engineering and Methodology , volume=

    Ecosystem of large language models for code , author=. ACM Transactions on Software Engineering and Methodology , volume=. 2025 , publisher=

    2025

  29. [38]

    An empirical study on usage and perceptions of

    Rasnayaka, Sanka and Wang, Guanlin and Shariffdeen, Ridwan and Iyer, Ganesh Neelakanta , booktitle=. An empirical study on usage and perceptions of

  30. [39]

    Pan, Zhenyu and Song, Xuefeng and Wang, Yunkun and Cao, Rongyu and Li, Binhua and Li, Yongbin and Liu, Han , booktitle=. Do Code. 2025 , organization=

    2025

  31. [40]

    Mapping Code Smells and Refactorings Accurately:

    Shetty, Gautam and Sharma, Tushar , booktitle =. Mapping Code Smells and Refactorings Accurately:

  32. [41]

    Evaluating software development agents:

    Chen, Zhi and Jiang, Lingxiao , booktitle=. Evaluating software development agents:. 2025 , organization=

    2025

  33. [42]

    Attributing Open-Source Contributions is Critical but Difficult:

    Holtgrave, Jan-Ulrich and Friedrich, Kay and Fischer, Fabian and Huaman, Nicolas and Busch, Niklas and Klemmer, Jan H and Fourn. Attributing Open-Source Contributions is Critical but Difficult:. 2025 , booktitle=

    2025

  34. [43]

    A systematic mapping study on mining software repositories , author=. Proc. of SAC , pages=

  35. [44]

    Empirical Software Engineering , volume=

    Ethics in the mining of software repositories , author=. Empirical Software Engineering , volume=. 2022 , publisher=

    2022

  36. [45]

    Beyond Stars and Commits:

    Sun, Yuqiang and Ding, Sun and Tan, Liwei and Xue, Yue and Li, Bo and Huang, Charles and Xiong, Siyang , booktitle=. Beyond Stars and Commits:

  37. [46]

    Using thematic analysis in psychology , author =. Qual. Res. Psychol. , pages =. 2006 , number =

    2006

  38. [47]

    4.5 Million (Suspected) Fake Stars in

    He, Hao and Yang, Haoqin and Burckhardt, Philipp and Kapravelos, Alexandros and Vasilescu, Bogdan and K. 4.5 Million (Suspected) Fake Stars in. arXiv preprint arXiv:2412.13459 , year=

    arXiv

  39. [48]

    Redcode:

    Guo, Chengquan and Liu, Xun and Xie, Chulin and Zhou, Andy and Zeng, Yi and Lin, Zinan and Song, Dawn and Li, Bo , journal=. Redcode:

  40. [49]

    We need structured output

    Liu, Michael Xieyang and Liu, Frederick and Fiannaca, Alexander J and Koo, Terry and Dixon, Lucas and Terry, Michael and Cai, Carrie J , booktitle=. "We need structured output":

  41. [50]

    Analyzing developer use of

    Grewal, Balreet and Lu, Wentao and Nadi, Sarah and Bezemer, Cor-Paul , booktitle=. Analyzing developer use of

  42. [51]

    Proceedings of the Brazilian Symposium on Software Quality , pages=

    Characterizing commits in open-source software , author=. Proceedings of the Brazilian Symposium on Software Quality , pages=

  43. [52]

    Jamil, Mohammad Talal and Abid, Shamsa and Shamail, Shafay , booktitle=. Can. 2025 , organization=

    2025

  44. [53]

    Language Models in Software Development Tasks:

    Alizadeh, Negar and Belchev, Boris and Saurabh, Nishant and Kelbert, Patricia and Castor, Fernando , booktitle=. Language Models in Software Development Tasks:. 2025 , organization=

    2025

  45. [54]

    Prompt Engineering or Fine-Tuning:

    Shin, Jiho and Tang, Clark and Mohati, Tahmineh and Nayebi, Maleknaz and Wang, Song and Hemmati, Hadi , booktitle=. Prompt Engineering or Fine-Tuning:. 2025 , organization=

    2025

  46. [55]

    2025 , note =

    Ivan Mehta , title =. 2025 , note =

    2025

  47. [56]

    Prompting in the wild:

    Tafreshipour, Mahan and Imani, Aaron and Huang, Eric and de Almeida, Eduardo Santana and Zimmermann, Thomas and Ahmed, Iftekhar , booktitle=. Prompting in the wild:. 2025 , organization=

    2025

  48. [57]

    Prompts are programs too!

    Liang, Jenny T and Lin, Melissa and Rao, Nikitha and Myers, Brad A , journal=. Prompts are programs too!. 2025 , publisher=

    2025

  49. [58]

    Vibe Coding as a Reconfiguration of Intent Mediation in Software Development:

    Meske, Christian and Hermanns, Tobias and von der Weiden, Esther and Loser, Kai-Uwe and Berger, Thorsten , journal=. Vibe Coding as a Reconfiguration of Intent Mediation in Software Development:

  50. [59]

    Vibe coding:

    Sarkar, Advait and Drosos, Ian , journal=. Vibe coding:

  51. [60]

    2025 , note =

    Andrej Karpathy , title =. 2025 , note =

    2025

  52. [61]

    Liu, Yue and Zhao, Yanjie and Lyu, Yunbo and Zhang, Ting and Wang, Haoyu and Lo, David , journal=. "Your

  53. [62]

    Context Engineering for

    Mohsenimofidi, Seyedmoein and Galster, Matthias and Treude, Christoph and Baltes, Sebastian , journal=. Context Engineering for

  54. [63]

    2025 , note =

    agents.md , title =. 2025 , note =

    2025

  55. [64]

    The Essential Guide to Prompt Engineering: Key Principles, Techniques, Challenges, and Security Risks , pages=

    Key Principles of Good Prompt Design , author=. The Essential Guide to Prompt Engineering: Key Principles, Techniques, Challenges, and Security Risks , pages=. 2025 , publisher=

    2025

  56. [65]

    Investigating and designing for trust in

    Wang, Ruotong and Cheng, Ruijia and Ford, Denae and Zimmermann, Thomas , booktitle=. Investigating and designing for trust in

  57. [66]

    Developers' perceptions on the impact of

    Vaillant, Thiago S and de Almeida, Felipe Deveza and Neto, Paulo Anselmo and Gao, Cuiyun and Bosch, Jan and de Almeida, Eduardo Santana , journal=. Developers' perceptions on the impact of

  58. [67]

    Trust, transparency, and adoption in generative

    Basha, Manaal and Rodr. Trust, transparency, and adoption in generative. Information and Software Technology , volume=. 2025 , publisher=

    2025

  59. [68]

    Software product quality metrics:

    Colakoglu, Fatima Nur and Yazici, Ali and Mishra, Alok , journal=. Software product quality metrics:. 2021 , publisher=

    2021

  60. [69]

    Systematic literature review on software quality for

    Gezici, Bahar and Tarhan, Ay. Systematic literature review on software quality for. Empirical Software Engineering , volume=. 2022 , publisher=

    2022

  61. [70]

    Automated Code Review Assignments:

    Lulla, Jai Lal and Kula, Raula Gaikovina and Treude, Christoph , journal=. Automated Code Review Assignments:

  62. [71]

    An Empirical Study of Policy as Code:

    Opdebeeck, Ruben and Alfadel, Mahmoud and Rahman, Akond and Kashiwa, Yutaro and Ferreira, Jo. An Empirical Study of Policy as Code:. Proc. of MSR , year=

  63. [72]

    Understanding Prompt Management in

    Li, Hao and Masri, Hicham and Cogo, Filipe R and Bangash, Abdul Ali and Adams, Bram and Hassan, Ahmed E , journal=. Understanding Prompt Management in. 2025 , publisher=

    2025

  64. [73]

    Prompt-with-Me: in-

    Li, Ziyou and Sergeyuk, Agnia and Izadi, Maliheh , journal=. Prompt-with-Me: in-

  65. [74]

    Prompting

    Nam, Daye and Omran, Ahmed and Murillo, Ambar and Thakur, Saksham and Araujo, Abner and Blistein, Marcel and Fr. Prompting. arXiv preprint arXiv:2504.20196 , year=

  66. [75]

    Do Prompt Patterns Affect Code Quality?

    Della Porta, Antonio and Lambiase, Stefano and Palomba, Fabio , booktitle=. Do Prompt Patterns Affect Code Quality?

  67. [76]

    2021 , publisher=

    The coding manual for qualitative researchers , author=. 2021 , publisher=

    2021

  68. [77]

    Content analysis in mass communication:

    Lombard, Matthew and Snyder-Duch, Jennifer and Bracken, Cheryl Campanella , journal=. Content analysis in mass communication:. 2002 , publisher=

    2002

  69. [78]

    Data saturation:

    Aldiabat, Khaldoun M and Le Navenec, Carole-Lynne , journal=. Data saturation:. 2018 , publisher=

    2018

  70. [79]

    Empirical Research for Software Security , pages=

    Threats to validity in empirical software security research , author=. Empirical Research for Software Security , pages=. 2017 , publisher=

    2017

  71. [80]

    Content analysis for the social sciences and humanities , author=. Reading. MA: Addison-Wesley (content analysis) , year=

  72. [81]

    Journal of Advanced Nursing , volume=

    The qualitative content analysis process , author=. Journal of Advanced Nursing , volume=. 2008 , publisher=

    2008

  73. [82]

    How are communication channels on

    Ebert, Verena and Graziotin, Daniel and Wagner, Stefan , booktitle=. How are communication channels on

  74. [83]

    How do software developers use

    Chouchen, Moataz and Bessghaier, Narjes and Begoug, Mahi and Ouni, Ali and Alomar, Eman and Mkaouer, Mohamed Wiem , booktitle=. How do software developers use

  75. [84]

    How do machine learning projects use continuous integration practices?

    Bernardo, Jo. How do machine learning projects use continuous integration practices?. Proceedings of MSR , pages=

  76. [85]

    Empirical Software Engineering , volume=

    Developers talking about code quality , author=. Empirical Software Engineering , volume=. 2023 , publisher=

    2023

  77. [86]

    How developers and managers define and trade productivity for quality , author=. Proc. of the Int. Conf. on Cooperative and Human Aspects of Soft.Eng. , pages=

  78. [87]

    Carrots and rainbows:

    Von Krogh, Georg and Haefliger, Stefan and Spaeth, Sebastian and Wallin, Martin W , journal=. Carrots and rainbows:. 2012 , publisher=

    2012

Pith tools

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