The Impact of Generative AI on Collaborative Open-Source Software Development: Evidence from GitHub Copilot

1. Introduction

• The study addresses uncertainty about AI’s effects on voluntary OSS participation and project-level contributions, beyond well-defined individual tasks.Easier development may encourage participation, but collaborative OSS settings leave the overall participation effect unclear.Source: §1 · pp. 2–3

How do AI pair programmers affect project-level code contributions in OSS development?

• Coordination time measures the time needed to integrate individual contributions, which AI could shorten through easier code evaluation or lengthen through increased discussions.The second research question examines this unresolved effect in informal, decentralized OSS coordination.Source: How do AI pair programmers affect… · p. 3

OSS development?

• The study applies generalized synthetic control to project-month data combining public GitHub records and proprietary Copilot usage from January 2021 through December 2022.Treated project-months require both local coding-environment support and actual Copilot use; control projects never use Copilot during the sample. Robustness checks include different samples, matching, instrumental-variable estimation, and alternative estimation.Source: OSS development? · p. 4
• 5.9% more project-level code contributions and 8% longer coordination time accompany Copilot use, yet timely project-level code merges improve overall.The findings reveal a tradeoff between contribution gains and the time required to integrate contributions.Source: OSS development? · pp. 4–5
• Contribution gains accompany greater developer participation and individual productivity, while longer coordination accompanies more discussions, more discussion participants, and greater discussion intensity per developer.In this open collaborative setting, volunteers perform distinct tasks requiring integration; reconciling broader ideas and perspectives may prolong coordination.Source: OSS development? · pp. 5–6
• Core developers show larger contribution increases, while peripheral developers experience larger increases in coordination time.The authors link these differences to greater expected net benefits for core developers and peripheral developers’ limited project familiarity; role differences need not reflect technical skills.Source: OSS development? · pp. 4–5
• The proposed explanation combines higher expected contribution benefits with lower development costs, affecting both whether developers participate and how much they contribute.AI may increase benefits through ideation and exploration of alternative solutions while reducing development time and effort, extending attention beyond cost reduction alone.Source: OSS development? · pp. 5–6
• The authors emphasize governance supporting peripheral contributors and organizational processes and team structures that address increasingly important coordination and integration constraints.AI may shift contributions toward core developers; in firms, developers central to decision-making and system design may benefit more.Source: OSS development? · pp. 6–7

2.1 Generative AI in Software Development

• 55.8% faster HTTP-server implementation with Copilot was reported by Peng et al. (2023), exemplifying prior research’s focus on individual task productivity.Hoffmann et al. (2025) find that Copilot shifts developers toward coding and away from project management. Yeverechyahu et al. (2024) examine extrapolative versus interpolative innovation and compare AI’s influence in Python versus R.Source: §2.1 · p. 7
• Research on generative AI’s project-level effects remains limited for collaborative OSS, where participation is voluntary and coordination lacks formal centralized processes.The unresolved questions concern participation in both coding and non-coding activities, alongside team coordination.Source: §2.1 · p. 7
• The study distinguishes core and peripheral developers by roles, responsibilities, expected contribution benefits, and project familiarity rather than programming skill.Prior skill-based comparisons (e.g., Brynjolfsson et al. 2025, Cui et al. 2026) offer limited insight into these role-based differences.Source: §2.1 · pp. 7–8

2.2 Generative AI and Voluntary Participation

• AI’s effect on voluntary OSS participation is ambiguous: it could weaken skill-development and reputation incentives or lower contribution costs by overcoming technical challenges.OSS participation serves complex problem-solving, skill development, software quality, and reputation goals (Shah 2006, Kononenko et al. 2018). Other settings show reduced Stack Overflow participation (Burtch et al. 2024) and fewer simple-coding job postings (Demirci et al. 2025), but those findings may not transfer to OSS.Source: §2.2 · p. 8

2.3 Generative AI in Team Coordination

