Does coding with LLMs mean more microservices?

It has been reported that developers are watching a new kind of sprawl unfold. On Hacker News and in a short post by Ben Page (ben.page/microservices), engineers say LLM-assisted coding naturally nudges teams toward carving functionality into small, focused microservices — think a standalone service that handles image and video generation for the rest of a backend. The promise is obvious: tiny, testable pieces you can prompt, iterate, and replace fast. Who wouldn’t like that?

What engineers are seeing

The pattern makes sense. LLMs are best at well-scoped tasks and work nicely with API-style boundaries. Spin up a service that wraps an image-generation model, give it a clear contract, and suddenly other teams can call it like any other endpoint. It’s modularity with a turbocharger. But it’s not just practicality; there’s an emotional current here — delight at rapid prototyping, mixed with a flash of dread when you imagine dozens of one-purpose endpoints multiplying overnight.

The trade-offs

More microservices sounds modern, but it’s not free. Latency, orchestration, security, observability, and billing complexity all rise with count. This feels a lot like the microservices honeymoon of the 2010s — exciting at first, operationally heavy later. The unique twist now: many of these services wrap large models and external APIs, so costs and external dependencies can balloon quickly. Governance and API standards matter more than ever.

Why this matters

So, will LLMs usher in a golden age of efficient, single-purpose services — or a new era of brittle, over-split architectures? The honest answer: both. Teams that adopt clear boundaries, monitoring, and cost controls may reap big wins. Those that don’t could end up with a jungle of endpoints needing a machete. Question for architects: how do you get the best of LLM-driven modularity without signing up for maintenance misery? That’s the practical dilemma playing out right now.

Sources: ben.page, Hacker News