Live data from Hacker News

Does coding with LLMs mean more microservices?

ben.page

31–40 of 73 posts

Re: Does coding with LLMs mean more microservices?

#31
Like almost all of these articles, there's really nothing AI- or LLM-specific here at all. Modularization, microservices, monorepos etc have all been used in the past to help scale up software development for huge teams and complex systems.

The only new thing is that small teams using these new tools will run into problems that previously only affected much larger teams. The cadence is faster, sometimes a lot faster, but the architectural problems and solutions are the same.

It seems to me that existing good practices continue to work well. I haven't seen any radically new approaches to software design and development that only work with LLMs and wouldn't work without them. Are there any?

I've seen a few suggestions of using LLMs directly as the app logic, rather than using LLMs to write the code, but that doesn't seem scalable, at least not at current LLM prices, so I'd say it's unproven at best. And it's not really a new idea either; it's always been a classic startup trick to do some stuff manually until you have both the time and the necessity to automate it.

Re: Does coding with LLMs mean more microservices?

#32
post #9

What matters for LLMs is what matters for humans, which usually means DX. Most Microservice setups are extremely hard to debug across service boundaries, so I think in the future, we'll see more architectural decisions that make sense for LLMs to work with. Which will probably mean modular monoliths or something like that.

Aren't libraries just "services" without some transport layer / gateway? You should only ever have a separate "service" if there's a concrete reason to. You should never have a "service" to make things simpler (it inherently does not). Libraries on the other hand are much more subjective.

> Aren't libraries just "services" without some transport layer / gateway?

Libraries can share memory, mutable state, etc. Services can not.

> (it inherently does not)

That's going to be debatable.

Re: Does coding with LLMs mean more microservices?

#33
One thing I find interesting is how GraphQL has evolved from an API technology for API consumers with "different needs" to an API technology for agents. What helped organizations scale GraphQL across multiple teams is Federation, a way to split one supergraph into multiple subgraphs. So, what works well to scale teams actually works equally well for agents. The core value you can get from Federation is a "coordination" layer that is deterministic. Now, what's interesting is that you can scale agentic software development pretty well when you have a deterministic layer where everyone involved can agree. I wrote more about this on our blog if anyone is interested: https://wundergraph.com/blog/graphql-api-layer-for-ai-agents

Re: Does coding with LLMs mean more microservices?

#34

Like almost all of these articles, there's really nothing AI- or LLM-specific here at all. Modularization, microservices, monorepos etc have all been used in the past to help scale up software development for huge teams and complex systems. The only new thing is that small teams using these new tools will run into problems that previously only affected much larger teams. The cadence is faster, sometimes a lot faster,…

[flagged]

Re: Does coding with LLMs mean more microservices?

#36

Like almost all of these articles, there's really nothing AI- or LLM-specific here at all. Modularization, microservices, monorepos etc have all been used in the past to help scale up software development for huge teams and complex systems. The only new thing is that small teams using these new tools will run into problems that previously only affected much larger teams. The cadence is faster, sometimes a lot faster,…

[flagged]

Why would you use an LLM to format your code?

Re: Does coding with LLMs mean more microservices?

#38
post #10

That's an argument for components with well-defined contracts on their interfaces, but making them microservices just complicates debugging for the model. It's also unclear whether tight coupling is actually a problem when you can refactor this fast.

Whether you call it modularization, good design, SOLID principles, or micro services, etc. It all boils down to the same thing. I usually dumb it down to two easy to understeand metrics: cohesiveness and coupling. Something with high cohesiveness and low coupling tends to be small and easy to reason about. Things that are small, can be easily replaced, fixed, changed, etc. with relatively low risk. Even if you have a…

The problem with the latter has always been the same. It requires careful review to ensure that system boundaries aren't being crossed. It's very obvious if your repo sounds to access to a new database. Less so if it imports a function directly from an inappropriate package.

Re: Does coding with LLMs mean more microservices?

#39
post #24

I think this is a promise, probably also for spec driven development. You write the spec, the whole thing can be reimplemented in rust tomorrow. Make small modules or libraries. One colleague describes monolith vs microservices as "the grass is greener of the other side". In the end, having microservices is that that the release process becomes much harder. Every feature spans 3 services at least, with possible incom…

>Every feature spans 3 services at least

If a feature spans more microservices it seems that the microservices boundaries are not well defined.

Re: Does coding with LLMs mean more microservices?

#40

Earlier quoted context omitted.

Whether you call it modularization, good design, SOLID principles, or micro services, etc. It all boils down to the same thing. I usually dumb it down to two easy to understeand metrics: cohesiveness and coupling. Something with high cohesiveness and low coupling tends to be small and easy to reason about. Things that are small, can be easily replaced, fixed, changed, etc. with relatively low risk. Even if you have a…

The problem with the latter has always been the same. It requires careful review to ensure that system boundaries aren't being crossed. It's very obvious if your repo sounds to access to a new database. Less so if it imports a function directly from an inappropriate package.

So test it separately.
Post reply on HN