• The study examines coordination time in fluid, self-organizing OSS teams integrating heterogeneous individual contributions, rather than fixed teams developing one shared solution.Distributed OSS developers coordinate without centralized task allocation or hierarchical oversight (Lindberg et al. 2024). Coordination time indicates efficiency relevant to timely software delivery.Source: §2.3 · p. 9
• Prior studies find that AI can impede idea convergence (Li et al. 2024) or improve cross-disciplinary alignment (Dell’Acqua et al. 2025).Li et al. (2024) attribute coordination difficulties to the increased volume and diversity of ideas introduced by AI.Source: §2.3 · p. 9

3.1 AI Pair Programmers and Project-level Code Contributions

• H1 predicts that AI pair programmers increase project-level code contributions by encouraging developer participation and greater individual output.AI-enhanced ideation is expected to increase skill-signaling, reputational, and intrinsic benefits, while reduced contribution time and effort lower expected costs.Source: §3.1 · pp. 10–11

3.2 AI Pair Programmers and Coordination Time

• H2 predicts that AI pair programmers increase coordination time spent discussing code to align efforts, resolve conflicts, and integrate contributions.Automation frees time for discussion, improved understanding enables feedback, and less-familiar contributors require additional clarification. Greater discussion volume and diversity are expected to outweigh interaction-efficiency gains for a given contribution level.Source: §3.2 · pp. 11–12

3.3 Core and Peripheral Developers

• Core developers define project objectives and oversee software delivery, while peripheral developers bring different user perspectives through improvements such as bug fixes and new features.These differences in roles and responsibilities motivate separate predictions about AI’s contribution and coordination effects.Source: §3.3 · p. 13

3.3.1. AI Pair Programmers and Code Contributions for Core vs. Peripheral Developers

• H3 predicts that AI pair programmers produce larger increases in project-level code contributions from core developers than from peripheral developers.Core developers’ authority, project familiarity, and visible contributions are expected to yield greater benefits, encouraging participation and individual output. Their broader contribution scope also allows larger reductions in total expected costs.Source: §3.3.1 · pp. 13–14

3.3.2. AI Pair Programmers and Coordination Time for Core vs. Peripheral Developers

• H4 predicts that AI pair programmers increase coordination time more for peripheral developers’ code contributions than for core developers’ contributions.Peripheral developers’ limited project context can produce AI-assisted code requiring additional alignment discussions. Core developers can provide context-rich prompts and better-aligned outputs, while other contributors’ limited familiarity may constrain prolonged discussion of their changes.Source: §3.3.2 · pp. 15–16

4. Data

• January 2021 through December 2022 defines the GitHub Archive project panel, spanning Copilot’s June 2021 introduction and June 2022 public availability.The analysis examines project-level code contributions and coordination time.Source: §4 · p. 16
• 9,244 projects initially meet the activity, collaboration, project-metadata, and IDE-disclosure requirements.Eligible projects have nonzero size, a specified language and license, a description, and no mirror or personal-store designation. They require code submissions every six months, another activity each year, and at least three contributing developers each month.Source: §4 · pp. 16–17
• 5,687 treatment projects and 3,557 controls are initially identified using Copilot usage and IDE compatibility.Treatment projects use Copilot and supported IDEs; controls use unsupported IDEs without Copilot, with IDE usage determined from project webpages. Treatment begins in the first month with IDE support and a nonzero share of developers using Copilot.Source: §4 · p. 17
• GitHub’s proprietary data measure the monthly proportion of contributing developers using Copilot for each project, without identifying individual users.Usage is measured at the GitHub platform level; the authors expect developers to use Copilot across projects where feasible.Source: §4 · p. 17
• 7,637 projects comprise the final sample: 4,491 treatment projects and 3,146 controls, retaining only project-months with at least one code contribution.This restriction permits acceptance-time measurement and a common sample for contribution and coordination analyses. Robustness checks remove the contribution restriction and expand eligibility to projects with as few as two developers.Source: §4 · pp. 17–18

