Is Claude changing my mind about microservices?
Anyone who knows me as a Rails or Phoenix developer already knows my default answer: start with the monolith. I am firmly in the Monolith First camp, and that opinion comes from experience, not theory. I have the battle scars from being in the microservice trenches during microservice battles of 2013-2014: too many repos, too much orchestration, too much cross-service debugging, and entire days lost to problems that had nothing to do with the product.
So my usual advice is simple: build a monolith in Rails or Phoenix, get to product-market fit, and keep pushing that monolith until the fault lines are obvious. Even then, most monoliths still have more life in them than people think. Like an old Honda Civic, they usually have a few more thousand miles left. Shopify keeps making that point with its long-running monolith.
That is why my current project has been so disorienting. We are breaking almost all of my rules, and somehow it is still working.
Right now the system is split across four repos:
- A React frontend (with mantine - uggh)
- A React frontend (tanstack - hell yeah!)
- A Rails API server
- A FastAPI service built around Pydantic AI
On paper, this is exactly the kind of setup I would normally argue against. Multiple frontends already increase the coordination cost. Add a Rails backend and a Python AI service, and you now have different runtime environments, different deployment concerns, different testing styles, and multiple places where context can get lost. In a normal team workflow, that can become exhausting very quickly.
What has surprised me is that Claude changes the paradigm.
I do not mean that Claude magically makes distributed systems good. The same structural problems still exist. Boundaries can still be wrong. Ownership can still be fuzzy. Integration bugs still happen. But the day-to-day tax of working across multiple codebases feels lower when I can offload a lot of the context switching.
The workflow that has been working for me looks roughly like this:
- Write the top-level Linear ticket and define the scope with Claude through Linear’s MCP
- Break that work into smaller repo-specific issues with Claude
- Execute each sub-issue in one Claude code session
The coordination burden is still there, but it is more manageable because I am not manually rebuilding all of that context every time I switch.
In other words, Claude is not making me love microservices. It is making me slightly less allergic to them.
I still think most teams reach for service boundaries too early. I still think a monolith is the right default for most products, especially when the main challenge is discovering what to build rather than scaling what already works. But I also have to admit that AI-assisted development changes the ergonomics of a multi-repo system. Some of the pain that used to make microservices unbearable was human coordination overhead, and tools like Claude can absorb a meaningful portion of that overhead.
So no, I have not converted. I am not about to start telling early-stage teams to split everything into services on day one. But for the first time in a while, I can see a version of the argument where a service-heavy setup is not automatically a productivity disaster, especially if the tooling helps each boundary feel smaller than it really is.