Govern the Repository, Not the Agent: Measuring Ecosystem-Level Risk in AI-Native Software Daniel Russo
arXiv:2606.28235v1 [cs.SE] 26 Jun 2026
Department of Computer Science Aalborg University, Copenhagen, Denmark [email protected] Abstract—Autonomous coding agents now open and merge pull requests in shared repositories at scale, and the field evaluates them the way it has always evaluated components, one agent at a time, on isolated benchmark tasks. Yet agents that each pass their own tests still leave repositories that accumulate problems no single contribution accounts for. We ask whether this problem belongs to the individual agent or to the repository where it accumulates. We study integration friction, the cost of integrating a contribution into a codebase that other contributors are concurrently changing. Across more than 930,000 agentauthored pull requests, we measure how much of the variation in friction stays with the repository after the contribution, its author, its size, and its agent are accounted for. About half does, and it survives full controls. In the same repositories, agentauthored contributions concentrate this repository-level friction roughly twice as much as human ones (intraclass correlation 0.30 versus 0.16), a gap that holds after controlling for codebase size, age, task shape, process maturity, and merge path. The risk is a property of the ecosystem, not the agent. AI-native software is therefore better measured and governed at the ecosystem level than one agent at a time. Index Terms—emergence, complex adaptive systems, multiagent systems, AI-assisted software engineering, software ecosystems, multilevel models
I. I NTRODUCTION Software is increasingly written by autonomous coding agents. Tools such as OpenAI Codex, Devin, GitHub Copilot, Cursor, and Claude Code open pull requests, respond to review, and merge changes into shared repositories with limited human direction, and their public activity already runs to hundreds of thousands of agent-authored pull requests [1], [2]. The field governs them as it has always governed components, one at a time, on isolated benchmark tasks (e.g., SWEbench [3]). That practice rests on a compositional assumption software engineering has long relied on. If each part is correct, so is the system built from those parts. Agentic development breaks that assumption in plain sight. A contribution can pass every automated check while the repository it enters drifts into a state no participant fully holds in mind. Developers working alongside these agents report the symptoms directly. Code arrives faster than they can understand it, shared mental models erode, and rationale goes unwritten [4]. These reports document the problem, but they do not tell us where it originates. This question matters for how
AI-native software is built and governed. We ask whether the problem belongs to the individual agent or to the ecosystem of agents, humans, and automation that produces the software, and how an engineer could distinguish the two with evidence rather than intuition. This paper locates the problem in the ecosystem, and measures it. We study integration friction, the effort of integrating a contribution into a codebase that other contributors are concurrently changing, observable as slow merges, repeated review, and merge conflicts. Using multilevel models, the standard tool for data nested in groups, we ask how much of the variation in friction stays attached to the repository once each contribution, with its author, size, and agent, has been accounted for. A share that remains is a property of the whole that no single part explains, the statistical signature of what complex-systems research calls emergence [5]. About half of the variation in friction sits at the repository level, and most of it survives full controls. In the same repositories, agent-authored contributions concentrate this repository-level friction roughly twice as much as human ones (an intraclass correlation of 0.30 versus 0.16), and the gap holds once codebase size, age, task shape, process maturity, and merge path are accounted for. The concentration is specific to agent-authored software. We make three contributions. First, we recast a practitionerreported problem as a measurement question. The issue is not how to repair a single agent but at what level the risk should be measured (Section III). Second, we give that question an operational, metric-independent test, statistical non-reducibility, computed with models the field already uses, together with a matched human baseline showing the signal is specific to agent authorship rather than a generic property of high-activity repositories (Sections III to V). Third, we turn the result into a measurement and governance agenda for AI-native software, with a reproducible replication package (Section VI). The capability of individual agents is a necessary but not sufficient condition for a dependable repository, and AInative software is therefore better measured and governed at the ecosystem level than one agent at a time.
II. R ELATED W ORK A. The reported difficulty and how we treat it Deferred cost has long been used to reason about expedient choices in software, from code and architecture [6], [7] to the social structure of development organizations [8], and practitioners now report an analogous accumulation under agentic development, where code arrives faster than teams can absorb it [4]. We treat that report as the symptom to be located, not as a framework to adopt, and ask instead at what level the difficulty resides. B. Programming as theory building and Conway’s law Naur argued that programming is, at heart, the building of a theory of a problem and its solution in the minds of the programmers, and that this theory cannot be reconstructed from the program text alone [9]. When the code is generated for us, the artefact exists without the understanding behind it. That understanding is a team-level asset that can be lost: projects suffer disproportionate knowledge loss when contributors leave [10], and developers who lean on AI assistance score lower on later comprehension of the same code [11]. Conway observed that the structure of a system mirrors the communication structure of the organization that builds it [12], a mirroring later borne out empirically [13]. As agents become both producers and reviewers of code, that organization turns into a mixture of humans, agents, and automation, and its partly emergent structure is stamped onto the systems it builds. C. Software ecosystems and coordination cost The software ecosystem, a set of actors coordinating on a shared technical platform, is a well-established unit of analysis [14], [15]. Empirical work shows that ecosystem-level outcomes are not reducible to single packages. The cost of a breaking change is shifted among maintainers, downstream users, and end-users according to ecosystem norms [16], dependency-network structure differs systematically across ecosystems [17], and a single package or maintainer can place a large share of an ecosystem at risk [18], [19]. Socio-technical congruence further ties such coupling-driven coordination cost to the technical dependency structure [20], [21]. This literature quantifies particular ecosystem-level properties, but it does not ask whether any such property is statistically non-reducible, and it does not address agent-authored software. D. Emergence and complex adaptive systems Anderson’s slogan that more is different frames emergence as a claim about reducibility. The behaviour of a large collection need not follow from the rules of its parts [5]. Over the past decade this idea has been turned into formal, measurable theory in the study of complex systems, including effective information, which measures when a coarse, wholesystem description has more causal power than the finegrained description beneath it [22], information-decomposition tests for predictive information that no single part carries on its own [23], [24], and dynamical independence, a wholesystem variable evolving under its own laws rather than as
a summary of the parts [25]. This theory has been tested on physical, biological, and neural systems, but not on software. Separately, software and information-systems research has described open-source communities and software ecosystems as complex adaptive systems [26]–[28], sometimes quantitatively, as in ecological models of ecosystem evolution [29], and recent theoretical work develops this account specifically for AInative ecosystems, framing the resulting comprehension gap as one of their emergent properties [30]. None of it, however, tests the analogy with a measure of non-reducibility. Our novelty is not the analogy but attaching such a computable measure to integration friction in an agentic software ecosystem, testing it on real data, and asking whether the signal is specific to agent-authored software through a matched human baseline. E. Multi-agent AI and agents in real repositories The word emergence entered machine learning to describe abilities that are absent in small models and appear in large ones [31], a usage later contested on the grounds that the apparent jump may be an artifact of the metric chosen to score it [32]. We therefore use a criterion that depends on no chosen metric. Beyond the single model, populations of agents develop shared conventions and collective biases that none shows alone [33], group behaviour is not predictable from the agents in isolation [34], and group size itself can drive misalignment [35]. Closer to engineering practice, an empirical taxonomy of multi-agent failures finds that most arise not inside an agent but between agents, in specification, inter-agent misalignment, and verification [36], and emerging research agendas for agentic software engineering reframe the field around human-agent and agent-to-agent collaboration rather than the isolated tool [37]–[39]. These accounts argue, but do not measure, that the failures that matter are ecosystemlevel. By an agentic ecosystem we mean contributions arriving asynchronously into a shared, evolving codebase. This does not require several vendor tools: a single orchestrator such as Claude Code delegating to sub-agents creates the same condition as Copilot and Codex working in one repository. On real repositories, the AIDev datasets record agentauthored pull requests at scale [1], [2], AgenticFlict records whether each pull request would conflict with its evolving base branch [40], and longitudinal industry analysis links rising AIassisted development to more duplicated code and churn and less refactoring [41]. Agentic friction escalates a documented pre-agentic phenomenon rather than introducing a new one, i.e., scripted bots already generated friction developers perceive as noise [42], [43], and review-bot adoption reshaped repository-level pull-request dynamics [44]. These datasets enable detailed descriptive analyses of the phenomenon, which we complement by proposing and empirically testing a generative mechanism for it. Short-run productivity gains from AI assistance are real [45], [46] but front-loaded: experienced developers on mature code can be slower despite expecting a speed-up [47], and outcomes that swing with context in this way are what an ecosystem-level account predicts.
B. Four hypotheses [ Related Work: summary and research gap Prior work analyses the individual agent or contribution, applies emergence theory to systems other than software, quantifies particular ecosystem-level properties of software ecosystems (costshifting, dependency-network risk, technical lag) without a general emergence test, or applies the complex-adaptive-systems analogy without a non-reducibility test. Multilevel variance partition is itself standard in software-engineering research. What is new is binding a metric-independent non-reducibility test to integration friction on agent-authored data, and showing, through a matched human baseline, that the signature is specific to agentauthored software.
III. T HEORY: E MERGENCE AS N ON -R EDUCIBILITY A. An operational definition We need a definition of emergence that an empirical software engineer can actually measure. The micro level is the individual participants and their contributions, a particular agent, a particular pull request, its size and its author. The macro level is a property of the repository as a whole, such as how much integration friction it accumulates over time. We account for who wrote each pull request, how large it was, and which agent produced it, and if repositories still differ systematically in their friction afterward, that leftover difference cannot be a fact about individual pull requests, because we have already subtracted those. It must belong to the repositories themselves, the empirical sign that a property belongs to the whole and not to its parts [5], [23]. We call the criterion statistical because the evidence is a partition of observed variation rather than the result of a controlled experiment. Rather than intervening on a repository, for instance by adding or removing an agent and measuring the effect, we observe repositories as they already are and use statistical models to separate the variation that belongs to the repository from the variation that belongs to individual contributions. This definition is independent of any threshold or success metric, which protects it from the charge that apparent emergence is merely an artifact of where someone drew a cutoff [32]. How it is computed, with multilevel models that the field already uses, is the subject of Section IV-B. A surviving repository-level difference is necessary but not sufficient for emergence. Since emergence implies such a difference, its absence would rule emergence out; but other mechanisms could produce the same difference, so its presence supports emergence without establishing it. The complexsystems literature offers stronger measures that establish causation, such as the effective information of Hoel et al. [22] and the dynamical independence of Barnett and Seth [25], but those require controlled interventions or long, fine-grained time series that a public record of pull requests simply does not contain. We therefore measure the signal the available data can support, and we leave the stronger causal measures to future work (Section VII).
The account yields four hypotheses that we test directly. Each is stated so that the data could falsify it. H1 (coupling). If an emergent ecosystem exists, agents do not act in isolation, and interaction with humans and automation is pervasive. If instead agents mostly worked alone, there would be no ecosystem to speak of. H2 (locus). The coupling runs through the shared codebase as it changes. Integration friction arises when the base branch is modified while a pull request is open, so the driver of friction should be the rate of change of the base branch while the contribution is in flight (its base-branch churn), not the number of distinct agents present. This prediction separates our account from the intuitive view that the danger is multiple agents interfering with one another (e.g., two agents editing the same files at once). ® RQ1 (tests H1, H2): do autonomous coding agents operate as an interacting ecosystem on shared repositories, and at what level does integration friction originate?
H3 (non-reducibility). Repository-level integration friction is not reducible to the properties of individual agents and contributions. Even after we account for those, a substantial share of the variation in friction remains a property of the repository as a whole. ® RQ2 (tests H3): is repository-level integration friction nonreducible to the properties of individual agents and contributions?
H4 (specificity). The non-reducibility is a property of agentauthored software in particular, not of repositories in general. In the same repositories, agent-authored contributions carry higher repository-level non-reducibility than human-authored ones. Were any contributor to produce the same ecosystemlevel signal, the non-reducibility would be a fact about repositories rather than about agents, and the appeal to emergence in agentic software would be unnecessary. ® RQ3 (tests H4): is the repository-level non-reducibility specific to agent-authored software, or a general property of repositories that human-authored contributions show equally?
On this account, the symptoms practitioners report are views of one underlying state rather than separate problems. Integration friction (H2 and H3) is the part we can observe directly, the cost of integrating each contribution into a codebase under concurrent change, the coupling-driven coordination cost that socio-technical congruence ties to technical dependency structure [20]. The same mechanism would produce two further symptoms that we do not measure here, each following from one of our findings. Because the repository-level signal is nonreducible (RQ2), the behaviour that matters lives at a level no single contribution accounts for, so no participant can hold a working model of it and shared understanding falls behind, the oversight gap developers report when agent-authored diffs arrive faster than they can be reviewed [9]–[11]. Because the
ecosystem has no single controller (RQ1), there is no single place where its intent is set, so the macro-goal tends to go unrecorded. We measure integration friction here and flag these two as open for future work.
This is an observational measurement study across multiple datasets. We estimate how much of the variation in integration friction sits between repositories rather than within them; this is a variance partition, not a treatment effect. We change nothing about how the agents work and observe only what they already did. In the ABC framework, this design trades controlled manipulation for generalizability over real actors in their natural setting [48], and follows established empiricalsoftware-engineering conventions [49].
of 0.4, for instance, means that about 40% of the variation in the outcome lies between repositories and the remaining 60% lies within them, between one PR and the next in the same repository. The higher the ICC, the more the repository as a whole, rather than its individual contributions, accounts for the outcome. Multilevel models with a repository random effect are not new to software engineering. Pull-request studies fit them and report explained-variance statistics as model fit [54], [55], and recent work partitions cycle-time variance across organizational and individual levels [56]. What we add is to read the repository-level partition as a metric-independent criterion for non-reducibility rather than a fit statistic, and to compare it across agent- and human-authored contributions in the same repositories (Section IV-H). Our contribution is the criterion and the comparison, not the multilevel models themselves.
B. Level of analysis and why multilevel models
C. Datasets and the measured terms
Our unit of analysis is the repository: a shared, continuously evolving codebase together with the contributors and automation that act on it. We call this local system an ecosystem to signal that it is shaped by interaction among its parts. This is the repository-internal sense of the term, distinct from the established cross-package “software ecosystem” such as the npm package network [14]. The data have two levels. Each pull request belongs to a repository, so pull requests are nested inside repositories. That nesting is the phenomenon under study rather than a statistical nuisance, because nonreducibility is a claim about where the variation in friction resides. The method must therefore separate variation between repositories from variation within them, and a multilevel (hierarchical) model is the tool for this [50]–[52]. Each friction outcome we measure, such as how long a pull request takes to merge, is a construct; Section IV-E defines the seven we use. For a construct y, pull request i inside repository j is modelled as
The study combines two public datasets with targeted GitHub API fetches, all keyed to the two levels just described, and we introduce the actors and measured terms where the data defines them. AIDev [1], [2] is our primary source, organized as two linked tables joined by repository identifier, a pull-request table and a repository table. Each pull-request row is authored by an autonomous coding agent (agent for short), a tool that opens and submits pull requests with limited human direction. The five agents in AIDev are OpenAI Codex, Devin, GitHub Copilot, Cursor, and Claude Code, and every row is labelled with which one wrote it. A row also carries the fields our constructs need: size (additions and deletions), an LLM-assigned task type, submission timing, and the PR’s reviews, comments, and linked issues. Each repository row carries popularity (stars, forks), primary language, and activity volume. We use the enriched curated subset (33,596 PRs across 2,807 repositories above 100 stars) as the primary source and the full set (930,292 PRs across 116,211 repositories) for cross-checking. A multiagent repository is one in which two or more distinct agents are active, and the number of distinct agents counts how many share a repository. RQ1 uses this count and weighs it against agent-to-agent interaction, one agent acting on another agent’s pull request, the agent-interference account it tests against. Only Copilot and Devin act through dedicated bot accounts, whereas Codex, Cursor, and Claude Code act through the human operator’s own GitHub account, so attributed interactions are only partly observable and RQ1 rests on the agent-count-independent conflict comparison. The third actor we distinguish from agents and humans is an automated bot, non-agent automation such as a continuous-integration check or a review bot (for example CodeRabbit). AIDev contains only agent-authored PRs. A contributor is whoever authors a pull request, human or agent, so the human population, and with it the baseline for RQ3, is absent from AIDev. We fetch human-authored PRs for the same repositories from the GitHub API and recompute every construct identically (Section IV-H), giving the two populations whose
IV. M ETHODOLOGY A. Design overview
⊤ η(yij ) = β0 +x⊤ ij β+zj γ +uj +εij ,
uj ∼ N (0, τ 2 ), (1)
where η is the identity link on log(1 + y) for continuous constructs, xij collects the PR-level covariates and agent indicators, zj collects the repository covariates, and εij ∼ N (0, σ 2 ) is the leftover variation within a repository. The key term is uj , the repository random intercept, a per-repository offset drawn from a normal distribution with variance τ 2 that captures how much a repository’s friction sits above or below the average once its contributions have been accounted for. A large spread of these offsets, that is, a large τ 2 , is the repository-level signal we are after. The repository-level variance partition coefficient [53], also known as the intraclass correlation (ICC), τ2 , (2) τ 2 + σ2 is our operational measure of non-reducibility, the share of the total variation that belongs to the repository (τ 2 ) out of the repository-plus-within-repository total (τ 2 + σ 2 ). An ICC ICC =
repository-level friction RQ3 contrasts. The same API supplies the two repository confounders absent from AIDev, codebase size (diskUsage) and age (created_at), for 99% of curated repositories. AgenticFlict [40] adds one construct absent from AIDev. It replays each agentic PR’s merge deterministically against the base branch as that branch evolved, and records whether the PR would conflict. We link it to AIDev by owner, repository, and PR number, and it covers 28.5% of curated PRs (9,582). Every other construct is computed from AIDev PR fields, the repository covariates from the repository table and the API, and the agent indicator from the PR label. We record provenance by dataset revision and SHA-256 hash, re-derive every figure with a separate audit script, and ship a replication package under a fixed seed. D. RQ1 measures To measure coupling (H1) we check, for each PR, whether it drew a review or comment from an account other than its author, and we sort the reviewers and commenters into three kinds, human accounts, automated bots, and the PR’s own author acting on its own work. To measure how many agents share a repository, we count the distinct agents per repository within bands of activity, and in repositories with more than one agent we measure how much the agents are active at the same time. To locate where friction comes from (H2) we compare AgenticFlict conflict rates between repositories with several agents and those with one, and across the five agents, and we count direct agent-to-agent actions, meaning one identifiable agent acting on another agent’s PR. E. Friction constructs We measure integration friction through a family of seven PR-level outcomes rather than a single number, grouped inside repositories, because evidence that points the same way across several measures is stronger than evidence from any one of them. The family covers four facets (N at the primary cutoff of repositories with ≥ 10 agentic PRs): • Timing: deliberation latency (hours from creation to merge, on engaged PRs; N = 6,958) and resolution latency (hours from creation to resolution; N = 26,694). • Effort: review rounds (count of review events) and comment volume (count of comments), each on N = 27,958. • Contention: changes requested (whether a review asked for changes; N = 27,958) and conflict incidence (whether the merge conflicts in AgenticFlict; N = 5,956). • Outcome: rejection, a PR closed and not merged (N = 26,694). A signature that shows up across all four facets cannot be an artefact of one measurement choice. Latency is defined only on engaged PRs, that is, PRs that drew a review or comment, for the reason given in Section IV-F. F. Isolating deliberation from automation Time-to-merge has two peaks corresponding to two different processes. Most agent pull requests are merged within minutes
(median 32 seconds), automatically or by the operator’s own account, with no real deliberation about how the contribution fits. Pull requests that draw a review or comment behave differently, with a median time-to-merge of 2.2 hours and a 75th percentile near a full day. Pooling the two would mix automation speed into integration friction and distort the variance estimates of interest. We therefore define deliberation latency only on engaged pull requests, and keep resolution latency, defined on all resolved pull requests, as the selectionrobust companion measure. G. Estimation and the non-reducibility test The estimand is the ICC of Eq. 2, and the test is to track it under increasingly demanding controls. Here we give the estimation details for the seven constructs. Two of our seven constructs are yes-or-no outcomes (a PR either conflicts or it does not), so an ordinary variance does not apply directly. For these binary constructs we fit a logistic mixed model and read the ICC off an underlying continuous scale, using the standard logistic residual variance π 2 /3 in place of σ 2 [53], [57], ICClatent =
τ2 τ 2 + π 2 /3
,
(3)
and we check this against a simpler linear-probability fit. Some constructs are counts (numbers of review rounds or comments), which tend to vary more than a basic count model expects; this excess spread is called overdispersion. To absorb it we add a per-observation random effect, which gives the Poisson-lognormal model, a close relative of the negative-binomial model [58], [59], and we report a log(1+x) Gaussian fit as a sensitivity check. The split of variation into a part explained by covariates and a part that is not follows the generalized-linear-mixed-model decomposition of Nakagawa and Schielzeth [60]. The continuous constructs are fit by restricted maximum likelihood [61], [62]. The binary random-intercept models are fit by dense fixed-grid numerical integration of the random intercept, validated against exact marginal-likelihood integration. The core idea of the analysis is to add explanatory variables in stages and track how the repository-level variance τ 2 responds. If the repository signal were merely a proxy for properties of individual contributions, adding those properties would make τ 2 shrink toward zero. We fit four nested models. M0 is the null model, with only the repository random intercept and no covariates, which gives the raw repository signal. M1 adds PR-level covariates (PR size as additions plus deletions, task type, submission timing) and one indicator per agent. M2 adds repository covariates (popularity as stars and forks, primary language, activity volume). M3 adds the two repository-level confounders we judged most plausible, codebase size and repository age. Watching τ 2 fall (or not) across this sequence shows how much of the repository signal the observed attributes can explain, and how much remains non-reducible. To put uncertainty on these estimates we use a cluster bootstrap for the continuous constructs, which resamples whole repositories rather than individual PRs so that
the grouping is preserved [63], and profile-likelihood intervals on the variance component for the binary constructs, and we report 95% intervals. We check robustness across four activity cutoffs (≥ 1, 5, 10, 20 agentic PRs, with ≥ 10 as primary) and within the subset of repositories that host more than one agent. Codebase size and repository age come from the GitHub API (diskUsage and created_at) for 99% of curated repositories. We release them only as deciles tied to an anonymized repository hash, so the replication package ships no raw repository identifiers, and models fit on the raw values and on the binned values agree to within 0.0005 (Section V). H. A human-authored baseline (RQ3) A high repository-level ICC for agent contributions could still be a generic property of active repositories, inherited by any contributor. RQ3 settles the question with a matched within-repository comparison. Because AIDev records only agent-authored PRs, we assemble the human arm separately. For each of the 404 curated repositories at the primary cutoff (at least 10 resolved agent-authored PRs), we fetch from the GitHub API the pull requests in the same observation window that AIDev did not label as agent-authored, with their reviews and comments, and recompute every construct. We exclude bot and agent accounts ([bot] logins, GitHub bot accounts, and known agent and continuous-integration bots, including the Copilot coding agent), so the arm is human-authored. The agent arm is the AIDev agentic PRs in the same repositories, so the comparison is strictly within-repository. To stop a few high-volume repositories from driving it, we cap both arms at the 200 most-recent PRs per repository, with the estimate unchanged under a random 200-PR cap. Conflict incidence stays agent-only, because the AgenticFlict replay cannot be reconstructed for historical human PRs, while the other six constructs transfer. We then estimate the repository-level ICC separately for the two arms under a common covariate set (PR churn, repository covariates, codebase size, and age, with agent identity dropped), and report the agent-minus-human difference with cluster-bootstrap 95% intervals. Two further controls guard against alternative readings. Because the populations need not draw the same work, we add a task-shape proxy, diff dispersion, measured identically as the number of distinct toplevel directories a PR touches and the number of changed files (M3T = M3 + dispersion). To rule out process maturity, we add M4 = M3 + team size + continuous-integration presence, with team size the count of distinct human contributors. Of the 404 repositories, 314 reach at least 10 resolved human PRs, the matched set for each construct is the intersection of the two arms (282 for the headline resolution-latency construct), and 33 repositories are inaccessible (renamed or made private), a survivorship limit we report. The binary constructs are read on the latent scale with profile-likelihood intervals.
V. R ESULTS A. RQ1: Agents form an interacting ecosystem, and friction originates at the repository level, not between agents. 1) Agents do not act in isolation, and interaction is pervasive (H1): H1 holds only if an agent’s work is taken up by others rather than handled by the agent alone. The most direct test is cross-account engagement, whether a pull request draws a review or a comment from an account other than its author. Two of every five agent pull requests do (39.7%), and such exchanges are not confined to a few projects, and 66.5% of repositories contain at least one engaged pull request (Table I), so interaction is the normal condition across the population rather than a local effect of a few busy repositories. The form of that interaction separates deliberate review from passing discussion. Formal review reaches 24.2% of pull requests, and where it occurs it is iterative, averaging 3.5 review events per reviewed pull request and asking for changes 1,604 times, while comments reach 38.6%. What rules out the obvious alternative, that this traffic is merely an agent acting on its own output, is the composition of the reviewing and commenting accounts. They divide in comparable proportions among human accounts, automated bots, and the authoring agent itself. The population engaging with agent work is mixed, human, agent, and automation together, which is what an interacting ecosystem requires and what H1 states. 2) Multiple agents per repository, a minority that grows with activity: Agents also increasingly share repositories as a project gets busy. Multi-agent repositories, i.e., those in which two or more of the five distinct agent tools are active (not repeated runs of a single tool), are a minority overall (8.3% of the curated set) but reach 31.2% among the most active, and in half of them (49.8%) different agents are active within the same seven-day window (Table I). We count multiplicity by distinct tools because that is what the data let us trace, but RQ2 is estimated over all repositories regardless of tool count. Consolidation onto a single orchestrator such as Claude Code with sub-agents would therefore leave it unchanged. Several agents working at once, the case in which an agent-interference account is most plausible, is therefore common enough in busy repositories for the comparison that follows to be meaningful. 3) Friction tracks the repository, not the number of agents (H2): If integration friction came from agents interfering with one another, repositories with several agents would conflict more often than those with one, yet the merge-conflict rate is statistically indistinguishable between multi-agent and single-agent repositories (two or more agents versus one; 30.8% against 31.2%, Table I), so raising the number of agents leaves friction essentially unchanged. To the question agentic-development teams will ask, whether adding agents to a repository compounds its integration problems, the answer at the level of conflict is no. We rest H2 on this comparison because it does not require attributing any action to a particular agent, which the data only partly permit. What the conflict rate does move with is the identity of the contributing agent, ranging from 15.4% for Copilot to
TABLE I RQ1 ECOSYSTEM DESCRIPTIVES . F IGURES ARE COMPUTED ON THE CURATED SET (2,807 REPOSITORIES ABOVE 100 STARS ) UNLESS A ROW NOTES THE FULL POPULATION .
Measure
Value
PRs with cross-account engagement Repositories with an engaged PR PRs reviewed (events per reviewed PR) PRs commented Repositories with ≥ 2 agents (curated / full) among repos with ≥ 20 agentic PRs Multi-agent repos with cross-agent PRs ≤ 7 days Conflict rate, multi-agent vs single-agent repos Direct agent-to-agent actions (lower bound)
39.7% 66.5% 24.2% (3.5) 38.6% 8.3% / 1.7% 31.2% 49.8% 30.8% vs 31.2% 2
32.3% for Codex. Friction therefore comes from a single contribution having to merge into a repository that moved on while its pull request was open, as H2 states, not from agents interacting. Directly observable agent-to-agent actions are rare, two in the whole corpus, but we treat that count as a lower bound carrying no weight in the argument, because three of the five agents act through the operator’s GitHub account and some agent-to-agent interaction is therefore invisible in the record. The stronger statement, that the repository signal actually weakens as more distinct agents are added, requires the variance models and is taken up under RQ2. B. RQ2: Repository-level friction is non-reducible to individual agents and contributions. 1) A large share of repository-level variance survives full adjustment (H3): H3 is the central claim, that the friction belongs to the repository as a whole rather than to the individual agents and contributions we can measure. The hypothesis would fail if accounting for those individual properties explained the repository signal away, so we subtract them and see what is left. Take the headline construct, resolution latency in repositories with at least 10 agentic PRs. With no covariates, half of its variation sits between repositories
TABLE II RQ2 VARIANCE PARTITION AT THE PRIMARY CUTOFF ( REPOSITORIES WITH ≥ 10 AGENTIC PR S ). R EPOSITORY- LEVEL ICC FOR THE NULL (M0) AND COVARIATE - ADJUSTED (M2) MODELS ; ∆ VAR IS THE M0- TO -M2 REDUCTION IN REPOSITORY VARIANCE . B INARY CONSTRUCTS (†) REPORT LATENT- SCALE ICC.
Construct Deliberation latency Resolution latency Review rounds Comment volume Changes requested† Rejection† Conflict incidence†
M0 ICC
M2 ICC
∆var
0.46 0.50 0.57 0.70 0.66 0.37 0.23
0.41 0.40 0.48 0.61 0.52 0.26 0.18
38% 41% 34% 40% 45% 41% 26%
† latent-scale ICC (logistic mixed model).
rather than within them (ICC 0.50, 95% CI [0.34, 0.61]). Adding everything we know about each contribution and its setting, PR size, agent, task type, timing, popularity, language, and activity, lowers the ICC only to 0.40 (Table II), and codebase size and age barely change it (0.39 [0.24, 0.51], Table III). Those covariates explain only about 41% of the between-repository variance, so close to three-fifths of it survives. Deliberation latency, which restricts to engaged PRs to isolate human review (Section IV-F), agrees within 0.03 and decomposes the same way. Its ICC is 0.46 with no covariates. The PR- and agent-level controls (M1 ) cut the betweenrepository variance by 31%, and the repository covariates (M2 ) by seven points more, lowering the ICC to 0.41 [0.34, 0.45]. What is left does not belong to any repository attribute we can name. The signal could also be an artefact of which pull requests draw attention, because whether a pull request draws any review or comment at all is itself a strongly repository-level property (latent ICC 0.85, and 0.78 after full controls), so the engaged-only deliberation latency conditions on a repositorydriven selection effect. Resolution latency, defined on all resolved pull requests, does not condition on that selection and gives nearly the same ICC (0.39 versus 0.41 at M3 ), so the non-reducibility signal does not depend on which pull requests draw attention. 2) The signature is consistent across constructs and activity cutoffs: A single construct or a single activity cutoff could give a misleading picture, so Figure 1 reports both. Because the seven constructs span the four facets of friction defined in Section IV-E, from timing to final outcome, their agreement shows the repository-level signal is a property of friction in general rather than of one measure. The left panel gives the adjusted ICC for all seven friction constructs, which ranges from 0.18 for conflict incidence to 0.61 for comment volume. The right panel gives the resolution-latency ICC across the four activity cutoffs, where it stays between 0.40 and 0.52. 3) More distinct agents weaken the residual rather than amplifying it: If the signal came from agents interacting, restricting to repositories with several agents would strengthen it, but the reverse happens. Holding activity comparable (repositories with at least 10 agentic PRs), the repository-level ICC is lower in multi-agent repositories than in single-agent ones, 0.21 (95% CI [0.12, 0.31]) against 0.47 ([0.26, 0.60]) for the headline resolution latency under full controls, with the same ordering for deliberation latency (0.34 against 0.43). More agents do not raise the repository-level concentration of friction, and in fact lower it. An agent-interference account predicts the opposite, that this concentration should grow with the number of agents. Because friction lives in the evolving codebase rather than in agent count (H2), adding distinct agents brings varied authorship that pulls the repository intercept down instead of adding friction. The prediction we leave to future work is that the repository-level concentration should fall as the distinct-agent count rises and recover where one agent dominates.
Most repository-level friction survives full adjustment
0.7
Headline ICC is stable across cutoffs M0 (null) covariate-adjusted (M2)
0.61
Comment volume
0.6 0.52
latent
0.48
Review rounds 0.41
Deliberation latency
0.40
Resolution latency (headline) Rejection
latent
Conflict incidence
latent
resolution-latency ICC
Changes requested
0.5 0.4 0.3 0.2
0.26 non-reducible (survives M2) explained by controls (M0 − M2)
0.18
0.1 0.0
0.0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
1
5
10
20
activity cutoff (min. agentic PRs)
repository-level ICC
Fig. 1. RQ2. Left: repository-level ICC for each friction construct, null (M0) and covariate-adjusted (M2); a large share of repository-level variance survives covariate adjustment across all seven measures. Right: the resolution-latency ICC is robust across activity cutoffs. This surviving repository-level variance is a necessary statistical signature of emergence.
4) The signature survives codebase size and repository age: The most plausible rival explanation is a stable repository attribute we failed to measure, above all codebase size and project age. We obtained both from the GitHub API for 2,780 of the 2,807 curated repositories (99.0%), size from diskUsage and age from created_at, with age essentially uncorrelated with the activity covariate already in M2 (Spearman ρ = −0.04). Estimated on this covariate subsample, adding both (M3 = M2 +size+age) removes only 0.7% of the resolution-latency repository variance, leaving the ICC at 0.39 (Table III). Across all seven constructs the two attributes explain at most 13.6% of the repository variance and usually under 3%, so a nonzero ICC survives across all constructs, and no single repository drives the signal. In a leave-one-repository-out jackknife (Figure 2), removing any one repository leaves the resolution-latency ICC between 0.31 and 0.40 (full value 0.39), and the per-repository offsets are broadly spread rather than concentrated in a few repositories. H1 through H3 hold. Whether the signal is specific to agentauthored software is the question for RQ3.
human difference excludes zero from the null model through full controls (Table IV). The gap is largest for the latency constructs, +0.22 for deliberation latency (95% CI [0.13, 0.29]) and +0.14 for resolution latency ([0.08, 0.19]), agent 0.30 against human 0.16, close to twice. For the binary contention and outcome constructs, read on the latent scale, it is near +0.13 for both changes requested and rejection, each interval excluding zero. A concentration that stands above the human level on every construct, in the same repositories, is not a generic repository effect. It is specific to agentauthored software, as H4 states. Because the agent-versushuman comparison is made within the same repositories, every fixed repository attribute the two populations share, such as maintainer responsiveness, contribution norms, and review culture, is held constant and cannot by itself produce a contributor-specific gap. The gap must therefore arise from agent authorship itself. 2) Ruling out attention, task shape, maturity, and merge path: One construct behaves differently. Whether a pull
C. RQ3: The non-reducibility is specific to agent-authored software.
TABLE III C ONFOUNDER ROBUSTNESS : CODEBASE SIZE AND REPOSITORY AGE ADD LITTLE . M3 = M2 + SIZE + AGE , ON THE 2,780 REPOSITORIES (99%) WITH G IT H UB -API COVARIATES . T HE LAST COLUMN IS THE FRACTION OF THE M2 REPOSITORY VARIANCE THAT SIZE AND AGE REMOVE .
1) Agent contributions concentrate friction at the repository level far more than human contributions (H4): A high repository-level concentration does not on its own point to agents, because those repositories might concentrate friction from any contributor, not only agentic ones. H4 holds only if the concentration is specific to agent-authored work, which a comparison between the two populations in the same repositories can settle. That comparison is consistent and runs in the same direction across constructs. On the shared repositories, the repository-level ICC for agent contributions stands above the human ICC on every construct, and the agent-minus-
Construct Deliberation latency Resolution latency Review rounds Comment volume Changes requested Rejection Conflict incidence
ICC M2
ICC M3
size+age share
0.42 0.39 0.49 0.61 0.52 0.25 0.18
0.41 0.39 0.48 0.61 0.52 0.23 0.16
2.5% 0.7% 0.8% 1.3% 0.9% 7.9% 13.6%
No single repository drives the signal
repositories
200
reported band [0.31, 0.40] full ICC = 0.391
150 100 50 0 0.32
0.34
0.36
0.38
0.40
resolution-latency ICC (leave-one-repository-out, M3)
Repository effects are broadly distributed reference normal
density
0.6 0.4 0.2 0.0 −2
−1
0
1
2
3
repository random intercept (M3) Fig. 2. Robustness after the size-and-age control (M3 ). Top: the leave-onerepository-out jackknife of the resolution-latency ICC stays between 0.31 and 0.40 around the full value 0.39, so no single repository’s removal collapses the signal. Bottom: the estimated repository random intercepts are broadly distributed, so the signal is not produced by a few repositories.
request draws any review or comment at all is strongly repository-level for humans and agents alike (latent ICC 0.77 for agents and 0.67 for humans, a gap of about 0.10 [0.04, 0.16]). Attention is set by the repository, not by which agent contributes. What agent authorship concentrates is the friction and latency a contribution then generates, where the agent ICC exceeds the human one. Four ordinary explanations could produce this agent-minus-
TABLE IV RQ3 SPECIFICITY CONTRAST. R EPOSITORY- LEVEL ICC FOR AGENT- AND HUMAN - AUTHORED PR S ON THE SAME SHARED REPOSITORIES (M3 ), WITH THE AGENT- MINUS - HUMAN DIFFERENCE AND 95% CI S ( CLUSTER BOOTSTRAP FOR CONTINUOUS CONSTRUCTS , PROFILE - LIKELIHOOD FOR BINARY ). B INARY CONSTRUCTS (†) USE THE LATENT SCALE ; CONFLICT INCIDENCE IS AGENT- ONLY AND OMITTED .
Construct
Agent
Human
Agent−Human
Resolution latency Review rounds Comment volume Deliberation latency Rejection† Changes requested†
0.30 0.35 0.54 0.43 0.27 0.54
0.16 0.28 0.43 0.21 0.13 0.41
+0.14 [.08,.19] +0.07 [.02,.13] +0.11 [.05,.17] +0.22 [.13,.29] +0.13 [.08,.18] +0.13 [.03,.23]
Engagement†
0.77
0.67
+0.10 [.04,.16]
† latent scale. Differences use unrounded ICCs.
human gap in repository-level concentration without any appeal to agent authorship, and the data rule out each one. The first is a division of labour. Agents and humans here are matched on task shape (standardized mean differences near zero for changed files and directories touched), and conditioning on this diff dispersion (M3T ) moves every gap by at most 0.006, with every interval still excluding zero. The second is process maturity. Adding team size (distinct human contributors) and continuous-integration presence (M4 ) leaves every gap essentially unchanged. The third is merge mechanics. Agents auto-merge more than humans (0.37 to 0.39 against 0.03), yet adding a merge-path covariate leaves every gap intact (the resolution-latency gap stays at +0.14). Because fast, unreviewed merges dominate the agent arm, that control pulls the estimate toward zero, so the surviving gap is conservative. The deliberation-latency gap is read on reviewed pull requests where the two merge paths overlap, so it does not extrapolate. The fourth is generic heterogeneity, a broad agenthuman difference that would show up on any measure, not just friction. As a placebo we recompute the comparison on PR diff size, which the author fixes before the contribution meets the changing codebase, so friction cannot shape it. The gap there is smaller (+0.10 [0.05, 0.15] for churn, +0.09 [0.03, 0.13] for files touched) than the resolution, deliberation, changesrequested, and rejection gaps. A small baseline gap is present even before contributions meet the codebase, but the friction gaps sit above it, so on those four constructs the concentration is friction-specific rather than generic. VI. D ISCUSSION The problems that agentic development leaves behind, slow and contested merges, repeated review, conflicts, and rejected contributions, are a property of the repository rather than of the agent that produced any one of them. This friction survives every attempt to attribute it to individual contributions, their authors, size, or agents: about half of its variation stays with the repository (resolution-latency ICC near 0.40, under full controls). The matched agent-versus-human comparison is what makes the concentration specific to agentauthored software rather than to high-activity repositories in general. In the same repositories, agent-authored contributions concentrate this repository-level friction roughly twice as much as human ones (0.30 versus 0.16), and the gap holds under codebase size, age, task shape, process maturity, and merge path. The data overturn two intuitive explanations. Friction arises when each contribution meets a concurrently changing base branch, not from agents interfering with one another, since the conflict rate is flat across agent count and the repository-level ICC is lower where several agents coexist (0.21 versus 0.47). This result reframes the difficulty practitioners report [4]: the symptoms need not be separate problems with separate fixes, but follow from one mechanism, the non-reducible concentration of friction at the repository level, whose effect on integration we measure here.
The unit of governance therefore moves from the agent to the repository. Four practices follow, each anchored to a result above and computable from version-control and continuous-integration telemetry a project already produces. ¬ Assess agents inside the target repository. A score earned on detached benchmarks does not predict behaviour in the target repository, where agent contributions concentrate friction more than human ones (resolutionlatency ICC 0.30 against 0.16). Evaluate a candidate by running it on a feature branch for a fixed window, reading its repository-level friction as the acceptance signal and re-estimating on a rolling basis to detect drift before merge permissions widen. ¬ Govern change tempo rather than headcount. Conflict is flat across the number of agents, and the repositorylevel ICC is in fact lower where several agents coexist (0.21 against 0.47), so friction comes from a contribution meeting a concurrently changing base branch. The effective controls serialize merges into frequently changed modules through a merge queue, cap batch size, and rebase onto the latest base branch before merge, rather than capping how many agents contribute. ¬ Route review to where friction concentrates. Attention is already set by the repository (engagement ICC 0.77), yet agents auto-merge most PRs unreviewed (0.37 to 0.39, against 0.03 for humans). A better policy keeps automerge on low-friction paths and forces review where friction indicators run high, triggered by base-branch churn and historical conflict rate. ¬ Track a handful of repository indicators. Because the signal is convergent across seven constructs, a small dashboard of base-branch churn, conflict-replay rate, crossaccount review engagement, and the resolution-latency ICC trend gives early warning that no per-agent metric can. Our replication scripts already compute these. These recommendations have limits. Which agent a team picks still matters a little, since the conflict rate ranges from 15.4% to 32.3% across the five agents. Even so, vetting each agent on its own does not add up to a dependable repository, so a vendor’s claims about a single agent cannot replace measuring friction at the repository level. VII. T HREATS TO VALIDITY Construct validity. The concern is whether our proxies capture integration friction. Because friction is multi-faceted and no single proxy is decisive, we use seven measures and rely on their agreement; in particular, latency could reflect operator review cadence rather than codebase state, but the cadence-free conflict construct still carries the repository-level signal, which argues against a pure timing artefact. Two threats we cannot fully remove, and so report: three of the five agents act through operator accounts, leaving agent-to-agent interaction only partly observable, and AgenticFlict’s replay drops PRs it cannot process, biasing the surviving set toward conflict. Known GitHub-mining hazards [64], [65] we limit
by reading merge status from the curated data and treating repository heterogeneity as the estimand rather than as noise. Conclusion validity. Our claims rest on estimated variance components, which could be unstable under resampling, sensitive to distributional assumptions, or inflated by examining several constructs at once. We quantify sampling uncertainty with cluster-bootstrap and profile-likelihood intervals and, rather than seek a single significant result, require the signal to hold across all seven constructs and four activity cutoffs, a deliberately conservative criterion. The binary latent-scale ICCs additionally depend on the logistic π 2 /3 residual convention [53], [57]; linear-probability and log(1 + x) Gaussian fits corroborate them in direction and ranking, so the conclusions do not hinge on that choice. Internal validity. Because the design is observational, the surviving repository-level variance is a necessary signature, not causal proof: an unmeasured but stable repository attribute could in principle produce it. We control the two most plausible such attributes, codebase size and age, which remove almost none of the signal, and the within-repository agentversus-human baseline holds review culture and contribution norms constant. Attributes we did not observe, notably governance and application domain, remain uncontrolled; and because deliberation latency conditions on engaged PRs, we treat the selection-robust resolution latency as primary. External validity. By design the study covers open-source repositories and five agents [2], [40], so whether the signal extends to closed settings and other agents is a scope limitation we leave to future work. Our multi-agent measure reflects today’s multi-tool market. Were the field to consolidate onto a single orchestrator such as Claude Code, the RQ1 toolcount comparison would narrow, yet the repository-level result would stand, since it does not depend on tool count. VIII. C ONCLUSION Autonomous agents now merge code into shared repositories faster than anyone can supervise one contribution at a time. We ask whether the resulting difficulty is a property of the individual agent or of the repository it works in, render the measurable part as statistical non-reducibility, and test four hypotheses on more than 930,000 agent-authored pull requests and a matched human baseline. All four hold, and the decisive one is specificity. In the same repositories, agent contributions concentrate friction at the repository level close to twofold over human ones on the headline resolutionlatency measure (ICC 0.30 versus 0.16), a gap that holds under every control we apply. This is a necessary signature of emergence rather than a causal proof, but it moves the most plausible cause from the parts to the whole. AI-native software, then, calls for measurement and governance at the ecosystem level rather than one agent at a time. Future work. The clearest next steps are to move from this result to the causal test set out in the companion theory [30], to measure how shared understanding falls behind and how intent goes unrecorded alongside integration friction, and to link
friction to downstream harm beyond open-source repositories and today’s agents. DATA AVAILABILITY All analyses use publicly released datasets. The replication package, with the full pipeline, fixed seeds, dataset hashes, and an audit script re-deriving every figure, is archived on Zenodo at https://doi.org/10.5281/zenodo.20759752. R EFERENCES [1] H. Li, H. Zhang, and A. E. Hassan, “The rise of AI teammates in software engineering (SE) 3.0: How autonomous coding agents are reshaping software engineering,” arXiv:2507.15003, 2025, aIDev origin study; replication github.com/SAILResearch/AI Teammates in SE3. [2] ——, “AIDev: Studying AI coding agents on GitHub,” arXiv:2602.09185; dataset Hugging Face hao-li/AIDev; MSR 2026 Mining Challenge, 2026. [3] C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, and K. Narasimhan, “SWE-bench: Can language models resolve real-world GitHub issues?” in Proceedings of the Twelfth International Conference on Learning Representations (ICLR), 2024. [4] M.-A. Storey, “From technical debt to cognitive and intent debt: Rethinking software health in the age of AI,” ACM Queue, 2026, article id 3807966; preprint arXiv:2603.22106. [5] P. W. Anderson, “More is different,” Science, vol. 177, no. 4047, pp. 393–396, 1972. [6] W. Cunningham, “The WyCash portfolio management system,” in Addendum to the Proceedings of OOPSLA ’92. ACM, 1992, pp. 29–30. [7] P. Kruchten, R. L. Nord, and I. Ozkaya, “Technical debt: From metaphor to theory and practice,” IEEE Software, vol. 29, no. 6, pp. 18–21, 2012. [8] D. A. Tamburri, P. Kruchten, P. Lago, and H. van Vliet, “Social debt in software engineering: Insights from industry,” Journal of Internet Services and Applications, vol. 6, no. 1, pp. 10:1–10:17, 2015. [9] P. Naur, “Programming as theory building,” Microprocessing and Microprogramming, vol. 15, no. 5, pp. 253–261, 1985. [10] P. C. Rigby, Y. C. Zhu, S. M. Donadelli, and A. Mockus, “Quantifying and mitigating turnover-induced knowledge loss: Case studies of Chrome and a project at Avaya,” in Proceedings of the 38th International Conference on Software Engineering (ICSE), 2016, pp. 1006–1016. [11] J. H. Shen and A. Tamkin, “How AI impacts skill formation,” arXiv:2601.20245, 2026, preprint; peer-review status to confirm. [12] M. E. Conway, “How do committees invent?” Datamation, vol. 14, no. 4, pp. 28–31, 1968. [13] A. MacCormack, J. Rusnak, and C. Y. Baldwin, “Exploring the duality between product and organizational architectures: A test of the mirroring hypothesis,” Research Policy, vol. 41, no. 8, pp. 1309–1324, 2012. [14] K. Manikas and K. M. Hansen, “Software ecosystems – a systematic literature review,” Journal of Systems and Software, vol. 86, no. 5, pp. 1294–1306, 2013. [15] M. Lungu, R. Robbes, and M. Lanza, “Recovering inter-project dependencies in software ecosystems,” in Proceedings of the 25th IEEE/ACM International Conference on Automated Software Engineering (ASE), 2010, pp. 309–312. [16] C. Bogart, C. Kästner, J. Herbsleb, and F. Thung, “When and how to make breaking changes: Policies and practices in 18 open source software ecosystems,” ACM Transactions on Software Engineering and Methodology, vol. 30, no. 4, pp. 42:1–42:56, 2021. [17] A. Decan, T. Mens, and P. Grosjean, “An empirical comparison of dependency network evolution in seven software packaging ecosystems,” Empirical Software Engineering, vol. 24, no. 1, pp. 381–416, 2019. [18] M. Zimmermann, C.-A. Staicu, C. Tenny, and M. Pradel, “Small world with high risks: A study of security threats in the npm ecosystem,” in 28th USENIX Security Symposium, 2019, pp. 995–1010. [19] A. Zerouali, T. Mens, J. Gonzalez-Barahona, A. Decan, E. Constantinou, and G. Robles, “A formal framework for measuring technical lag in component repositories – and its application to npm,” Journal of Software: Evolution and Process, vol. 31, no. 8, p. e2157, 2019. [20] M. Cataldo, J. D. Herbsleb, and K. M. Carley, “Socio-technical congruence: A framework for assessing the impact of technical and work dependencies on software development productivity,” in Proceedings of the 2nd ACM-IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM), 2008, pp. 2–11.
[21] J. D. Herbsleb and A. Mockus, “An empirical study of speed and communication in globally distributed software development,” IEEE Transactions on Software Engineering, vol. 29, no. 6, pp. 481–494, 2003. [22] E. P. Hoel, L. Albantakis, and G. Tononi, “Quantifying causal emergence shows that macro can beat micro,” Proceedings of the National Academy of Sciences, vol. 110, no. 49, pp. 19 790–19 795, 2013. [23] F. E. Rosas, P. A. M. Mediano, H. J. Jensen, A. K. Seth, A. B. Barrett, R. L. Carhart-Harris, and D. Bor, “Reconciling emergences: An information-theoretic approach to identify causal emergence in multivariate data,” PLOS Computational Biology, vol. 16, no. 12, p. e1008289, 2020. [24] P. A. M. Mediano, F. E. Rosas, A. I. Luppi, H. J. Jensen, A. K. Seth, A. B. Barrett, R. L. Carhart-Harris, and D. Bor, “Greater than the parts: A review of the information decomposition approach to causal emergence,” Philosophical Transactions of the Royal Society A, vol. 380, no. 2227, p. 20210246, 2022. [25] L. Barnett and A. K. Seth, “Dynamical independence: Discovering emergent macroscopic processes in complex dynamical systems,” Physical Review E, vol. 108, p. 014304, 2023. [26] G. J. P. Link and M. Germonprez, “Understanding open source communities as complex adaptive systems: A case of the R project community,” in Americas Conference on Information Systems (AMCIS), 2016. [27] T. Mens, “Software ecosystem evolution: It’s complex!” in BENEVOL, 2016, non-archival extended abstract. [28] G. Vial, “A complex adaptive systems perspective of software reuse in the digital age: An agenda for IS research,” Information Systems Research, vol. 34, no. 4, pp. 1728–1743, 2023. [29] T. Mens, M. Claes, P. Grosjean, and A. Serebrenik, “Studying evolving software ecosystems based on ecological models,” in Evolving Software Systems. Springer, 2014, pp. 297–326. [30] D. Russo, “More is different: Toward a theory of emergence in AI-native software ecosystems,” arXiv:2604.19827, 2026. [31] J. Wei, Y. Tay, R. Bommasani, C. Raffel, B. Zoph, S. Borgeaud, D. Yogatama, M. Bosma, D. Zhou, D. Metzler, E. H. Chi, T. Hashimoto, O. Vinyals, P. Liang, J. Dean, and W. Fedus, “Emergent abilities of large language models,” Transactions on Machine Learning Research, 2022, arXiv:2206.07682. [32] R. Schaeffer, B. Miranda, and S. Koyejo, “Are emergent abilities of large language models a mirage?” in Advances in Neural Information Processing Systems (NeurIPS), 2023, outstanding Paper; arXiv:2304.15004. [33] A. F. Ashery, L. M. Aiello, and A. Baronchelli, “Emergent social conventions and collective bias in LLM populations,” Science Advances, vol. 11, no. 20, p. eadu9368, 2025. [34] S. Erisken, T. Gothard, M. Leitgab, and R. Potham, “MAEBE: Multiagent emergent behavior framework,” arXiv:2506.03053, 2025. [35] A. F. Ashery, L. M. Aiello, R. Pastor-Satorras, and A. Baronchelli, “Group size effects and collective misalignment in LLM multi-agent systems,” arXiv:2510.22422, 2025. [36] M. Cemri, M. Z. Pan, S. Yang, L. A. Agrawal, B. Chopra, R. Tiwari, K. Keutzer, A. Parameswaran, D. Klein, K. Ramchandran, M. Zaharia, J. E. Gonzalez, and I. Stoica, “Why do multi-agent LLM systems fail?” arXiv:2503.13657, 2025. [37] A. E. Hassan, H. Li, D. Lin, B. Adams, T.-H. Chen, Y. Kashiwa, and D. Qiu, “Agentic software engineering: Foundational pillars and a research roadmap,” arXiv:2509.06216, 2025. [38] R. Hoda, “Toward agentic software engineering beyond code: Framing vision, values, and vocabulary,” in Proceedings of the 48th International Conference on Software Engineering (ICSE-Companion), 2026. [39] A. Roychoudhury, C. Pasareanu, M. Pradel, and B. Ray, “Agentic AI software engineers: Programming with trust,” arXiv:2502.13767, 2025. [40] D. Ogenrwot and J. Businge, “AgenticFlict: A large-scale dataset of merge conflicts in AI coding agent pull requests on GitHub,” arXiv:2604.03551, 2026. [41] GitClear, “AI copilot code quality: 2025 data suggests downward pressure on code quality,” GitClear technical report, 2025. [42] M. Wessel, B. M. de Souza, I. Steinmacher, I. S. Wiese, I. Polato, A. P. Chaves, and M. A. Gerosa, “The power of bots: Characterizing and understanding bots in OSS projects,” Proceedings of the ACM on Human-Computer Interaction, vol. 2, no. CSCW, pp. 182:1–182:19, 2018. [43] M. Wessel, I. Wiese, I. Steinmacher, and M. A. Gerosa, “Don’t disturb me: Challenges of interacting with software bots on open source software projects,” Proceedings of the ACM on Human-Computer Interaction, vol. 5, no. CSCW2, p. Article 332, 2021.
[44] M. Wessel, A. Serebrenik, I. Wiese, I. Steinmacher, and M. A. Gerosa, “Quality gatekeepers: Investigating the effects of code review bots on pull request activities,” Empirical Software Engineering, vol. 27, no. 5, p. 108, 2022. [45] S. Peng, E. Kalliamvakou, P. Cihon, and M. Demirer, “The impact of AI on developer productivity: Evidence from GitHub Copilot,” arXiv:2302.06590, 2023. [46] Z. Cui, M. Demirer, S. Jaffe, L. Musolff, S. Peng, and T. Salz, “The effects of generative AI on high-skilled work: Evidence from three field experiments with software developers,” Management Science, 2026. [47] J. Becker, N. Rush, B. Barnes, and D. Rein, “Measuring the impact of early-2025 AI on experienced open-source developer productivity,” arXiv:2507.09089, 2025. [48] K.-J. Stol and B. Fitzgerald, “The ABC of software engineering research,” ACM Transactions on Software Engineering and Methodology, vol. 27, no. 3, pp. 11:1–11:51, 2018. [49] C. Wohlin, P. Runeson, M. Höst, M. C. Ohlsson, B. Regnell, and A. Wesslén, Experimentation in Software Engineering. Springer, 2012. [50] S. W. Raudenbush and A. S. Bryk, Hierarchical Linear Models: Applications and Data Analysis Methods, 2nd ed. Sage, 2002. [51] A. Gelman and J. Hill, Data Analysis Using Regression and Multilevel/Hierarchical Models. Cambridge University Press, 2007. [52] T. A. B. Snijders and R. J. Bosker, Multilevel Analysis: An Introduction to Basic and Advanced Multilevel Modeling, 2nd ed. Sage, 2012. [53] H. Goldstein, W. Browne, and J. Rasbash, “Partitioning variation in multilevel models,” Understanding Statistics, vol. 1, no. 4, pp. 223–231, 2002. [54] X. Zhang, Y. Yu, T. Wang, A. Rastogi, and H. Wang, “Pull request latency explained: An empirical overview,” Empirical Software Engineering, vol. 27, no. 6, p. 126, 2022. [55] X. Zhang, Y. Yu, G. Gousios, and A. Rastogi, “Pull request decisions explained: An empirical overview,” IEEE Transactions on Software Engineering, vol. 49, no. 2, pp. 849–871, 2023. [56] J. C. Flournoy, C. S. Lee, M. Wu, and C. M. Hicks, “No silver bullets: Why understanding software cycle time is messy, not magic,” Empirical Software Engineering, vol. 30, no. 6, 2025. [57] S. Nakagawa, P. C. D. Johnson, and H. Schielzeth, “The coefficient of determination R2 and intra-class correlation coefficient from generalized linear mixed-effects models revisited and expanded,” Journal of the Royal Society Interface, vol. 14, no. 134, p. 20170213, 2017. [58] X. A. Harrison, “Using observation-level random effects to model overdispersion in count data in ecology and evolution,” PeerJ, vol. 2, p. e616, 2014. [59] P. McCullagh and J. A. Nelder, Generalized Linear Models, 2nd ed. Chapman and Hall, 1989. [60] S. Nakagawa and H. Schielzeth, “A general and simple method for obtaining R2 from generalized linear mixed-effects models,” Methods in Ecology and Evolution, vol. 4, no. 2, pp. 133–142, 2013. [61] N. M. Laird and J. H. Ware, “Random-effects models for longitudinal data,” Biometrics, vol. 38, no. 4, pp. 963–974, 1982. [62] S. Seabold and J. Perktold, “statsmodels: Econometric and statistical modeling with Python,” in Proceedings of the 9th Python in Science Conference (SciPy), 2010, pp. 92–96. [63] B. Efron and R. J. Tibshirani, An Introduction to the Bootstrap. Chapman and Hall, 1993. [64] E. Kalliamvakou, G. Gousios, K. Blincoe, L. Singer, D. M. German, and D. Damian, “The promises and perils of mining GitHub,” Empirical Software Engineering, vol. 21, no. 5, pp. 2035–2071, 2016. [65] M. Nagappan, T. Zimmermann, and C. Bird, “Diversity in software engineering research,” in Proceedings of the 9th Joint Meeting on Foundations of Software Engineering (ESEC/FSE), 2013, pp. 466–476.