5.1 Measures

• Project-level contributions count eventually merged pull requests, while coordination time measures the monthly project average duration from submission to acceptance.Contributions are assigned to the submission month and include pull requests merged by December 2023, capturing successful changes incorporated into projects.Source: §5.1 · p. 18, §5.2 · p. 18

5.2 Model and Estimation

• Generalized synthetic controls accommodate staggered Copilot adoption by matching treated projects’ pretreatment outcomes and accounting for time-varying unobservables.The method combines synthetic controls with interactive fixed effects (Xu 2017) and can construct counterfactuals from a relatively small control sample.Source: §5.2 · pp. 18–21
• The model log-transforms both outcomes and allows Copilot’s treatment effects to vary across projects and months.The average treatment effect on treated projects is calculated from differences between observed outcomes and their constructed counterfactuals.Source: §5.2 · pp. 19–20
• Zero additional unobserved factors were selected by cross-validation after accounting for project and time fixed effects.Estimation first uses control-group data to select latent factors, then fits treated-unit loadings by minimizing pretreatment prediction errors.Source: §5.2 · p. 20
• Equivalence tests found no significant pretreatment outcome differences between treated projects and their synthetic controls.Additional validation includes placebo tests, treatment-effect plots, alternative samples, matching, instrumental-variable analysis, and alternative estimation.Source: §5.2 · p. 21

6.1 Main Results

• 5.9% more merged PRs in active projects accompanied an 8% increase in average time to merge a single PR after Copilot use.The proposed explanations are higher expected contribution benefits and lower contribution costs, alongside increased code discussions that lengthen coordination.Source: §6.1 · pp. 21–22

6.2 Robustness Checks

• Robustness analyses preserved the main findings of more merged PRs and longer average merge times across alternative specifications.Checks included within-IDE comparisons, propensity-score matching with difference-in-differences, and an instrument based on prior collaborators’ adoption outside the focal project. Additional analyses addressed spillovers, outliers, AI-related projects, workload, alternative measures, estimators, and sample definitions.Source: §6.2 · pp. 22–23

6.3.1 Project-level Code Contributions

• 3.4% more developers had merged PRs, while average merged PRs per developer increased by 2.1%, supporting both broader coding participation and greater individual productivity.Both measures correlated positively with project-level code contributions, consistent with increased expected net benefits of contributing.Source: §6.3.1 · pp. 23–24

6.3.2 Coordination Time

• 6.5% more comments per merged PR accompanied 1.7% higher code discussion participation and 5.9% higher code discussion intensity per developer following Copilot use.All three discussion measures correlated positively with coordination time; discussion-topic diversity and discussion cycles per merged PR also increased. Core developers completed more reviews with broader participation and higher reviews per developer, arguing against reduced review activity as the explanation for longer coordination.Source: §6.3.2 · pp. 24–26

6.4 Combined Effects of Project-level Code Contributions and Coordination Time

• 3.5% more PRs merged within one day, 4.1% within three days, and 5.1% within ten days indicate positive net timely-merge effects.Timely merges correlated positively with project-level contributions and negatively with coordination time.Source: §6.4 · p. 27
• Issues and bugs increased after Copilot use, but issues and bugs per merged PR and monthly stars and forks showed no significant changes.The authors attribute higher issue counts to greater contribution volume rather than lower individual-contribution quality, while cautioning that the short sample may obscure downstream recognition effects. Copilot’s effects did not differ significantly between simple and complex projects.Source: §6.4 · pp. 27–28, §6.5 · p. 28

6.5 Core and Peripheral Developers

