Cross-Repository Coordination Is the Ceiling Your Coding Agents Will Hit Next

Most enterprise teams measure coding agent success by whether the agent closes a ticket in a single repository. That is a reasonable starting point, but it is not where real software ecosystems live. Production systems are distributed across services, shared libraries, API clients, and platform tooling, and a meaningful proportion of changes require coordinated edits across several of those codebases at once. When agents operate at that level, the failure modes are qualitatively different from anything a single-repo benchmark can surface.

Companion piece to our broader work on coding agent limitations in enterprise codebases. See Why Coding Agents Fail at Real Migration Work for an examination of benchmark blindness and how it distorts technical debt strategy.

What WideSWE Actually Measures

The WideSWE benchmark was constructed specifically to evaluate this cross-repository coordination problem. Researchers mined 103 real software ecosystems to produce 120 tasks drawn from genuine GitHub history, split evenly between bug fixes and feature implementations. Each task requires changes across multiple repositories to be considered complete (Wang et al., HuggingFace 2026).

The benchmark derives prompts from real issues and pull requests, which means agents are working with the same ambiguous, human-authored context that engineers encounter in practice. Hidden tests are adapted to allow diverse correct implementations while preserving the behavioural constraints that matter. That design choice is significant: it means a passing score reflects genuine coordination, not pattern-matching to a narrow expected output.

Across seven agent configurations, full task success ranged from 10.83% to 42.50%. The highest-performing configuration paired Codex CLI with GPT-5.6-sol. Even that ceiling sits below a coin flip for tasks that any senior engineer would consider routine.

The Three Failure Modes That Matter

The trajectory analysis in WideSWE identifies three distinct ways agents fail on cross-repository tasks. Agents either fail to identify that a second repository needs to change at all, recognise the need but leave the work incomplete, or make changes across the required repositories without actually satisfying the request. Each failure mode has a different root cause and a different remediation path.

The first failure mode is a context and planning problem. The agent's representation of the task does not include enough cross-repository signal to trigger the correct set of edits. This is structurally related to the repository indexing limitations we have written about elsewhere: agents working with incomplete or stale context cannot reason about dependencies they cannot see.

The second and third failure modes are execution and verification problems. The agent understands what needs to change but cannot sustain coherent progress across multiple working directories, or it completes the mechanical edits without validating that the combined system behaviour is correct. Both failures are harder to address through prompt engineering alone.

Independent vs. Joint Execution

WideSWE directly compares two execution strategies under identical prompts: independent execution, where the agent works on one repository at a time, and joint execution, where it operates across repositories simultaneously (Wang et al., HuggingFace 2026).

Independent execution is more effective at recovering omitted work. When an agent finishes one repository and then re-reads the task, it is more likely to notice that a second repository was not touched. That is a genuine and measurable benefit for the first failure mode described above.

Joint execution performs better when the agent needs information from one repository to guide implementation in another. Interface contracts, shared type definitions, and API surface changes all fall into this category. The implication is that neither strategy dominates universally, and the choice should be driven by the dependency structure of the specific task.

What This Means for Autonomy Decisions

Engineering leaders expanding agent autonomy often make the mistake of treating single-repo benchmark scores as a proxy for production readiness across their full system. WideSWE results make the gap between those two things concrete. A configuration that resolves 60% of single-repo issues may succeed on fewer than 43% of cross-repository tasks, and the failure rate on the harder tasks is not evenly distributed across task types.

The practical implication is that autonomy decisions should be scoped to task topology, not just task complexity. An agent can be trusted to operate autonomously on self-contained service changes while still requiring human review on anything that touches a shared library or a cross-service interface. That is not a limitation of the technology in general; it is a calibration that reflects where current evaluation evidence actually sits.

Teams that do not make this distinction will eventually approve an agent-generated change that satisfies the tests in one repository while silently breaking a dependent system. The WideSWE results suggest that outcome is not an edge case at current capability levels.

Building Evaluation Infrastructure for Cross-Repository Work

The evaluation gap is as important as the capability gap. Most internal agent evaluation pipelines are built around single-repository test suites because that is the shape of the tooling that existed when those pipelines were designed. Extending them to cross-repository scenarios requires orchestrating test execution across multiple codebases, managing inter-repository dependency resolution in the test environment, and defining success criteria that span system boundaries.

That infrastructure investment is non-trivial, but it is the only way to generate the signal needed to make defensible autonomy decisions. Without it, engineering leaders are extrapolating from benchmarks that were not designed to measure the failure modes they are most likely to encounter as agent scope expands.

The WideSWE benchmark itself is a useful reference point for calibrating internal evaluation design. The task construction methodology, particularly the approach to adapting hidden tests for behavioural correctness rather than implementation specifics, is directly applicable to teams building their own evaluation corpora from production change history.