The Monorepo Versus Polyrepo Debate Came Back Because Agents Cannot See Across a Boundary
This argument should have been settled years ago. It was being compared to the Vim and Emacs wars back in 2024, and then in the space of about six months it came back everywhere. A vendor relitigated it for the agent era, a benchmark firm published pull request cycle time data across hundreds of organisations, and half the platform engineering threads worth reading found their way back to it.
Something dragged it out of retirement, and it is not really about where files live.
What actually changed
Agents optimise for full codebase context, atomic changes and a connected dependency graph. A monorepo happens to provide all three by accident of layout, so the moment agents started writing a large share of the code, the monorepo looked as though it had won on a technicality.
Except it has not, and the data does not support a clean verdict. Faros benchmark analysis from March 2026 across many organisations found monorepo teams show markedly more variable pull request cycle times than polyrepo teams, with heavy tails at the 90th percentile where some organisations blow past 10 days on worst case pull requests. Well engineered monorepo infrastructure can match polyrepo performance, the infrastructure has to keep evolving with repository scale, and when it lags the cycle time absorbs the difference.
So a monorepo is a bet that you will keep funding that evolution indefinitely. Polyrepos buy autonomy instead, with each repository getting its own pipeline, release cadence and ownership boundary that maps onto a team.
The more interesting reading is that the debate is measuring the wrong thing. The variable that decides whether agents work is not code location. It is whether the question of what depends on this is answerable at all, and infrastructure never got a vote on that.
Why the answer is missing in both layouts
In a polyrepo, the boundary is obvious. A parser resolves references it can reach on the filesystem in front of it, so when your billing service publishes an event that a reporting service consumes from another repository, there is no edge to parse. The two ends were never in the same working directory. You can check out both and merge the graphs and you still have two correct graphs sitting next to each other with nothing across the seam, because the seam is a runtime contract rather than a syntactic reference.
In a monorepo, everything is technically reachable, and that turns out to help less than people expect. A monorepo of hundreds of millions of lines does not fit in any context window that exists or is planned. At a conservative 1,000 tokens per file, 10 million files is roughly 10 billion tokens, and a 1 million token window holds 0.01% of that. Reachability without a way to select the relevant fraction is not much better than unreachability.
Both layouts leave the same question unanswered. What promises does this code make to the rest of the organisation, and which of those does my change break.
The scale this now runs at
Stripe’s internal agent system was merging well over 1,000 AI written pull requests a week as of February 2026, against a monorepo of hundreds of millions of lines. Razorpay’s internal platform reports roughly 1,000 pull requests created a week automatically, around 100 merged with zero human review, and 1 in 3 reviews completed end to end without a human comment.
Neither of those is an experiment. That is throughput arriving at a review capacity that did not grow, inside organisations sophisticated enough to have already built everything else. Neither layout choice changes the arithmetic of it.
The research picked up the same gap. A cross repository benchmark released in 2026 exists specifically because agents that perform well on single repository bug fixing do not carry that performance across repository boundaries, and it was built from issues whose resolution genuinely requires information from a linked external repository.
The meta layer is what actually resolves it
The pattern people are converging on is a layer above the repository, and that framing looks right. The monorepo versus polyrepo debate assumed a human audience. When the audience is a machine that is fast, capable and amnesiac, the question becomes whether it knows where it is.
ByteBell is a verification layer generated on top of a codebase of any size below 10 million files, and it is layout independent by construction.
Cheap open source models read every file once at indexing time. An agent detects the boundaries of each language element, stores them separately, then analyses each one in the context of its file, its module, its repository and across every repository we have indexed. That last clause is where the seam disappears, because the analysis is not scoped to a checkout. The model is asked what depends on this elsewhere in the organisation and answers from the other indexed repositories rather than from what a parser could reach.
For each file the layer stores what it does, why it exists in business terms, what users lose if it fails, the capabilities it provides, its edge cases, the contracts it provides, its preconditions, and the places where the behaviour is genuinely undecided. Everything in plain English with the file and the line attached.
What that produces on a real question
Asked which files must change if the shape of a writer contract changes, the layer returned 32 impacted files across 4 repositories in 4 minutes 9 seconds. It named the 3 teams involved. It marked one file as a shared schema, one as will break, one as needs review, one as new work, and one as ask first because it belongs to billing. It also listed 2 things it would not guess at, namely whether exports should count against the metered plan and whether row limits are enforced for each workspace separately.
That run cost 30 for the same work by brute force. A monorepo does not produce that answer for free, and a polyrepo does not prevent it.
Then it checks rather than describes
Because the layer holds what each file promised, a change gets compared against that promise. We trace what it touches, generate tests for it, run them, then review each modified file against its indexed base rather than against what the diff claims it changed. Collateral damage is checked across the other repositories reading the same helper before anyone approves. A full pass came to 87,001 tokens at $0.11.
Indexing runs about $13 per 1,000 files, once, with only what changes re-derived on each commit. Accuracy of code holds above 93% while token spend drops by roughly 80%, because a model reading pre-established meaning never runs the chain of inference that establishes it.
What to tell a platform team
Choose the layout that fits your ownership model and your release cadence, because those are the things it genuinely affects. If teams need independent deploy cycles, take the polyrepo. If you have the appetite to keep funding build infrastructure forever, the monorepo has real advantages.
Then solve the dependency question separately, because neither choice solves it. Migrating a hundred repositories into one is an expensive way to discover that a 10 billion token monorepo is still not readable by anything.
The honest limitation
The layer only knows about repositories that have been indexed. A dependency into a service nobody added is invisible to us in exactly the way it is invisible to a parser, and there is no clever inference that fixes it. Coverage is a decision somebody has to make deliberately.
A derived index can also be wrong about a relationship in ways a parser cannot, which is why every claim carries a file and a line, and why there is a window after a push where a claim can lag the branch. We also do not cover every language, and Mojo is not indexed today.
This is what ByteBell builds
The test that settles it for your own team costs an afternoon. Take a recent change in one repository and ask what it breaks elsewhere. If the honest answer is that somebody would have to go and look, your layout was never the variable, and moving the files will not change it.
ByteBell is the verifiable context layer for code. We run the LLM compiler pattern, a one time pass where a model reads every file and lowers it into a verifiable code IR capturing purpose, business context and cross repository relationships, on your own infrastructure through Docker, with your source never leaving your environment. Every engineer, on any copilot, queries the same representation through a single MCP url, and every agent edit is checked against it before it lands, using per file SHA-256 diffing so only what actually changed gets examined again. Across 46 Kubernetes ecosystem repositories and 150,000 files we measured roughly 10% higher accuracy at 70% lower cost, on about a fifth of the tokens.