• 6.5% higher core developers’ share of merged PRs and 5.4% higher peripheral developers’ relative average merge time followed Copilot use.Relative merge time compares peripheral developers’ average with the project-wide average; peripheral developers also experienced smaller timely-merge gains. Both groups increased contributions, coding participation, and individual productivity while experiencing longer coordination and more discussion.Source: §6.5 · pp. 28–30
• Core developers gained relatively more coding participation and individual productivity and increased their share of feature-related PRs, consistent with greater expected contribution benefits.The feature-related analysis compares similar tasks across groups, mitigating task-heterogeneity concerns and providing suggestive evidence about differences in expected net benefits.Source: §6.5 · p. 30
• Participation gains following Copilot use were more pronounced among new peripheral developers than existing peripheral developers.The proposed explanation is that AI pair programmers reduce expected participation costs more for newcomers, while peripheral developers’ expected benefits remain relatively stable.Source: §6.5 · p. 31
• Project familiarity may partly explain differences in code contributions and coordination time between core and peripheral developers.Peripheral developers had shorter project tenure and received a higher proportion of context-clarification comments. Copilot use was associated with a greater increase in highly familiar developers’ contribution share and a greater coordination-time reduction for their contributions relative to the project average.Source: §6.5 · p. 31
• Peripheral developers had lower project-level code contributions and longer coordination times than core developers following Copilot use, alongside greater code discussion demands.Discussion volume, the number of discussion participants, and discussion intensity per developer increased, potentially helping explain peripheral developers’ relatively longer coordination times.Source: §6.5 · pp. 30, 32
• Programming-language expertise did not differ significantly between core and peripheral developers, while Copilot usage appeared higher among peripheral developers.Lower programming skills or lower Copilot usage therefore appear unlikely to explain peripheral developers’ lower contributions and longer coordination times.Source: §6.5 · p. 32
• Core–peripheral findings remained consistent after controlling for prior project coordination time and after excluding December 2022, which overlapped Chat GPT’s initial release.The coordination controls addressed potential crowding out of peripheral contributions by increased core-developer activity; excluding December addressed possible confounding from other AI tools.Source: §6.5 · p. 32
• Both core and peripheral developers experienced longer first-review-to-acceptance durations following Copilot use, with larger increases for peripheral developers.This alternative coordination measure excludes waiting before the initial review, indicating that the findings are not solely attributable to longer prereview waits.Source: §6.5 · pp. 32–33

7. Discussion and Conclusions

• Copilot use increases project-level code contributions but lengthens coordination time, alongside greater coding participation, individual productivity, and code discussions.The study uses proprietary project-level GitHub data. Increased discussion activity includes both more participating developers and greater discussion intensity per developer.Source: §7 · p. 33
• Core developers experience larger contribution gains, while peripheral developers experience larger coordination delays and contribute a smaller proportion of timely merged code.The authors interpret this difference through developers’ roles: core developers can capture signaling, ideation, and project-level benefits, whereas peripheral developers primarily experience cost reductions.Source: §7 · p. 33, §7.1.1 · pp. 34–35

7.1.1 Theoretical Implications

• The study extends individual-programmer research to voluntary OSS collaboration, explaining how AI can change contribution incentives while increasing coordination needs.Its theoretical account proposes that creativity and alternative solutions raise expected benefits while reduced effort and time encourage participation and productivity. In decentralized communities, wider, more heterogeneous participation may require reconciling viewpoints and integrating contributions.Source: §7.1.1 · p. 34

7.1.2 Practical Implications

• OSS communities should consider pull-request templates, AI-output validation, and mentoring to help peripheral contributors overcome coordination frictions.The authors warn that persistent frictions could discourage peripheral participation and concentrate activity among core developers, weakening broad participation and diverse perspectives.Source: §7.1.2 · p. 35
• In firms, architectural knowledge and decision-making responsibility may shape AI benefits beyond routine coding assistance.Developers central to system design and integration may gain more through experimentation, coordination, and higher-level problem solving; developers with narrower implementation roles may mainly benefit in routine coding.Source: §7.1.2 · pp. 35–36
• Improved code generation may shift software development’s primary constraint toward coordination, making productivity gains depend on review, integration, and alignment capacity.Even firms with structured coordination may face additional demands from increased code output, making organizational processes important determinants of AI’s returns.Source: §7.1.2 · p. 36

