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.
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.
The bounded surface area insight is right, but the actual forcing function is context window size. Small codebase fits in context, LLM can reason end-to-end. You get the same containment with well-defined modules in a monolith if your tooling picks the right files to feed into the prompt.
Interesting corollary: as context windows keep growing (8k to 1M+ in two years), this architectural pressure should actually reverse. When a model can hold your whole monolith in working memory, you get all the blast radius containment without the operational overhead of separate services, billing accounts, and deployment pipelines.
Agree on the context window framing. If an LLM needs well-defined boundaries to work well, just write clean module interfaces. You don't need a network boundary for that.
The part about "less scrutiny on PR review" and committing straight to main is telling too. That's not really about microservices, that's just wanting to ship faster with less oversight. Works until it doesn't.
> The part about "less scrutiny on PR review" and committing straight to main is telling too. That's not really about microservices, that's just wanting to ship faster with less oversight. Works until it doesn't.
And that's the reason I think the author proposes microservices I think. Doesn't need to be microservices, but something where your codebase is split up so that when-not-if it does blow up, you only roll back the one component and try again.
Modularization is hardly a new idea, but might need a slight spin to allow agents to work by themselves a bit more. The speed advantages are too tantalizing not to.
This makes no sense as you’re able to have similar interfaces and contracts using regular code.
Microservices solve an organizational problem mostly — teams being able to work completely independently, do releases independently, etc — but as soon you’re going to actually do that, you’re introducing a lot of complexity (but gain organizational scalability).
This seems like the idea of modularizing code, and using specific function sighatures for data exchange as an API is being re-invented by people using AI. Aren't we already mostly doing things this way, albeit via submodules in a monolith, due to the cognitive ctrain it puts on humans to understand the whole thing at any given time?
A typical rant (composed from memory) goes something like this:
> "These AI types are all delusional. My job is secure. Sure your model can one-shot a small program in green field in 5 minutes with zero debugging. But make it a little larger and it starts to forget features, introduces more bugs than you can fix, and forget letting it loose on large legacy codebases"
What if that's not a diagnosis? What if we see that as an opportunity? O:-)
I'm not saying it needs to be microservices, but say you can constrain the blast radius of an AI going oops (compaction is a famous oops-surface, for instance); and say you can split the work up into self-contained blocks where you can test your i/o and side effects thoroughly...
... well, that's going to be interesting, isn't it?
Programming has always supposed to be about that: Structured programming, functions (preferably side-effect-less for this argument), classes&objects, other forms of modularization including -ok sure- microservices. I'm not sold on exactly the latter because it feels a bit too heavy for me. But ... something like?
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.
You are taking the article argument too literally. They meant microservices also in the sense of microlibraries, etc, not strictly a HTTP service.
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.
The bounded surface area insight is right, but the actual forcing function is context window size. Small codebase fits in context, LLM can reason end-to-end. You get the same containment with well-defined modules in a monolith if your tooling picks the right files to feed into the prompt.
Interesting corollary: as context windows keep growing (8k to 1M+ in two years), this architectural pressure should actually reverse. When a model can hold your whole monolith in working memory, you get all the blast radius containment without the operational overhead of separate services, billing accounts, and deployment pipelines.
Agree on the context window framing. If an LLM needs well-defined boundaries to work well, just write clean module interfaces. You don't need a network boundary for that.
The part about "less scrutiny on PR review" and committing straight to main is telling too. That's not really about microservices, that's just wanting to ship faster with less oversight. Works until it doesn't.
> The part about "less scrutiny on PR review" and committing straight to main is telling too. That's not really about microservices, that's just wanting to ship faster with less oversight. Works until it doesn't.
And that's the reason I think the author proposes microservices I think. Doesn't need to be microservices, but something where your codebase is split up so that when-not-if it does blow up, you only roll back the one component and try again.
Modularization is hardly a new idea, but might need a slight spin to allow agents to work by themselves a bit more. The speed advantages are too tantalizing not to.
This makes no sense as you’re able to have similar interfaces and contracts using regular code.
Microservices solve an organizational problem mostly — teams being able to work completely independently, do releases independently, etc — but as soon you’re going to actually do that, you’re introducing a lot of complexity (but gain organizational scalability).
This has nothing to do with context sizes.
Large context windows cost more money. So the pressure is still there to keep it tight.
This seems like the idea of modularizing code, and using specific function sighatures for data exchange as an API is being re-invented by people using AI. Aren't we already mostly doing things this way, albeit via submodules in a monolith, due to the cognitive ctrain it puts on humans to understand the whole thing at any given time?
A typical rant (composed from memory) goes something like this:
> "These AI types are all delusional. My job is secure. Sure your model can one-shot a small program in green field in 5 minutes with zero debugging. But make it a little larger and it starts to forget features, introduces more bugs than you can fix, and forget letting it loose on large legacy codebases"
What if that's not a diagnosis? What if we see that as an opportunity? O:-)
I'm not saying it needs to be microservices, but say you can constrain the blast radius of an AI going oops (compaction is a famous oops-surface, for instance); and say you can split the work up into self-contained blocks where you can test your i/o and side effects thoroughly...
... well, that's going to be interesting, isn't it?
Programming has always supposed to be about that: Structured programming, functions (preferably side-effect-less for this argument), classes&objects, other forms of modularization including -ok sure- microservices. I'm not sold on exactly the latter because it feels a bit too heavy for me. But ... something like?
This makes no sense. You can easily make a monolith and build all parts of it in isolation - i.e. modules, plugins, packages.
In fact, my argument is that there will be more monolith applications due to AI coding assistants, not less.
Why microservices when small composable CLI tools seem a better fit for LLMs?
His argument is not about LLM tools but rather about which architecture is better suited for coding with LLMs.