For Coding Agents, the Repository Matters

arXiv:2606.28235 · cs.SE, cs.AI · Submitted 2026-06-26 · Read on arXiv

Listen

Transcript

Introduction to the show: ident: AI Radio. Generated commentary on the latest Artificial Intelligence papers.

Tom: We're looking at the paper: "For Coding Agents, the Repository Matters".

Jane: Here's the gist of the paper. The gist 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.

Tom: How it works The study investigates integration friction, defined as "the effort of integrating a contribution into a codebase that other contributors are concurrently changing," across more than 930,000 agent-authored pull requests to determine if this problem belongs to the individual agent or the repository where it accumulates <ref:2606.28235#pg2>.

Jane: The researchers used multilevel models to partition the variation in friction into components attributable to individual contributions and those that remain attached to the repository, which is operationalized as the "repository-level variance partition coefficient" or ICC <ref:2606.28235#pg5>.

Tom: A high ICC indicates that a large share of the total variation belongs to the repository rather than individual parts <ref:2606.28235#pg9>.

Title and authors: Tom: Let's talk about the core findings now. The paper shows that about half of this repository-level friction survives when you account for things like how many agents there are or how big the contribution is, which is significant because it holds up even after doing some full controls.

Jane: That sounds pretty substantial. So, what's the direct comparison they made to show why this isn't just a generic software problem?

Lu: They found that agent-authored contributions concentrate this repository-level friction roughly twice as much than human ones, with an intraclass correlation of zero point three zero versus zero point one six for humans, which they say is specific to agent-authored software >

Meng: That concentration is a key finding because it suggests the issue isn't just that agents are busy; it points to something specific about how AI generated code interacts with evolving repositories.

Lalam: And they also found that having more distinct agents actually weakens the residual friction instead of amplifying it, which means the friction lives in the evolving codebase itself, not just in how many agents are present >

The paper's summary: Tom: So, what's the big picture here? It seems they are arguing that we need to shift our focus from governing individual agents to governing the whole ecosystem of AI-native software.

Jane: That makes sense, especially when you consider how quickly code is arriving—faster than teams can absorb it—which is a symptom they mentioned in their related work section >

Lu: They test four hypotheses, and one of the big ones is that repository-level integration friction isn't reducible to just the properties of individual agents and their contributions >

Meng: That’s interesting because it suggests that even if you fix an agent's training or prompt, you might not solve the problem if the repository structure itself is causing the drag >

Lalam: And they specifically test whether this non-reducibility is a property of agent-authored software in particular, rather than being true for general repositories >

The paper's improvements: Tom: The paper suggests four specific practices to move governance to the repository level. They propose assessing agents inside the target repository, governing change tempo instead of headcount, routing reviews where friction concentrates, and tracking a handful of indicators >

Jane: So they aren't just diagnosing a problem; they’re telling us how to actually fix it in practice. What does governing change tempo mean practically for a team?

Lu: It means serializing merges into frequently changed modules through a merge queue, capping the batch size, and rebasing onto the latest base branch before merging instead of just capping how many agents contribute >

Meng: That sounds like throttling the input rate to manage the repository's state rather than just managing the number of contributors >

Lalam: And they suggest routing review to where friction concentrates by keeping automerge on low-friction paths and forcing human review when friction indicators run high, triggered by base-branch churn and historical conflict rate >

Conclusion: Tom: So, the overall implication is that the unit of governance needs to move from the agent to the repository because AI-native software calls for measurement and governance at the ecosystem level rather than one agent at a time, based on this study on "For Coding Agents, the Repository Matters" >

Jane: It seems like they're really hammering home that we need to stop treating these friction symptoms as separate problems with separate fixes, because they all follow from this one mechanism of non-reducible concentration at the repository level >

Lu: And in their future work, they plan to move from this result to a causal test set out in the companion theory, measuring how shared understanding falls behind and how intent goes unrecorded alongside integration friction >

Meng: I'm curious about what that next step means for us at scale. Can we actually measure that intent?

Lalam: They are also looking at linking friction to downstream harm beyond open-source repositories and today's agents, which suggests they want to see the broader impact of this concentration >

Daniel Russo

Department of Computer Science, Aalborg University

cs.SE, cs.AI

Submitted: 2026-06-26

Updated: 2026-10-20

Comments: 11 pages, 2 figures, 3 tables, followed by a 4-page supplement (Tables S1-S4, Figures S1-S2). v2: substantially revised and retitled; v1 was titled "Govern the Repository, Not the Agent: Measuring Ecosystem-Level Risk in AI-Native Software". Revised research questions, analysis and framing; replication package on Zenodo (doi:10.5281/zenodo.23504056)

Code: https://github.com/SAILResearch/AI

License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/

The gist: The gist 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

Key concepts

Integration Friction: This is the effort required to integrate a new contribution into a codebase while other contributors are simultaneously making changes. The research found this friction is largely an issue of the repository's state, not just individual agent contributions.
Repository-Level Variance Partition Coefficient (ICC): This coefficient measures how much of the total integration friction in a repository is due to the repository itself versus individual parts. A high ICC means most of the problem lies with the overall codebase environment rather than specific agents.
Base Branch Churn: This refers to how frequently the main or base branch of a project is modified while a pull request is being developed. The research hypothesized that this churn, not just the number of agents, drives integration friction in an ecosystem.

Terminology

Benchmark — 1× in this paper · explained in 2 episodes

Summary

The gist 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.

How it works