7.2 Limitations and Future Work

• Privacy constraints, observational data, and limited panel size restrict conclusions about individual adoption, developer differences, coordination mechanisms, and long-term effects.Individual usage is unobserved, limiting analyses of adoption heterogeneity, role transitions, and spillovers; unobserved motivation, ability, and preferences may also shape responses. The data cannot identify intermediate coordination mechanisms or establish whether effects persist as developers gain experience.Source: §7.2 · p. 36
• Broader social and governance effects remain unexamined, including authorship transparency, ownership, credit assignment, community trust, skill erosion, coding biases, and security risks.The authors call for research on these potential consequences and frameworks supporting safe, transparent, and ethical AI use in software development.Source: §7.2 · pp. 36–37

Tables and Figures:

• 0.023, 0.031, and 0.023 are Copilot’s estimated increases in core developers’ contributor share, relative per-developer contributions, and new-feature contribution share, respectively.Relative per-developer contributions use all developers as the baseline; estimates include project and month fixed effects. The first two estimates have p<0.01; the third has p<0.05.Source: Tables and Figures · pp. 41, 43, Table 9 · p. 43

Appendix A: Estimation Details of the Generalized Synthetic Control Method (GSCM)

• GSCM combines interactive fixed effects (Bai 2009) and synthetic controls (Abadie et al. 2015), accommodating staggered adoption, multiple treated projects, and relatively few controls.The combination relaxes pre-treatment parallel-trends assumptions while accounting for unobserved factors whose effects vary across projects and time.Source: Appendix A · p. 46
• GSCM selects the latent-factor count minimizing pre-treatment out-of-sample mean squared prediction error, rather than optimizing information-criterion fit.Candidate models use control-project data and leave-one-period-out validation on treated projects before adoption. The appendix argues that even factor-free GSCM improves on DID unless treatment is randomly assigned and treatment effects are homogeneous.Source: Appendix A · pp. 47–48
• GSCM averages observed-minus-counterfactual outcomes among treated projects to estimate treatment effects, using bootstrapping for confidence intervals and standard errors (Xu 2017).Synthetic controls represent outcomes without treatment; their post-treatment validity depends on accurate pre-treatment predictions.Source: Appendix A · pp. 46, 48

Appendix B: Equivalence Test of Pre-trend in GSCM

• 0.14 to 0.26 times the residualized untreated outcome’s standard deviation defines the study’s approximate equivalence bounds across outcomes.These data- and uncertainty-dependent bounds are more conservative than the ±0.36 benchmark proposed by Liu et al. (2024). The two-one-sided t test requires each pre-treatment period’s average prediction error to fall within the equivalence range.Source: Appendix B · p. 49
• 0 is the reported equivalence-test p-value for contributions, coordination time, and timely merges, with 90% confidence intervals inside equivalence bounds.The authors interpret these results as evidence of no pre-treatment trends, sufficient confounder control, and a suitable GSCM control group.Source: Appendix B · p. 49, Figure B.1 · p. 50, Figure B.2 · p. 50

Appendix C: Placebo Test in GSCM

• Three pre-treatment periods form the placebo window; TOST equivalence tests (Liu et al. 2024) assess effects on project-level contributions, coordination time, and timely merges.The tests assess practical equivalence to zero against a null of meaningful differences, helping evaluate strict exogeneity and detect potential model misspecification.Source: Appendix C · p. 52
• Merged and timely merged pull requests initially drop at treatment onset, potentially reflecting developers’ adjustment to Copilot or its integration into workflows.Equivalence still holds within the pre-treatment window, supporting the credibility of the synthetic control construction.Source: Appendix C · p. 52
• Pre-treatment placebo effects show no meaningful departures from zero, supporting the validity and robustness of the GSCM causal identification strategy.Estimated pre-treatment effects are at or below zero, whereas post-treatment effects are substantially above zero.Source: Appendix C · p. 52, Figure C.1 · p. 53

