You’ve been told the same story for years: small teams need to modularize. Microservices are the future. And now, with LLMs promising to boost your productivity, the pressure is worse than ever—break your code into tiny pieces so AI agents can work in parallel. You’ve probably felt the anxiety: if you don’t adopt this architecture, you’ll be left behind.
But here’s what nobody tells you: Modularity is not a design principle. It’s a tax on small teams. The more you split your code, the more you pay in operational complexity, deployment nightmares, and cognitive load. And the worst part? The very AI tools that are supposed to save you are the ones demanding this sacrifice.
I’ve seen this firsthand. A friend runs a two-person startup. They started with a clean monolith—tight code, fast shipping, happy customers. Then the ‘experts’ told them they needed to ‘prepare for AI.’ So they broke it into fifteen microservices. Now they spend 80% of their time debugging network calls and container orchestration. Their velocity? Dead. Their LLM? Still can’t find the right files because the context window is too small.
This is the trap. The source article you’ve probably read—’There’s no such thing as a small software team anymore’—argues that LLMs force modularity. But that’s a false choice. The real bottleneck isn’t team size or AI adoption. It’s the architectural dogma that equates modularity with good design.
Look at the comment that got the most traction: ‘Build a well architected monolith and be super strict on single purpose and keeping modules separated from each other.’ That’s not a throwaway opinion—it’s the missing piece. A monolith with strict module boundaries gives you the same parallelism as microservices, without the operational overhead. Your LLM can still work on isolated modules. Your agents can still run in parallel. But you maintain a single deployable unit, a single codebase, a single team.
Uber’s approach to modularity was extreme for a reason: they had thousands of engineers. For a team of five, it’s not just overkill—it’s lethal. Neutrality is death in software architecture. Pick a side: either embrace the monolith with discipline, or accept that you’re building a distributed system that will eat your team alive.
The twist? Most people miss that the push for modularity is a result of laziness, not sophistication. It’s easier to throw a new service over the wall than to enforce clean boundaries within a monolith. But the latter is what actually makes small teams viable. You don’t need more agents. You need better boundaries.
So here’s the truth: Small teams aren’t dead. They just need to stop listening to the modularity prophets. A monolith with discipline is more powerful than a million microservices. The next time someone tells you to split your code for AI, ask them: ‘Who’s going to pay the ops tax?’ If they don’t have an answer, walk away.
FAQ
Q: Isn't modularity necessary for scaling?
A: You can scale within a monolith by enforcing strict module boundaries—think of them as logical microservices without the physical overhead. Microservices only make sense when your team is large enough to own each service independently. For small teams, they're a death sentence.
Q: What's the practical implication for my team?
A: Stop splitting your codebase until you hit a real performance bottleneck. Focus on clean interfaces, single-responsibility modules, and a single deployment pipeline. Your LLM agents will work just as well when they can see the whole codebase and understand module boundaries.
Q: What about the argument that LLMs need parallel execution?
A: Parallel execution doesn't require separate services. A monolith can run multiple agents in parallel on different modules—just use process isolation or lightweight containers. The operational complexity of a full microservices stack far outweighs any marginal AI gain for small teams.