alt Hacker NewsI believe that the solution to the coordination problem is good monorepo tooling (like the OP) plus AI to understand the whole codebase and help the engineers understand how their part fits in.
I was one of the biggest proponents of microservices, going so far as to traveling around the world spreading the gospel of microservices keynoting large tech conferences. I believed that microservices were the best solution to scaling large teams of developers, so that small teams could work on small problems, where the API was the only contract between them.
But even then I cautioned that the overhead made it not worthwhile for small teams -- that it was a solution to the coordination problem for large organizations. And that Google was not a counterexample because they had spent so many resources on their monorepo tooling.
But there is a new factor in town that changes the calculus:
AIs can grok monorepos much easier than a cluster of microservices. AIs change the calculus here. They allow the developer to work successfully in even the largest monorepos, and the AIs themselves will give better results when all of the code is in one place.
Replies
IMO AI agents harnesses (claude code, codex, etc) haven't added monorepo features yet as of a couple of months ago and thats what makes them painful. Basic things like, only apply these skills to the subdir that the .agents/skills directory exists in would go a long way. Or even reading the skills in a subdir .agents/skills directory. Or the ability to specify the basic monorepo custom VCS and other actions in a way that isn't limited to fragile skills and AGENTS.md specs that can get forgotten or unused as the context windows grows in a session and so on.
You can have microservices while still using a monorepo. They are still useful for creating service topology that can segment scaling and permissions, though I think people get carried away in the number of services created.
I think the eventual sweet spot will be monorepos that have good modular boundaries, and dynamically adjusting service topology that doesn't rely on pre-committed decisions on what code lives in a "service".
IME, AI does find established patterns more quickly a in monorepo (sometimes the ones you want, sometimes the ones you don't) - but at the cost of an enormous overhead tax you pay on input token cost.
Giving agents pointers to the right patterns, libraries and services helps avoid expensive grep goose chases, but if you're already curating the input you can do the same thing with small repositories.
Microservices is a deployment strategy. Monorepo is a code organization strategy. They are not mutually exclusive.
I'm going to play devil's advocate here.
As a developer, I quite like monorepos to a certain size (eg: until they get big enough that the tooling we typically use outside of big tech starts to fall down).
As an AI, I'm not sure that I care? I'd guess that context management can actually be easier if each microservice has a well documented API (openapi/graphql/grpc/asyncapi/whatever) and you provide the agent harness the ability to drop into each polyrepo as required (and give it the ability to access said documentation).
The tedium of making branches / commits / pull requests across 6 repos to land a feature is less problematic to an agent.
Admittedly the way I'm using agents at the moment is more repo orientated where it's sandboxed to a single repo, but conceptually I think polyrepo microservices could end up being a sweet spot.