Appendix D: Within-IDE Analysis

• Matching treatment and control projects within the same Copilot-supported IDE addresses concerns about development-environment differences and developer self-selection.The design addresses differences between supported and unsupported IDEs, variation across supported IDEs, and characteristics of developers choosing Copilot-compatible IDEs.Source: Appendix D · p. 55
• 4,462 projects comprised the matched sample analyzed using GSCM: 3,215 treatment projects and 1,247 control projects.The analysis covers January 2021–March 2022. Treatment projects adopted Copilot during July 2021–March 2022; control projects adopted after March 2022.Source: Appendix D · p. 55
• Copilot increased merged PR counts and average time to merge a PR in the within-IDE analysis, consistent with the main findings.The supplied table caption identifies these outcomes, but no numerical estimates are provided.Source: Table D.1 · p. 56, Appendix D · p. 56

Appendix E: PSM and DID

• June 2021 serves as the common treatment date, addressing concerns about non-random adoption timing but potentially understating positive effects because developers adopted gradually.The DID specification includes project and month fixed effects, with post-treatment months defined as those after June 2021.Source: Appendix E · pp. 57–58
• 2,122 projects—1,061 treated and 1,061 controls—formed the matched sample, with no statistically significant differences across the pre-treatment matching covariates.One-to-one nearest-neighbor matching without replacement used logit propensity scores. Covariates were log-transformed January–June 2021 averages of merged PR counts, merge time, contributing developers, push events, release events, opened issues, and closed issues.Source: Appendix E · p. 57, Table E.1 · p. 58
• Copilot significantly increased merged PR counts and average time to merge a PR in the matched DID analysis, consistent with the main findings.The comparison measures changes after Copilot became available relative to changes in projects that never used Copilot during the sample period.Source: Table E.2 · p. 58, Appendix E · p. 58
• Four pre-treatment lead indicators were statistically insignificant, providing no evidence of pre-treatment trends in merged PR counts or average merge time.The relative-time model included four lead indicators and 18 post-treatment lag indicators.Source: Appendix E · p. 59, Table E.3 · p. 60

Appendix F: Instrumental Variable Analysis

• The project-month instrument combines exposure to an early Copilot adopter with the time between the earliest collaborator’s adoption and the focal project’s adoption.The relevance argument is that early-adopter contacts convey knowledge, while longer exposure permits more information exchange and observation.Source: Appendix F · pp. 61–62
• Instrument construction identifies each focal developer’s historical collaborators in external projects, then combines these networks into a project-level set of prior collaborators.The instrument uses these external connections to address potential endogeneity in Copilot use.Source: Appendix F · p. 61
• Early adopters adopted Copilot during July–September 2021; exposure uses 2020 external collaborations for focal developers observed between October 2021 and December 2022.A focal developer is considered exposed if any identified external collaborator adopted Copilot during the early period.Source: Appendix F · p. 62
• 268.36 was the first-stage F-statistic, with a significantly positive relationship between the instrument and Copilot use indicating strong instrument relevance.Instrument relevance does not resolve the separate concerns about exclusion.Source: Appendix F · p. 62
• The authors treat the analysis as supplementary because developers connected to early adopters may differ in network characteristics or exposure to other technologies.Their exclusion argument assumes that adoption in unrelated, out-of-sample projects affects focal-project outcomes only through focal developers’ adoption decisions.Source: Appendix F · p. 62
• Copilot increased both the number of merged PRs and the average time to merge a single PR in the instrumental-variable analysis.Both directions are consistent with the main findings.Source: Appendix F · p. 62, Table F.1 · p. 63

G.1 Refined Sample

