Imagine a team where every developer is brilliant in isolation. Each one writes code that passes its own tests, ships features that work in demos, and never breaks a build on their own machine. Now imagine that after a year of this, the codebase is a tangled mess — duplicated logic everywhere, inconsistent naming, modules that barely fit together. Nobody did anything wrong individually. But collectively, the repository is suffering.

That, in a nutshell, is the problem Daniel Russo's paper raises about AI coding agents. Today's autonomous agents — the ones opening pull requests, fixing bugs, and merging code into shared repositories — are evaluated the way we've always evaluated software components: one at a time, on isolated benchmark tasks. Did the agent solve the ticket? Did its tests pass? Great, ship it.

But Russo argues this misses the real story. When dozens or hundreds of agents independently contribute to the same repository, problems emerge that no single contribution is responsible for. He calls this integration friction — the accumulating cost of stitching together work from many autonomous contributors who each optimized for their own local success.

The key insight is a shift in where we measure quality:

• Old model: evaluate the agent. "Is this AI a good coder?"
• New model: evaluate the repository. "Is this codebase still healthy after the AI has been working in it?"

This matters because agentic coding is no longer a thought experiment. Tools like Claude Code, Cursor, Devin, and GitHub Copilot's agent mode are actively merging code into production repositories. The benchmarks we use to decide which agents to trust (SWE-bench and its cousins) treat each task as independent. They don't capture what happens when an agent's stylistic choices clash with the conventions of the surrounding code, or when ten agents independently re-implement nearly the same helper function, or when subtle semantic drift accumulates over hundreds of merges.

Russo's framing reframes the governance question, too. If the unit of risk is the repository, then mitigation belongs at the repository level: shared conventions enforced by tooling, architectural guardrails, automated detection of duplication and drift, and merge policies that account for who (or what) is contributing. The agent vendor can't fix this from the outside; it requires the repository owner to set the rules of the ecosystem.

It's a useful corrective to the dominant narrative around AI coding. We've been asking "how smart is this agent?" when the harder, more important question is "what happens to a codebase that lives with these agents for a year?"