1 Introduction↩︎

AI coding assistants such as GitHub Copilot and Cursor have become increasingly common in modern software development [1], [2]. Compared with general-purpose browser-based chat interfaces such as ChatGPT, these tools operate directly within developers’ programming environments and can access local project context. They support multi-turn dialogue, coordinated multi-file edits, terminal interaction, and iterative refinement based on codebase and execution feedback. Developers can therefore express high-level intent in natural language and steer AI-generated changes through dialogue, using the assistant as a conversational collaborator within the development environment. This style of interaction is often described as vibe coding: an intent-driven workflow in which developers express goals through natural-language prompts and rely on AI-generated code to varying degrees of manual oversight [3], [4].

Open-source software (OSS) provides a particularly relevant context for studying vibe coding workflows because many AI-assisted development activities are observable in public repositories’ development histories, such as commits, issues, and pull requests (PRs) [5]–[7]. Understanding how developers make vibe-coding-based OSS contributions is important because OSS is a collaborative ecosystem, where AI-assisted coding may affect not only individual productivity but also contribution practices, maintenance work, and community trust. Recent industry reports suggest that AI-assisted development is already straining GitHub’s infrastructure: code changes were reportedly on pace to increase from about 1 billion in 2025 to 14 billion in 2026, prompting Microsoft to explore additional multi-cloud capacity [8]. These trends raise concerns about AI-assisted development in OSS: while it may improve efficiency, accelerate implementation, and revive inactive projects, it may also increase risks of insufficient review, maintenance burden, reduced testing, and less deliberate engineering decisions [9], [10]. Understanding these tradeoffs requires first characterizing how developers use AI coding assistants in OSS vibe-coding workflows. Although prior studies provide early evidence on AI adoption in OSS, they mainly examine observable outcomes such as commits, pull requests (PRs), and code-quality signals. For example, prior work reports that Cursor and autonomous-agent adoption can yield short-term velocity gains, but may also increase static-analysis warnings, code complexity, and post-merge churn [11]–[13]. Other studies find that agent-generated contributions are more likely to merge when supported by actionable reviewer engagement [14], [15]. Less is known about the human–AI interaction process behind these outcomes, leaving open how vibe-coding interactions shape subsequent OSS development activity.

Motivated by these gaps, we link developers’ conversational interactions with AI coding assistants to subsequent development activity, offering a more complete understanding of how vibe-coding workflows may influence OSS developers and communities. Specifically, we collected 13,360 chat sessions between developers and AI coding assistants (e.g., Copilot, Cursor, and Claude Code) in OSS contributions. We examine how AI coding assistants are used in repositories, how repository dynamics change after adoption, and how developers whose chat histories appear in our dataset perceive and practice vibe coding in OSS. We find that smaller, less mature, and less collaborative repositories tend to exhibit heavier AI use than their counterparts. After AI adoption, projects tended to show increases in active contributors and lower contributor concentration (\(p<.001\)), but communication remained concentrated among a few participants. Furthermore, Code Writing was the dominant chat purpose, and nearly all AI chat sessions were followed by subsequent commits. We find no broad deterioration in observable code-quality signals, but survey responses show that developers were more concerned about others’ AI-generated code than their own and perceived others’ AI-generated code as imposing a greater maintenance burden (\(p=.029\)). Respondents generally viewed AI as lowering barriers to OSS contribution and were often willing to share chat histories, but raised concerns about reputation, reviewer burden, and idea exposure. We claim the following contributions:

• A large-scale empirical characterization of vibe-coding-based AI coding-assistant adoption in OSS.

• A comprehensive understanding of how OSS dynamics change after AI adoption.

• A mixed-methods study linking vibe-coding behavior to subsequent OSS development activity and developer perceptions.

In this paper, we aim to provide practical insights for understanding AI’s impact on OSS communities, designing more effective and responsible AI-assisted development practices, and informing future AI coding tool design.

2 Related Work↩︎

2.1 AI Coding Assistants in Software Engineering↩︎

Large language models (LLMs) have rapidly reshaped software engineering by enabling AI-assisted coding tools for code generation, completion, debugging, documentation, testing, and refactoring [16]. A growing body of software engineering research has focused on improving the techniques behind these tools. For example, prior work has explored feedback loops that iteratively refine generated code using execution results or test outcomes, as well as reinforcement learning methods that optimize code for efficiency, resource use, and developer comprehension [17]–[20]. More recently, LLM-based coding agents have extended these capabilities beyond isolated code generation, enabling more autonomous support for tasks such as task decomposition, debugging, and tool integration across the development lifecycle [21]. As a result, AI coding tools are increasingly framed as AI pair programmers that reduce implementation effort and accelerate routine development tasks [22], [23]. Empirical studies show that AI coding tools can improve productivity and reduce development time. For example, Copilot users completed programming tasks faster [9] and reported productivity gains reflected in behavioral usage data [24].

At the same time, prior work highlights important limitations of AI-assisted coding. Studies of Copilot’s code suggestions show that generated solutions vary in correctness, complexity, robustness, and reproducibility [25], [26]. Security-focused work further shows that Copilot may generate insecure code in security-sensitive scenarios [27]. Human-centered studies add that, although developers often value Copilot’s suggestions, these tools do not always improve task completion and may introduce challenges in understanding, validating, and integrating generated code [28], [29]. Together, prior work shows that AI-assisted coding affects not only productivity but also how developers evaluate and maintain code. However, most studies focus on controlled tasks or short-term outcomes, leaving less known about how AI-assisted coding unfolds from developer–AI conversations to sustained activity in real-world repositories.

2.2 AI Coding Assistant in Open Source Software↩︎