• Excluding projects with developers in both treatment and control groups preserves Copilot’s increases in merged PRs and average PR merge time.Approximately 3.5% of selected projects had overlapping developers. Prior Copilot experience could also create spillovers into control projects, making estimated contribution and coordination-time effects lower bounds.Source: Table G.1 · p. 64, §G.1 · p. 64

G.2 Outlier Removal

• Removing projects with unusually high or low merged-PR counts or average PR merge times leaves results consistent with the main findings.Source: §G.2 · pp. 64–65, Table G.2 · p. 65

G.3 Non-AI Topic Projects

• Excluding AI-related projects leaves results consistent with the main findings, addressing potential confounding from topic-specific enthusiasm and developer composition.Source: Table G.3 · p. 65, §G.3 · p. 65

G.4 Alternative Measures; Appendix H: Additional Evidence on the Mechanisms for H1 and H2

• Alternative measures—submitted PRs, commits, and coordination intervals in days or minutes—produce results consistent with the main analysis.The main measures are merged PRs and hours from submission to acceptance. Appendix H presents correlation analyses linking participation and individual productivity to project contributions, discussions to coordination time, and contributions and coordination time to timely merges.Source: Table G.4.1 · p. 66, §G.4 · p. 66, Table G.4.2 · p. 66

G.5 Effect of Workload

• Controlling for cumulative submitted PR workload leaves the coordination-time results qualitatively consistent with the main findings.The model adds the log number of cumulative submitted PRs through the focal month to address delays potentially caused by greater review workload.Source: §G.5 · pp. 66–67, Table G.5 · p. 67

G.6 Alternative Estimation

• A two-way fixed effects model using the full sample yields findings qualitatively consistent with the main analysis.Source: Table G.6 · p. 67, §G.6 · p. 67

G.7 Expanded Sample

• Expanding the sample to include projects with two developers yields results qualitatively similar to the main findings.The main sample includes projects with three or more developers.Source: §G.7 · p. 67, Table G.7 · p. 68

G.8 Additional Alternative Sample

• Including project-months with zero merged PRs preserves the contribution findings, but coordination time cannot be assessed without PR acceptance times.The main analysis includes only project-months with at least one eventually merged PR.Source: Table G.8 · p. 68, §G.8 · p. 68

I.1 Text Analysis of Comment Content

• 5,404,735 merged pull-request comments from selected projects during 2021–2022 formed the LDA corpus used to measure topic counts and topic-distribution entropy.Non-English comments and comments too short to convey meaningful information were excluded. Coherence and diversity scores guided selection of 10 topics.Source: §I.1 · pp. 70–71
• Copilot adoption increased both the number of discussion topics and topic-distribution entropy per merged pull request, suggesting broader discussion content contributed to longer coordination time.These measures capture distinct topics and the evenness of their distribution.Source: §I.1 · pp. 70–71, Table I.1 · p. 71

I.2 Discussion Cycles

• Copilot increased discussion cycles per merged pull request, requiring more iterative exchanges before agreement and integration and thereby extending coordination time.A discussion cycle is an iterative round concerning the same proposed changes within one merged pull request.Source: Table I.2 · p. 71, §I.2 · p. 71

Appendix J: The Impact of Copilot and Project Complexity

• Projects were classified as complex or simple using a median split of their lines of code before Copilot adoption.The check addressed opposing possibilities: complexity could attract contributors and increase coordination demands, or higher expected costs could suppress coding and discussion participation.Source: Appendix J · p. 72
• Both simple and complex projects exhibited increased project-level code contributions and longer coordination time following Copilot adoption.The separate project-group analyses showed similar directional patterns.Source: Appendix J · p. 72, Table J.1 · p. 73, Table J.2 · p. 73
• The project-complexity interaction was not statistically significant in PSM and DID analyses, providing no evidence that Copilot’s effects differed between simple and complex projects.This analysis tested whether project complexity moderated Copilot’s effects.Source: Appendix J · p. 72, Table J.3 · p. 73

