alt Hacker NewsI'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.
> The tedium of making branches / commits / pull requests across 6 repos to land a feature is less problematic to an agent.
You're probably not using your microservices correctly if you need to change more than one service at the same time. The whole point of microservices is independently developing and deploying the services. Sweeping changes like that should be done in pieces, one service at a time.
Which is why microservices are best for larger organizations, because it reduces coordination between dev groups.