The monorepo question is settled, and both sides won

Ten years of argument resolved into an unglamorous consensus that nobody claimed as a victory.

The monorepo debate was never really about repository count. It was about whether a change should be able to cross a module boundary atomically, and whether the cost of making that possible is worth paying. Framed that way, the answer that emerged is obvious in hindsight: it depends entirely on how often changes need to cross those boundaries, and organisations differ wildly on that.

What actually settled the argument was tooling convergence. Build graphs, remote caching, and code ownership at path granularity are now available in both topologies, which removed most of the concrete advantages each side used to claim. The remaining difference is genuinely organisational rather than technical, and organisational questions do not have universal answers.

• If a typical feature touches three services owned by three teams, the coordination cost of many repositories will dominate. Use one.
• If a typical feature touches one service and the teams ship independently, the ceremony of a shared build graph is pure overhead. Use many.
• If you cannot tell which of those describes you, instrument it. The answer is in your merge history and it takes an afternoon to extract.