Appendix K: Additional Analyses on the Effects of Copilot on Core and Peripheral Developers

• 6.1% higher project-level code contributions accompanied a 6.7% increase in coordination time for core developers following Copilot adoption.Timely integrated code contributions increased by 4.4%, 4.8%, and 5.8% within one, three, and ten days, respectively.Source: Appendix K · p. 74, Table K.1 · p. 75
• 5.4% higher project-level code contributions accompanied a 5.3% increase in coordination time for peripheral developers following Copilot adoption.Timely integrated code contributions increased by 2.3%, 2.4%, and 3.6% within one, three, and ten days, respectively.Source: Appendix K · p. 74, Table K.2 · p. 75
• 5.5% higher developer coding participation and 5.6% higher individual code contributions accompanied Copilot adoption among core developers.Code discussion volume, code discussion participation, and code discussion intensity per developer increased by 4.1%, 1.6%, and 3.6%, respectively.Source: Appendix K · pp. 74–75, Table K.3 · p. 76
• 2.8% higher developer coding participation and 2.2% higher individual code contributions accompanied Copilot adoption among peripheral developers.Code discussion volume, code discussion participation, and code discussion intensity per developer increased by 12.6%, 2.3%, and 11.4%, respectively.Source: Appendix K · p. 75, Table K.4 · p. 76
• New peripheral developers’ share and participation increased significantly after Copilot adoption; the share increase was not driven by declining existing-developer participation.New developers had not previously contributed to the focal project. The proposed explanation is that AI lowers expected contribution costs more for new than existing peripheral developers.Source: Appendix K · pp. 76–77, Table K.5 · p. 77

Appendix L: Project Familiarity

• Core developers had significantly longer pre-Copilot project working tenure than peripheral developers, supporting greater project familiarity.For projects continuously active during 2018–2021, familiarity was measured as the number of months developers contributed before June 2021.Source: Table L.1 · p. 78, Appendix L · p. 78
• High-familiarity developers experienced relatively greater gains in code-contribution share and reductions in coordination time relative to the project average after Copilot adoption.High familiarity meant working tenure above the project-specific median before Copilot adoption.Source: Appendix L · pp. 78–79, Table L.2 · p. 79

“You can find the table of valid contexts here.”

• Peripheral developers received a higher proportion of context-clarification comments, suggesting project familiarity might partly explain differences in Copilot’s coordination effects.Dictionary-based keyword matching covered 5,404,735 discussion records. Qualitative discussion patterns concerned design intent, project-specific context and history, and integration uncertainties.Source: Appendix L · p. 79, Table L.3 · p. 80, “You can find the table of valid… · p. 80

• Peripheral developers had significantly higher Copilot adoption rates, despite smaller project-level code contribution gains and greater coordination-time increases than core developers.The authors interpret this pattern as favoring project familiarity over adoption differences. GitHub supplied project-level adoption percentages by role, but privacy restrictions prevented access to individual-level usage data.Source: Appendix M · pp. 81–82, Table M.1 · p. 82
• Core and peripheral developers showed no statistically significant difference in the percentage of programming language experts, weakening expertise as an explanation for heterogeneous effects.Experts were developers who used the focal project’s primary language in at least 75% of their prior projects.Source: Appendix M · p. 81, Table M.1 · p. 82
• Peripheral contributions increased in number but declined as a proportion of total contributions following Copilot adoption, even after controlling for prior coordination time.Controls included lagged log average merge times for core developers’ code and peripheral developers’ code, addressing concerns that increased core activity crowds out peripheral contributions.Source: Table M.2 · p. 82, Appendix M · p. 82
• Review duration increased for both groups, with larger increases for peripheral developers, even after excluding waiting time before the first review.Measured from first review to final acceptance, this alternative isolates review-stage coordination rather than initial-review delays. Its increase is consistent with increased code discussion.Source: Table M.3 · p. 83, Appendix M · p. 83