Open-source software (OSS) provides an important setting for studying AI-assisted development because contributions are collaborative, publicly visible, and shaped by concerns about review, trust, reputation, and maintainability. It also offers an observable context for examining how developers use AI coding assistants in vibe-coding workflows. Recent work has begun to examine generative AI in OSS contexts. Song et al. studied the impact of GitHub Copilot on collaborative OSS development and found evidence that Copilot use can increase project-level productivity and developer participation, but may also increase integration time, suggesting additional coordination costs [30]. Other work has examined AI support for pull-request workflows and studied generative AI for PR descriptions, showing how LLMs can assist with summarizing and documenting code changes in review contexts [31].

Recent studies have shifted from controlled evaluations of AI coding tools to large-scale analyses of their use in OSS. Li et al. introduced AIDev, a dataset of agent-authored pull requests from multiple autonomous coding agents, and showed that agents are beginning to act as software contributors by opening PRs, participating in review workflows, and producing code changes at scale [7]. Complementary causal studies examine repository-level effects after tool adoption: He et al. found that Cursor adoption produces short-term increases in development velocity but also persistent increases in static-analysis warnings and code complexity [11], while Agarwal et al. showed that autonomous agents yield front-loaded velocity gains mainly in repositories without prior AI-tool use, alongside sustained increases in warnings and cognitive complexity [12]. Other work analyzes agent-generated artifacts more directly: Robbes et al. found that agent-assisted commits are larger than human-only commits and frequently involve feature development or bug fixing [14], Popescu et al. linked autonomous-agent contributions to greater post-merge churn [13], and Nachuma et al. showed that agent-authored PRs are more likely to be integrated when they receive actionable reviewer engagement, whereas larger or coordination-disrupting changes are less likely to be merged [15]. These studies provide important evidence on agent-authored commits and pull requests, but they leave open how developers’ IDE-based conversations with AI coding assistants connect to subsequent repository activity. They also provide limited insight into how OSS developers who actively use these tools perceive their effects on participation and project development. Our work focuses on these gaps.

3 Methodology↩︎

We collected 13,360 AI chat sessions from 1,356 OSS repositories and complemented them with each repository’s full development history. Using these data, we investigated the following research questions:

• RQ1: How do OSS repositories use AI coding assistants?

• RQ2: How do OSS repositories’ dynamics change after AI adoption?

• RQ3: How do developers perceive AI tool usage through vibe coding in OSS?

3.1 Data Collection↩︎

Figure 1 shows the data-collection pipeline. Our replication package includes all scripts and materials.

3.1.1 AI Chat Sessions↩︎

Following prior work [32], we collected developers’ AI-coding-assistant conversations from real-world conversational programming workflows using SpecStory, which preserves timestamped Markdown chat logs under .specstory/history/ for tools such as Cursor, GitHub Copilot, and Claude Code¹. We located these logs with GitHub Code Search and downloaded the raw Markdown files through the Git Blobs API, and parsed conversations using SpecStory’s role markers. Each AI-chat session can contain multiple user messages. Following prior data-collection practices, we collected 13,360 AI-chat sessions containing 79,172 user messages, spanning September 2024 to March 2026, from 1,356 repositories.

3.1.2 GitHub Repository Data↩︎

To contextualize these chat sessions within broader development activity, we augmented the dataset with the full history of each GitHub repository. We used the GitHub REST API to collect complete repository histories, including creation and update timestamps, size, primary language, stars, forks, owner type, default branch, fork/archive status, contributors, commits, file-level changes, PRs, issues, comments, reviews, and CI/check-run records. Specifically, for commit details, we first queried the commit-listing endpoint, GET /repos/owner/repo/commits, to collect API-visible commits. Because this endpoint is branch-dependent, we also enumerated repository branches and tags using GET /repos/owner/repo/branches and GET /repos/owner/repo/tags, then queried commits from each branch and tag reference and de-duplicated commits by SHA. For each unique SHA, we requested detailed commit metadata using GET /repos/owner/repo/commits/ref, which returns the commit timestamp, SHA, message, author and committer information, parent count, and file-level diff metadata, including changed file paths, file status, additions, deletions, and total changes. We then applied a rule-based path classifier to categorize changed files as source code, tests, documentation, dependencies, configuration/build files, AI-chat artifacts, generated or binary assets, or other. Because file-type classification from paths is heuristic, we manually inspected a random sample of 100 classified files, identifying an initial misclassification rate of 3.0%, and refined the rules accordingly to reduce error.

Of the 1,356 repositories, 1,287 had complete and accessible histories; repositories that were deleted, private, or otherwise inaccessible were excluded. To reduce noise from trivial projects, we followed prior work on identifying valid repositories [33] and screened our sample using signals of substantive development (e.g., development history, community activity, repository naming conventions, and README content). This process excluded 47 repositories (3.7%) judged to be toy, homework, template, or otherwise trivial projects. Contributor identities were resolved using GitHub login, where available, and hashed email addresses otherwise; recognized bot and automated-agent accounts were excluded from all human-contributor analyses. The final dataset comprised 1,240 repositories created between April 2013 and March 2026, with 12,108 AI-chat sessions retained for analysis and a total of 2,369 contributors across the dataset. The most common primary languages were TypeScript (25.8%), Python (22.8%), and JavaScript (12.9%). In total, we collected 657,971 commit records, 1,400,804 changed-file records, 12,747 issues, 9,510 pull requests, 25,418 issue or pull-request comments, 6,902 pull-request reviews, and 120,489 CI/check records.

3.1.3 Chat-Purpose and Project-Type Labels↩︎

