Benchmarks for coding agents ask one question. Did the tests pass? A new benchmark called RepoReuse asks a second. When the agent needed something the codebase already had, did it call that code or write its own? The two answers come apart badly.
The setup is closer to real work than most. An agent gets a mature open-source Python library and a requirement, then four more requirements in sequence, each building on the last. The workspace keeps whatever the agent wrote, so by the final turn it is working in a codebase that is half its own output. Each turn starts a fresh session with no memory of the last, which is roughly how these tools run in anger. The researchers then read what it submitted and checked whether it called the functions its task depended on.
Two failures turned up, with different causes.
The first is that agents stop looking around. On the first turn they read more than four-fifths of the repository code their task depended on; by the fifth, about a third. Exploration collapses as the workspace fills with the agent's own material.
The second is odder. On code the agent had written itself, it read essentially all of it every turn and still called a shrinking share.
"The gap therefore lies in the decision to build on the code that was found, not in finding it."
A bypassed function doesn't vanish; it becomes a second copy. The benchmark counts one when a new file skips an existing function but rewrites most of its internals. The share of task chains carrying at least one such duplicate climbed from roughly one in seven at the first turn to half by the fifth, while pass rates barely moved.
"Agents can solve every task and still degrade the codebase and pass rates cannot tell the difference."
Then the researchers changed what the agent was told about its earlier work. A short index of what it had already built, listing names, signatures and return values, more than doubled how often it built on that work. Handing over the complete source of those files did no better than saying nothing at all. The authors read this as a problem of disposition rather than information, and they are straight about their design's limit, since the index also told the agent to reuse and the source dump did not, so two things changed at once and the study cannot separate them.
An agent's context is not a cumulative good. Anyone whose instinct is to fix an agent that ignores the codebase by pasting more of it into the prompt should sit with that.
On this evidence, the number to watch is duplication across an agent's successive changes, not its acceptance rate. A clone detector over a week of agent commits costs almost nothing and catches what green tests cannot. The same goes for vendor claims, where a pass rate says nothing about what the agent left behind, and the tool topping a leaderboard may be the one filling your repository with parallel copies of the same function.
This will get over-read, because duplication is not always wrong, and a shared helper dragged into unrelated callers can be worse than two honest copies.
The paper's own stated limit is narrower. It runs on a handful of pure-Python libraries over short chains, so nobody should assume the same curve in a large Java monolith or a much longer job. What travels is the shape of the problem. The code gets worse in a way the scoreboard is built not to notice, and it gets worse faster than anyone is reading it.
Sources
- Ma, D., Wang, S., Huang, X. et al., "Do Coding Agents Reuse Existing Code or Reinvent the Wheel?" — https://arxiv.org/abs/2609.35357