The study investigates integration friction, defined as the effort of integrating a contribution into a codebase that other contributors are concurrently changing, across more than 930,000 agent-authored pull requests to determine if this problem belongs to the individual agent or the repository where it accumulates <ref:2606.28235#pg2>. The researchers used multilevel models to partition the variation in friction into components attributable to individual contributions and those that remain attached to the repository, which is operationalized as the repository-level variance partition coefficient or ICC <ref:2606.28235#pg5>. A high ICC indicates that a large share of the total variation belongs to the repository rather than individual parts <ref:2606.28235#pg9>.

Key Hypotheses Tested

The research tests four hypotheses regarding this phenomenon, which are stated so that the data could falsify them <ref:2606.28235#pg2>. These hypotheses include:

H1 (coupling): If an emergent ecosystem exists, agents do not act in isolation, and interaction with humans and automation is pervasive <ref:2606.28235#pg5>.
H2 (locus): "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" <ref:2606.28235#pg5>.
H3 (non-reducibility): Repository-level integration friction is not reducible to the properties of individual agents and contributions <ref:2606.28235#pg2>.
H4 (specificity): The non-reducibility is a property of agentauthored software in particular, not of repositories in general <ref:2606.28235#pg2>.

Empirical Findings on Friction

The analysis showed that about half does, and it survives full controls regarding the repository-level friction <ref:2606.28235#pg2>. Specifically, agent-authored contributions concentrate this repository-level friction roughly twice as much as human ones (intraclass correlation 0.30 versus 0.16) <ref:2606.28235#pg2>. This concentration is specific to agent-authored software <ref:2606.28235#pg2>. Furthermore, More distinct agents weaken the residual rather than amplifying it because friction lives in the evolving codebase rather than in agent count <ref:2606.28235#pg2>.

The Human Baseline Comparison

To test H4, a matched human baseline was established by comparing agent-authored pull requests against human-authored ones within the same repositories <ref:2606.28235#pg2>. The comparison showed that the repository-level ICC for agent contributions stands above the human ICC on every construct <ref:2606.28235#pg2>. The gap is largest for the latency constructs, with a difference of +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 <ref:2606.28235#pg2>. This gap is specific to agent-authored software <ref:2606.28235#pg2>.

Governance Implications

The findings suggest that the unit of governance therefore moves from the agent to the repository <ref:2606.28235#pg2>. The paper proposes four practices anchored to these results, including:

- Assess agents inside the target repository.

- Govern change tempo rather than headcount.

- Route review to where friction concentrates.

- Track a handful of repository indicators.

These recommendations are based on the finding that 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 <ref:2606.28235#pg2>. The final conclusion is that AI-native software, then, calls for measurement and governance at the ecosystem level rather than one agent at a time <ref:2606.28235#pg2>.

Future Work

The paper suggests that "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" <ref:2606.28235#pg2>. The capability of individual agents is a necessary but not sufficient condition for a dependable repository <ref:2606.28235#pg2>.

Threats to Validity

The study acknowledges threats such as construct validity, where latency could reflect operator review cadence rather than codebase state, but the cadence-free conflict construct still carries the repository-level signal <ref:2606.28235#pg2>. Another threat is that three of the five agents act through operator accounts, leaving agent-to-agent interaction only partly observable <ref:2606.28235#pg2>. The conclusion's robustness is supported by requiring the signal to hold across all seven constructs and four activity cutoffs <ref:2606.28235#pg2>.

Conclusion Validity

The claims are based on estimated variance components, which could be unstable under resampling or sensitive to distributional assumptions <ref:2606.28235#pg2>. The authors address this by quantifying sampling uncertainty with cluster-bootstrap and profile-likelihood intervals <ref:2606.28235#pg2>. The overall conclusion is that The gap holds under codebase size, age, task shape, process maturity, and merge path <ref:2606.28235#pg2>.

External Validity

The study's scope is limited by the fact that it covers open-source repositories and five agents [2], so whether the signal extends to closed settings and other agents is a scope limitation we leave to future work <ref:2606.28235#pg2>. The multi-agent measure reflects today’s multi-tool market <ref:2606.28235#pg2>.

References

[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 <ref:2606.28235#pg2>.

[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 <ref:2606.28235#pg2>.

[5] P. W. Anderson, “More is different,” Science, vol. 177, no. 4047, pp. 393–396, 1972 <ref:2606.28235#pg2>.

[9] P. Naur, “Programming as theory building,” Microprocessing and Microprogramming, vol. 15, no. 5, pp. 253–261, 1985 <ref:2606.28235#pg2>.

[30] D. Russo, “More is different: Toward a theory of emergence in AI-native software ecosystems,” arXiv:2604.19827, 2026 <ref:2606.28235#pg2>.

[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 <ref:2606.28235#pg2>.

[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 <ref:2606.28235#pg2>.

[50] S. W. Raudenbush and A. S. Bryk, Hierarchical Linear Models: Applications and Data Analysis Methods, 2nd ed.

Improvements for AI systems

Assess agents inside target repositories by running them on a feature branch for a fixed window to read repository-level friction as an acceptance signal and re-estimating on a rolling basis to detect drift before merge permissions widen. This moves governance from the agent to the repository, as a score earned on detached benchmarks does not predict behaviour in the target repository.
Govern change tempo rather than headcount by serializing merges into frequently changed modules through a merge queue, capping batch size, and rebasing onto the latest base branch before merge instead of capping how many agents contribute. This addresses H2: Friction tracks the repository, not the number of agents because conflict is flat across the number of agents.
Route review to where friction concentrates by keeping automerge on low-friction paths and forcing human review where friction indicators run high, triggered by base-branch churn and historical conflict rate. This utilizes the finding that Attention is already set by the repository (engagement ICC 0.77).
Track a handful of repository indicators by monitoring base-branch churn, conflict replay rate, crossaccount review engagement, and resolution-latency ICC trend to provide early warning that no per-agent metric can. This leverages the finding that the signal is convergent across seven constructs.