Common objections to monorepos debunked: they are not monoliths, they scale, and they work great with AI.

Common objections to monorepos are addressed and debunked one by one. A monorepo is not a monolith — deployment and repository structure are orthogonal concerns. Code ownership can be enforced at the folder or project level using tools like GitHub CODEOWNERS or Nx's @nx/owners. Module boundaries and dependency constraints prevent the 'big ball of mud' problem. CI scalability is solved through affected-only builds, remote caching, distributed task execution, and test atomization. AI coding agents actually benefit from monorepo structure rather than being overwhelmed by it. Real challenges include the need for trunk-based development, more sophisticated CI setup, and careful handling of breaking changes to shared libraries.

A Monorepo Is NOT a Monolith

Monorepo is legacy (from git 1.5.2 in 2007). Use git modules if u need collect many repos to multyProjects Project, but use one separated repo for every product. Always!!!
Monorepo was ugly before gitmodules, but now it’s just a tool for lazy people.
So, should you use Monolith? Yes, but it depends on the situation. Should you use Monorepo? No, never.

These are completely different topics

Tldr
But if you need an additional tool where you can just create multi repositories and just have git, don’t see the benefits…
Actually the shared code is in a lib that is pulled by other projects

In my experience monorepos rarely work and require strong discipline from developers and very detailed code reviews.
To clearly separate concepts and create a bounded mental model, services should be physically separated into different repositories. Otherwise developers can easily change everything without realizing where the boundaries are.