We labeled chat purposes using the behavioral-intent taxonomy and LLM-based classification procedure from prior work [32]. This multi-label taxonomy comprises seven categories: Code Writing (writing or editing code), Failure Reporting (reporting errors), Delegation (asking the AI to perform tasks), Inquiry (asking for explanations), Context Specification (providing constraints or background), Workflow Control (turn-taking cues, e.g., “continue" or confirmations), and Validation (checking correctness, quality, tests, or security). The GPT-5 classifier achieved a macro-F1 of 0.83 against a human-annotated reference set. The resulting distribution, summarized in Table 1, is broadly consistent with prior observations [32]. Furthermore, we labeled project type using the taxonomy and LLM-plus-manual procedure from [34]. Because the taxonomy is multi-label, each repository could be assigned to one or more categories: Technology (90.2%), Management-Productivity (33.1%), and Creativity-Entertainment (5.6%). In addition, 9.3% of repositories were classified as OSS4SG. Manual verification on a random sample of 200 projects yielded an accuracy of 90.5%.

3.1.4 Survey Data↩︎

We complemented the repository-activity analysis with a developer survey on perceptions of vibe-coding-based AI use in OSS development. Our institutional IRB approved the study. From 1,240 repositories, we identified 652 developers with publicly available email addresses and, after removing bounced emails, delivered 589 survey invitations via Qualtrics². Upon completion, participants were entered into a lottery for a $30 Amazon gift card, with one gift card awarded per 20 participants. We received 25 responses, yielding a 4.2% response rate among delivered invitations, consistent with response rates reported in prior software-engineering surveys [35], [36].

The consent screen required participants to confirm that they were at least 18 years old, had programming or OSS experience, and voluntarily agreed to participate. The survey measured participants’ perceived benefits and risks of AI coding assistants in vibe coding; perceptions of code quality and maintainability; social and reputational concerns; authorship and responsibility; willingness to disclose AI use or share chat history; appropriate use cases; and open-ended reflections on benefits and risks. The survey included Likert-scale, multiple-choice, and open-ended questions and was designed to be completed within 15 minutes. Most respondents are software developers (36%) or students (20%). They were generally experienced programmers: 92% reported at least intermediate experience, and 72% had programmed for three or more years. They were also familiar with vibe coding, with 76% reporting very or extreme familiarity and 84% using it for OSS contributions.

3.2 Data Analysis↩︎

3.2.1 Preprocessing and temporal alignment↩︎

Because developers may use AI coding assistants during local development before publishing a repository to GitHub, SpecStory chat histories can predate the repository’s GitHub created_at timestamp, which reflects when the repository was created on GitHub, not when local development began. We therefore define a repository’s first observed AI adoption as the timestamp of its earliest AI-chat session in our dataset. We mapped chat sessions to repositories using the session SHA and the GitHub location where the chat-history file was found. For each repository, we selected the earliest mapped chat session and converted all timestamps to UTC. Under this definition, 632 of the 1,240 repositories had their first observed AI chat at or before the GitHub repository creation timestamp, while the remaining 608 had their first observed AI chat after GitHub repository creation.

3.2.2 RQ1: How do OSS repositories use AI coding assistants↩︎

For each chat-history file identified through GitHub Code Search, we used the commit_or_ref in the GitHub blob URL to identify the repository state in which the artifact was observed. When the ref matched a commit in our collected history, we treated that commit as the artifact-containing commit for the session. We further classified these commits as mixed AI-artifact development commits if they also modified development files, and as chat-history-only artifact commits otherwise. In the following analyses, AI-related commits refers to all artifact-containing commits, while analyses of AI-related development activity focus on mixed AI-artifact development commits.
RQ1-1: How are AI coding assistants used in OSS contribution? For each repository, we computed the share of AI-related commits among all post-adoption commits. Calendar months were indexed relative to the adoption month, with the adoption month coded as relative month 0 and excluded from pre/post comparisons to avoid transition-period effects. We then assessed its temporal trend using Spearman correlation across relative months and a binomial regression modeling each post-adoption commit as AI-related or not, with relative month as the predictor. For each AI-related commit, we computed the number of files changed, file-type categories touched, and total churn, measured as additions plus deletions, after excluding AI-artifact files. To assess associations with repository characteristics, we used Spearman correlations for numeric predictors, given the skewness of both predictors and outcomes, and then fit a multivariable binomial regression with AI-related commit count as the outcome and repository and contributor characteristics as predictors. Finally, to assess clustering, we also excluded AI-artifact files and computed concentration at the file and module (top-level directory) levels: the share of AI-related file changes attributed to the single most-changed file or module, the share attributed to the top three, and the Herfindahl–Hirschman Index (HHI),

\[\small HHI = \sum_j s_j^2,\] where \(s_j\) is the share of AI-related file changes attributed to file or module \(j\). Higher HHI values indicate greater concentration, consistent with its use as a measure of inequality in software-maintenance effort [37].
RQ1–2: How do developers chat with AI in OSS contributions? We next examined how chat purpose is associated with subsequent development activity. We computed the average chat sessions per repository, purposes per repository, and dominant-purpose distributions, defining the dominant purpose as the category with the most labeled sessions in a repository. We then measured whether each chat session was followed by any commit or source-code commit. For the subsequent development commit, we classified the file types touched and grouped rare combinations as “Less common mixes.” For commit-scope analyses, we measured total and source-code churn, the number of source files changed, and the number of file categories touched. Finally, we compared dominant chat-purpose distributions across project content categories and OSS4SG status.

3.2.3 RQ2: How do OSS repositories’ dynamics change after AI adoption↩︎

As discussed in Section 3.2.1, we excluded repositories with pre-publication AI chats, since their observed AI use began before GitHub publication. Of the 1,240 repositories, 608 (49.0%) had their first observed AI chat after GitHub publication; we use this group as the main sample. Because these repositories tended to be young, we additionally validated our results on a more mature and larger cohort of 114 repositories filtered from the main group, averaging 5.0 contributors and 3.5 years of age. We compute the following measures for both the main cohort (\(n=608\)) and the validation cohort (\(n=114\)). To handle imbalanced pre- and post-adoption periods, we used normalized measures where appropriate and modeled temporal trends with the relative-month ITS specification.
RQ2-1: How does repository commit activity change? We analyzed repository activity at the repository-month level using the adoption timestamp defined in Section 3.2.1. For each relative month, as defined in Section 3.2.2, we computed average total commits and source-code commits before and after adoption. To evaluate temporal trends before and after AI adoption, we estimated an interrupted time-series (ITS) model for each outcome:

\[\begin{align} \log(1+Y_{im}) ={}& \alpha_i + \beta_1 \text{PreTime}_{im} + \beta_2 \text{Post}_{im} \\ &+ \beta_3 \text{PostTime}_{im} + \beta_4 \log(1+\text{Age}_{im}) + \epsilon_{im}. \end{align}\]

where \(Y_{im}\) is the outcome for repository \(i\) in relative month \(m\), and \(\alpha_i\) is a repository fixed effect. \(\text{PreTime}_{im}\) estimates the pre-adoption trend, \(\text{Post}_{im}\) estimates the immediate level change after adoption, and \(\text{PostTime}_{im}\) estimates the post-adoption trend. Repository fixed effects control for stable repository differences, while \(\text{Age}_{im}\) adjusts for repository aging over time. Standard errors were clustered by repository, and we compared pre- and post-adoption trajectories using the slope contrast \(\beta_3-\beta_1\). We use the same relative-month ITS specification for all later temporal trend analyses.
RQ2-2: Is AI adoption associated with changes in code-quality signals in OSS repositories? We evaluated code-quality signals using defect-related activity, testing behavior, and CI outcomes, following prior repository-mining practice [38], [39]. All measures were computed per repository for the pre- and post-adoption periods and then modeled using the relative-month ITS specification described above.

First, we measured defect-related activity using the number and share of bug/fix commits and bug-labeled issues. Bug/fix commits were identified from commit messages containing corrective terms such as fix, bug, error, issue, patch, and regression. Bug-labeled issues were identified from GitHub issue labels containing terms such as bug, defect, regression, and error. Second, we measured testing and CI signals using the share of commits touching test files, CI failure rate, and CI success rate. A commit was considered test-touching if it modified at least one test file, identified using path- and filename-based rules such as test, tests, spec, __tests__, unittest, pytest, jest, and mocha. CI outcomes were collected from GitHub check-run and check-suite records: completed checks with success were treated as successful, while failure, timed_out, cancelled, and action_required were treated as failed. Checks with missing, non-completed, or other terminal conclusions were excluded.
RQ2-3: How do Issues and Pull Requests change? We analyzed issue and pull-request activity by volume, share, and resolution/merge efficiency. Using the first observed AI-chat timestamp as the cutoff, we assigned openings by creation time, issue closings by closure time, and merged PRs by merge time, then compared pre/post counts per repository. For share-based measures, we computed issue and PR shares among opened items, issue closure-to-opening ratios, and PR merge shares. For efficiency, issues and PRs were assigned by creation time; issue-resolution time measured creation to closure, and PR-merge time measured creation to merge. We computed mean and median times per repository before and after adoption, including only repositories with at least one resolved issue or merged PR in both periods.
RQ2-4: Is AI adoption associated with changes in OSS collaboration patterns? We defined active contributors as non-bot contributors with at least one commit in a repository period. Contributor participation was measured by the number of active contributors, and concentration by the top-contributor share,

\[\text{TopContributorShare}_{rp} = \frac{\max_j(\text{commits}_{jrp})}{\sum_j \text{commits}_{jrp}},\]

where \(\text{commits}_{jrp}\) is the number of substantive commits by contributor \(j\) in repository \(r\) during period \(p\), and by the HHI defined in Section 3.2.2. For communication and review activity, we assigned issues, pull requests, issue/PR comments, PR review comments, and PR reviews to periods by creation timestamp. We measured intensity using comments per issue/PR, PR review comments per PR, unique issue/PR commenters, and unique PR reviewers. We measured concentration using the top-commenter share, defined analogously to the top-contributor share above but over issue/PR comments, and the commenter and reviewer HHIs (see Section 3.2.2).

3.2.4 RQ3: How do developers perceive AI tool usage through vibe coding in OSS↩︎

We analyzed survey responses using descriptive and construct-level summaries. Five-point Likert items were coded from 1 (strongly disagree) to 5 (strongly agree) and summarized using means and the percentage of respondents selecting somewhat or strongly agree. For multi-item constructs, such as OSS contribution access, we averaged related items per respondent and summarized construct scores using the mean and percentage above the neutral midpoint. We used within-respondent comparisons for paired perception items, such as concerns about one’s own versus others’ AI-generated code. Multiple-choice questions were summarized as the proportion of valid respondents selecting each option, and open-ended responses were reviewed to contextualize quantitative patterns.

3.2.5 Statistical inference.↩︎

We selected statistical tests based on the structure of each analysis. For repository-level before–after comparisons, we computed one pre-adoption and one post-adoption value per repository and used paired Wilcoxon signed-rank tests, as many measures were sparse and non-normally distributed. For categorical associations, such as relationships between dominant chat purpose and project characteristics, we used chi-square tests or permutation tests where appropriate. For skewed continuous outcomes compared across chat categories, we used non-parametric tests; when multiple chat-linked observations came from the same repository, we used repository-blocked permutation tests. We corrected for multiple comparisons using the Benjamini–Hochberg false-discovery-rate procedure within families of related tests rather than globally across all analyses. Throughout, we report raw \(p\)-values, FDR-adjusted \(q\)-values, and model coefficients or odds ratios where applicable.

4pt

4 Results↩︎

4.1 RQ1: How do OSS repositories use AI coding assistants?↩︎

4.1.1 How are AI coding assistants used in OSS contributions↩︎

AI-related commit prevalence and size. Across the 1,240 repositories, AI-related commits accounted for 44.3% of post-adoption commits on average (median: 34.3%). AI-related commits share declined sharply over time, from 32.8% of post-adoption commits in the first month to 16.1% by six months and 4.4% by twelve months. This downward trend was confirmed by a Spearman correlation (\(\rho = -0.940\), \(p < .001\)) and a commit-level binomial regression (OR \(= 0.762\) per month, \(p = .015\)), indicating that AI assistance was used most heavily right after adoption and progressively phased out as repositories matured.

Moreover, across AI-related commits, total churn was highly right-skewed, with a mean of 19,947 lines and a median of 1,789. Although total churn fluctuated over time, a log-scale model estimated a 7.1% increase per relative month after adoption (\(p=.007\)). In contrast, source-code churn decreased by 13.2% per month (\(p=.002\)). Mean churn declined from 2,211 lines in the adoption month to 1,456 in months 4–6 and 1,911 in months 7–12; medians fell from 113 to 28.5 and 32 lines, respectively. Thus, the increase in total churn appears to be driven by non-source changes or unusually large commits, rather than larger source-code edits.
Repository characteristics and AI-use intensity. We next examined whether repository characteristics were associated with AI-use intensity. In bivariate analyses, AI-related commit share was negatively correlated with repository size, age, contributor count, stars, forks, and total commits, with the strongest association observed for post-adoption commits (\(\rho=-0.570\), \(p<.001\)). This association partly reflects a denominator artifact, since AI-related commit share is calculated using total commits as the denominator, but it also indicates that AI-related commits did not increase proportionally with overall repository activity. After adjusting for repository characteristics in a multivariable binomial model, only repository size in MB (OR \(=0.834\), \(p=.010\)) and contributor count (OR \(=0.531\), \(p=.047\)) remained significant negative predictors. Repository age, programming language, and project domain showed no robust associations. Overall, AI-related commits were more prominent in repositories with smaller codebases and fewer contributors, even after accounting for repository age, language, and domain.
Scope and concentration of AI-related changes. We also examined the scope of files touched by AI coding assistants. On average, each AI-related commit changed 25.7 files (median = 7.0) across 3.3 file-type categories (median = 3). Source-code files made up the largest share of files changed (43.6%), followed by documentation (15.0%), generated or binary files (11.8%), configuration files (3.5%), test files (3.2%), and dependency files (2.0%). The remaining 20.9% consisted of miscellaneous or unclassified files not assigned to a distinct category.

We further examined whether AI-related file changes were concentrated in specific files or modules (a module being the top-level directory in a file path, e.g., src, tests, with root-level files grouped as (root)). Concentration was low at the file level: the top file accounted for 10.7% of AI-related changes on average (median = 5.0%), the top three for 23.6% (median = 13.0%), and HHI averaged 0.08 (median = 0.03). Concentration was higher at the module level: the top module accounted for 62.2% on average (median = 59.9%), the top three for 90.8% (median = 97.4%), and HHI averaged 0.52 (median = 0.46). Thus, AI-related work spanned many files but clustered within a few repository areas, partly reflecting coarser module-level aggregation.

4.1.2 How do developers chat with AI in OSS contributions↩︎

Distribution of chat purposes. Repositories had an average of 9.8 chat sessions (median = 2.0) and used an average of 2.1 distinct chat purposes (median = 2.0). For each repository, we defined the dominant chat purpose as the category with the largest number of labeled sessions. Under this definition, Code Writing was dominant in 53.9% of repositories, followed by Delegation (15.5%), Failure Reporting (12.7%), and Inquiry (8.9%), as summarized in Table 1.
Subsequent activity by chat purpose. We next examined development activity in the commit associated with each labeled chat session, referred to as subsequent activity. Nearly all sessions (98.9%) had subsequent activity, and 96.1% were associated with commits that changed at least one development file. We then characterized the file-type composition of these commits using the multi-label chat-purpose assignments. Across all purpose categories, the most common associated commit type was a source-only commit, accounting for 26.9%–30.4% of associated development commits depending on the purpose. Documentation-only commits were generally the second most common pattern, ranging from 14.8% to 20.2%. Workflow Control and Validation had the highest shares of broad commits touching source, tests, documentation, configuration, and dependency files together (10.3% and 10.4%, respectively). After accounting for repository-level clustering (i.e., that observations from the same repository are not independent) using a repository-blocked permutation test, we found no evidence that chat purpose statistically predicted the file-type composition of the associated commit.
Subsequent activity scope by chat purpose. We then examined the size and scope of the first subsequent development commit associated with each chat session, regardless of file type. As shown in Table 1, total churn varied descriptively across chat purposes, with Code Writing showing the largest mean total churn and Validation the smallest. However, repository-blocked permutation tests found no robust differences in total churn, total files changed, or the number of file-type categories touched. Thus, the chat purpose did not statistically predict larger or broader subsequent commits overall. When focusing only on source-code changes, source-code churn differed significantly by chat category (\(p=.001, q=.007\)), with Failure Reporting, Delegation, and Code Writing showing the largest mean source churn. However, the number of source files changed did not differ significantly across categories.
Chat purpose across project types. We next examined whether repositories’ chat-purpose distributions or dominant purposes differed by project content category or OSS4SG status. Overall, we found no statistically reliable associations. Descriptively, Creativity-Entertainment projects had a higher share of Failure Reporting as the dominant purpose than the overall sample (19.4% vs. 12.7%), as did OSS4SG repositories (16.9% vs. 12.7%), but neither pattern was significant. Thus, project content category and OSS4SG status did not reliably explain variation in dominant chat purpose or chat-purpose distribution.

4.2 RQ2: How do OSS repositories’ dynamics change after AI adoption?↩︎

4.2.1 How does repository commit activity change↩︎

Since repositories had unequal pre- and post-adoption observation windows, we compared activity using repository-month rates relative to the adoption date [34], [40]–[42], excluding the adoption month to avoid transition-period effects. Monthly activity declined after adoption: mean commits per repository-month fell from 19.2 to 7.7, and the median fell from 4.8 to 1.0 (\(p<.001\), \(q<.001\)). Source-code commits showed the same pattern, with the mean decreasing from 13.4 to 4.7 and the median from 2.3 to 1.0 (\(p<.001\), \(q<.001\)). The validation cohort showed the same direction of change.

We then fit repository-month interrupted time-series (ITS) models with repository fixed effects, repository age, and repository-clustered standard errors. In the main cohort, activity was increasing before adoption and showed no reliable immediate post-adoption jump; the post-adoption trend turned negative, though this change was not statistically significant for total commits (\(-2.00\%\)) or source-code commits (\(-1.36\%\)). The validation cohort showed the same pattern more clearly, with a short post-adoption burst followed by a significant decline (Figure 3; the cohort trends overlap on the left because most sampled repositories are young). The two cohorts point in the same direction: a short-lived post-adoption increase followed by a decline rather than sustained growth. As a sanity check, this pattern matches prior evidence on Cursor adoption [11], lending external support to the burst-then-decline interpretation.

4.2.2 Is AI adoption associated with changes in code-quality signals in OSS repositories↩︎

We examine defect-related activity, testing behavior, and CI outcomes as observable code-quality signals. General changes are summarized in Table ¿tbl:tab:rq2-summary-signals?.
Defect-related activity. We measured defect-related activity using bug/fix commits and bug-labeled issues, inspired by prior work [38], [43]–[45]. We observed a significant rise in bug/fix commit share, while bug-labeled issues showed no meaningful change. The mean bug/fix commit share per repository increased from 9.6% (pre-adoption) to 16.9% (post-adoption), with the median rising from 0.0% to 11.1% (\(p<.001\), \(q<.001\)). Raw bug/fix commit counts did not follow the same pattern: the mean declined slightly from 17.3 to 16.1, while the median rose from 0.0 to 2.0 (\(p<.001\), \(q<.001\)). Bug-labeled issues remained largely stable, with means of 0.2 (pre) and 0.1 (post) and medians of 0.0 in both periods. The bug-labeled issue share rose non-significantly from a mean of 5.5% to 7.3%, while the median stayed at 0.0% in both periods. This pattern suggests the rise in bug/fix commit share mainly reflects the drop in overall commit volume (Sec 4.2.1), not an actual increase in defect-related activity: the same or fewer bug/fix commits now make up a larger share of a smaller total.

This interpretation is supported by the relative-month interrupted time-series (ITS) models, which showed no robust post-adoption increase in defect-related activity. Bug/fix commits rose non-significantly by 13.3% immediately after adoption and then declined non-significantly month over month. Bug/fix commit share rose non-significantly by 3.63% immediately after adoption, with an essentially flat post-adoption trend. Bug-labeled issues and their share likewise showed no reliable immediate change or post-adoption trend.
Testing and CI. For testing and CI, we examined the test-touching commit share and CI outcomes and found no broad change in testing behavior after AI adoption. Test-touching commit share rose slightly on average (5.2% to 6.0%), with the median unchanged at 0.0% in both periods, indicating that most repositories did not touch tests more often. CI outcomes were essentially stable: mean failure rates changed from 29.1% to 27.4% (median 12.2% to 13.8%), and mean success rates from 70.9% to 72.6% (median 87.8% to 86.2%).

The relative-month ITS models support this interpretation. Test-touching commit share showed a positive but non-significant immediate change (+6.7%). CI failure and success rates also showed no robust immediate change or post-adoption trend. The validation cohort showed broadly consistent but more pronounced trends. Thus, we find no clear evidence linking AI adoption to increased testing activity or changed CI outcomes.

Overall, we find no evidence of broad code-quality deterioration after AI adoption. The higher bug/fix share appears driven by reduced commit volume rather than sustained growth in defect-related activity, while testing and CI signals remained stable.

4.2.3 How do Issues and Pull Requests change↩︎

We also analyzed issue and pull-request activity before and after AI adoption. Issue activity was sparse: mean issue openings decreased from 3.6 to 0.8 per repository and mean closings from 2.7 to 0.6, with medians of 0 in both periods; neither the opening nor the closing change reached significance. Issues did, however, make up a smaller share of opened items after adoption, declining from 29.6% to 19.2% on average (\(p=.001\), \(q=.002\)), while the issue closure-to-opening ratio increased from 40.0% to 95.7% (\(p<.001\), \(q=.001\)). PR activity showed a significant before/after shift in raw volume: mean PR openings increased from 5.1 to 6.3, while the mean merged PRs changed only slightly from 4.1 to 3.9 (both \(p<.001\), \(q<.001\)), with medians remaining 0. The PR-open share also increased, from 70.4% to 80.8% (\(p=.001\), \(q=.002\)), whereas the PR merge share did not decrease significantly.

Despite these before/after differences, relative-month ITS models showed no reliable immediate or trend-level changes in issue openings, issue closings, PR openings, or merged PRs. In contrast, issue-resolution time increased substantially after adoption: the mean rose from 10.5 to 29.4 days and the median from 6.6 to 50.1 days (\(p=.002\), \(q=.008\)). PR merge time, by comparison, showed no significant increase. The validation cohort showed the same pattern but with weaker statistical support. Results were summarized in Table ¿tbl:tab:rq2-summary-signals?.

Thus, the main change was compositional: activity became more PR-oriented and less issue-oriented, with issues growing rarer but taking substantially longer to resolve once opened. This points to a reallocation of effort toward PR-based contribution rather than a net expansion of development activity, alongside reduced responsiveness to the issues that remain.

4.2.4 Is AI adoption associated with changes in OSS collaboration patterns↩︎

Contributor participation broadened modestly after AI adoption, but communication and review were still highly concentrated. On average, active contributors increased from 1.4 to 1.7 per repository, although the median remained 1.0 in both periods (\(p<.001\), \(q<.001\)). The active-contributor share also increased, from a mean of 78.9% before adoption to 86.8% after adoption, while the median remained 100% in both periods (\(p<.001\), \(q<.001\)). The validation cohort did not show the same pattern: active-contributor share decreased from 87.9% to 74.1% on average, with the median remaining 100% in both periods (\(p=.002\), \(q=.004\)). Thus, AI adoption was not consistently associated with broader contributor participation across cohorts, and the main-cohort pattern may reflect cohort composition rather than a generalizable effect.

Communication intensity changed little: comments per issue/PR increased from 1.4 to 2.0, and PR review comments per PR from 1.7 to 2.1, but neither change was statistically significant; unique commenters and reviewers per repository remained low and stable. We also examined whether this activity became more or less concentrated among participants: none of the concentration measures (e.g., top-commenter share, commenter HHI, or reviewer HHI) changed significantly, and all remained high throughout. The validation cohort showed the same overall lack of broadening in communication and review activity. Therefore, the communication and review were already highly concentrated before adoption and remained unchanged afterward. Results were summarized in Table ¿tbl:tab:rq2-summary-signals?.

4pt

4.3 RQ3: How do developers perceive AI tool usage through vibe coding in OSS?↩︎

Respondents generally viewed AI coding assistants as beneficial for OSS contribution. Most (76%) agreed that AI assistance lowers barriers to contribution, and at the construct level, the OSS contribution access scale was above neutral (mean \(= 3.8\), \(p=.002\)). More specifically, 80.0% agreed that AI support makes them more comfortable making a first OSS contribution, and 68% agreed that it makes them more confident about contributing to projects they had previously hesitated to join.

At the same time, respondents expressed quality and maintenance concerns, particularly about AI-generated code produced by others. Concern about others’ AI-generated code was significantly above neutral (mean \(= 3.9\), \(p=.009\)), while concern about one’s own AI-generated code was lower and not statistically significant (mean \(= 3.1\)). Consistent with this asymmetry, a separate paired comparison focused specifically on maintenance burden found that respondents rated others’ AI-generated code as more likely to require extra maintenance than their own (\(p=.029\)). Respondents also generally believed that human contributors remain responsible for AI-assisted code, and that OSS communities need clearer disclosure guidelines (mean \(= 4.2\), \(p<.001\)).

Respondents did not report strong general social-image concerns about using AI coding assistants in OSS (mean \(= 2.9\)). However, while 68% said they would be willing to share their chat history, the remaining respondents cited two main barriers: reputational risks, such as judgment, stigma, or appearing incompetent, and practical risks, such as increased reviewer burden or exposing ideas to competitors or AI vendors. These concerns suggest disclosure feels costly to some developers unless it offers a clear benefit to the contributor or community. Respondents also distinguished appropriate from risky AI use cases in OSS. Most considered AI coding assistants appropriate for exploring solutions before writing final code (92%), fixing small bugs or typos (84%), improving documentation (84%), and implementing small, well-scoped features (80%). In contrast, respondents most often felt AI coding assistants should be avoided for security-related changes (48%), large or complex feature development (44%), and performance-critical changes (36%).

5 Threats to Validity↩︎

5.0.1 Internal↩︎

Our sample reflects the long-tailed nature of OSS development: many repositories are small, personal, or low-activity projects, while a few are much larger and more active [46], [47]. Accordingly, repositories vary substantially in scale, collaboration structure, and development intensity, so we report both means and medians where appropriate. Because most repositories in our sample (90%) were created in 2025 or later and are relatively small or solo-maintained, generalizability to larger, established projects may be limited. To assess robustness, we repeated the main analyses on a validation repository cohort with more established teams and maintenance routines; the main patterns held, suggesting that results are not driven by the newer, smaller-repository majority. As an additional sanity check, our commit-activity trends were consistent with those reported by [11]. Beyond sample composition, our time-series models control for repository fixed effects and age, but unobserved factors such as developer experience, governance practices, or concurrent workflow changes may still confound the results. Another concern is causality. Our analyses identify changes following the first observed AI-chat session, but they do not establish that AI adoption caused those changes. Repositories may adopt AI while undergoing other changes (e.g., shifts in contributors, project phase, or maintenance practices) that could independently affect commits, testing, issues, pull requests, and CI outcomes. We therefore interpret our results as associations with AI adoption rather than causal effects.

5.0.2 External↩︎

First, our findings may not extend to private repositories, proprietary codebases, or organizations with development practices that differ from public OSS projects; we therefore limit our claims to public OSS development. Second, our survey was restricted to developers from repositories using Copilot, Cursor, or Claude Code and yielded only 25 valid responses from those with public email addresses who chose to participate, so it may not represent the broader OSS contributor population or the full range of perspectives on AI-assisted development. To partially address this, we triangulate survey responses with the repository-level commit and issue/PR data described above, so our main conclusions do not rely on survey evidence alone. Third, our findings reflect the specific observation period and the AI tools available at that time; as AI coding assistants and vibe coding workflows continue to evolve rapidly, the observed patterns may not generalize to future tool generations or usage patterns.

5.0.3 Construct↩︎

Our chat-category and project-type labels were derived through LLM-based classification with manual validation, following prior work [32], [48]. This approach enabled large-scale labeling, but may still introduce errors. To mitigate this, we adopted the same labeling procedure and taxonomy validated in prior work [16], [32]; the resulting label distribution broadly resembled that of the original study, and validation against human judgments achieved an F1 score of 0.83 for chat categories and 90.5% accuracy for project types. A second concern is that our metrics (e.g., commits, test-file changes, CI pass/fail rates) are proxies for development activity rather than direct measures of correctness, maintainability, or developer intent, and may reflect non-AI-related factors such as bulk renaming or formatting changes. We mitigate this by distinguishing source-code commits from broader commit categories, though some measurement imprecision remains.

6 Discussion↩︎

6.1 From Private Chats to Reviewable Context↩︎

Our results show that AI chat in OSS is not a single, uniform activity. Although Code Writing dominated, developers also used AI for Failure Reporting, Delegation, Inquiry, Context Specification, Validation, and Workflow Control. These purposes showed distinct downstream patterns, most often leading to source-code commits and, secondarily, documentation-only edits; Workflow Control and Validation were more often associated with broader multi-file changes. This suggests that AI chat is not merely a code-generation channel but also supports debugging, explanation, planning, validation, and coordination.

At the same time, the dominant chat purpose did not vary significantly by project type or OSS4SG status. This suggests that developers use AI chat in broadly similar ways across project domains. The more important OSS-specific issue may be what happens after these conversations: although nearly all chat sessions were followed by commits, the purpose and reasoning behind the AI interaction are usually not visible in the repository. A commit may show the final code change, but not whether AI was used to debug a failure, specify project context, validate a solution, or plan a broader update.

This creates an opportunity for lightweight transparency mechanisms in OSS platforms and workflows. For example, developers could summarize relevant AI assistance in commit messages or pull-request descriptions, indicating whether AI was used for implementation, debugging, validation, or planning. Since 68% of surveyed developers indicated willingness to share chat history, some contributors may be open to surfacing this context, but full transcript sharing should not be required. Instead, structured summaries or “AI-assisted” tags could provide useful review context while reducing concerns about stigma, reviewer burden, or exposure of sensitive ideas. Maintainers could then calibrate review effort based on the risk and scope of the change, rather than treating all AI-assisted contributions the same.

6.2 From Individual Adoption to Ecosystem-Level Consequences↩︎

Even after AI adoption, communication and review remained concentrated among a few contributors, despite survey responses suggesting that AI lowers barriers to OSS contribution. This suggests that AI may help contributors work more independently by supporting code understanding, debugging, and implementation, but it may not necessarily make collaboration more visible or distributed. However, if problem-solving increasingly occurs in private AI chat sessions, important design reasoning and debugging context may become less accessible to maintainers and future contributors. Rather than showing that team-based programming becomes less important, these findings raise a broader question: whether AI-assisted OSS contribution shifts collaboration from shared problem solving toward post-hoc review, documentation, and accountability.

Future work should therefore examine both AI adopters and non-adopters to better understand their concerns, barriers, and expectations, as well as how AI adoption evolves across OSS communities over time. Such evidence could inform OSS contribution guidelines that support open communication and collaboration, and AI tool designs that support not only code generation but also effective communication. Future research could also investigate how AI affects developer behavior, review expectations, contribution transparency, and project maintainability. Chat data offers a valuable window into developer intent, but should be carefully linked to repository outcomes such as commits, tests, issues, and pull requests to draw meaningful conclusions. Researchers should further distinguish between AI use in newly bootstrapped projects and AI adoption in mature, collaborative projects, as these contexts likely involve different risks, benefits, and governance needs.

Our findings also raise platform-level questions. If AI-assisted development increasingly produces small or solo-maintained repositories, platforms such as GitHub may need to better support how AI-heavy projects are created, reviewed, maintained, and sustained, especially as AI-driven activity may strain existing infrastructure [8]. One option is to surface AI-tool usage as repository metadata, similar to language or license information, through maintainer self-reporting, tool integrations, or inferred activity patterns. Such metadata could help contributors assess a project’s maintenance model before contributing to or depending on it. Community practices are equally important: although some tools already mark AI involvement through co-author trailers, standardized lightweight disclosure remains limited [49], [50]. Maintainers could also require targeted review steps for AI-heavy contributions, such as tests or human-written documentation, to keep design reasoning visible when initial problem-solving occurs in private AI sessions.

7 Conclusion↩︎

AI coding assistants have become conversational collaborators that support vibe-coding, where developers guide AI-generated code through natural language. Yet little is known about how these interactions relate to subsequent OSS activity. We collected 13,360 AI conversation sessions across 1,356 OSS repositories, linked them to repository histories, and complemented the results with a developer survey. We found AI use concentrates in smaller, less mature, less collaborative repos. Post-adoption, projects generally gained contributors and reduced contributor concentration, though communication stayed concentrated. Code Writing dominated chat use, most sessions led to commits, and code quality/merge rates held steady. Surveys show developers see AI as lowering contribution barriers, but worry about others’ AI-generated code, reviewer burden, perceived incompetence, and idea exposure. These offer a large-scale empirical view of AI-assisted OSS contribution and inform responsible vibe-coding governance.

References↩︎

---

1. https://specstory.com/↩︎

2. https://www.qualtrics.com/↩︎