I had the same thought as I'm working with LLMs. Then I reached the same conclusion as I did without LLMs: you can get most of the benefits without many of the drawbacks using well-bounded 'modules' within a monolith. The article doesn't distinguish these:
> When coding in a monolith, you have to worry about implicit coupling. The order in which you do things, or the name of a cache key, might be implicitly relied-upon by another part of the monolith. It’s a lot easier to cross boundaries and subtly entangle parts of the application. Of course, you might not do such unmaintainable things, but your coworkers might not be so pious.
What it's saying could also apply to a monorepo with distinctly deployed artifacts. The reason many don't think about clear boundaries between modules is that popular interpreted languages don't support them. Using the Java ecosystem as an example, each module can be a separate .jar containing one or more package namespaces. These must have an explicit X uses Y declaration.
The problem I see isn't so much that misuse it's easy (though that's a part of it), it's that there's to clear indication that boundaries are being crossed since calling from one package to another is normal, and the fact that some packages belong to other modules isn't always obvious.
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.
Maybe just a refinement of "LLM as app logic" but "LLM as emergent workflow" seems powerful.
For example, a customer service playbook may have certain ways to handle different user problems, but that breaks down as soon as there are complications or compound issues. But an LLM with the ability to address individual concerns may be able to synthesize solution given fundamental constraints. It's kind of lile building mathematics from axioms.
The "current LLM prices" part is doing a lot of work in that argument though. Prices dropped roughly 10x in the past year, and model routing helps too -- not every inference call in an agent loop actually needs a frontier model. Tool output parsing, formatting, simple next-step decisions can use something that costs 1/100th of Opus without quality loss.
The real shift isn't just that code gets generated faster, it's that people are starting to use LLMs as runtime components. And the cost curve for that use case is moving way faster than most people realize.
Right. The equivalent in handwritten code would be formatting your code by hand. That used to be the normal way to do it!
For handwritten code, the evolution of best practices has tended to be:
- just make your code look neat and tidy;
- follow the style and conventions of existing code;
- follow a strict formatting style guide;
- format automatically using a tool.
I don’t see why it should be any different with LLMs. Why format with an LLM each time, when you can use the LLM once to write the formatter?
Maybe there’s a point at which neural nets replace conventional programming languages for low-level tasks. But I’m skeptical that natural language models will replace programming languages for low-level tasks any time soon.
> Why format with an LLM each time, when you can use the LLM once to write the formatter?
the right way to use an llm imo (and same for end-user features as well)... no need to waste tokens and wait time on something that can be done at a fraction of the cost and time (and be deterministic on top of that)
That had me bogling too. But you know what? A local MoE model roughly equivalent to sonnet mid-2025? Totally possible. Just costs electricity to run, put it in your CI/CD pipeline. Have it apply a bit of intelligence to the thing as well. Uh.... if you've got a spare box, why not?
(the fact that said spare box would cost an arm and a leg in 2026 is... a minor detail)
Why not? Because you can get stronger guarantees of correctness and consistency out of a typical code formatter, which will also probably run about a million times faster.
> 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.
I've been thinking about it lately and I think you are right. LLMs haven't changed what is 'good software'. But they changed some proxies I used to have for what is 'good software'.
In the past I've always loved projects that had good documentation, and many times I've used this metric to select a project/library to use. But LLMs transformed something that was (IMHO) a good indicator for "care"/"software quality" into something that is becoming irrelevant (see Goodhart's law).
I'm not sure llms produce good documentation. I'm open to hear more opinions on this, my feeling is that the documentation of llm-heavy projects is a bit too verbose, a bit off-target, sometimes completely irrelevant, very repetitive.
Not terrible, but I'll just point my own llm to it instead of reading it myself like I would for an actual great documentation
If you are willing to point your LLM to the docs instead of actually reading it why not skip it and send your LLM directly to the source code? That is what I've been doing recently, and that is why recently good documentation became less important for me.
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.
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 monolith, you probably want to impose some structure on it. Whenever you get tight coupling and low cohesiveness in a system, it can become a problem spot.
Easy reasoning here directly translates into low token cost when reasoning. That's why it's beneficial to keep things that way also with LLMs. Bad design always had a cost. But with LLMs you can put a dollar cost on it.
My attitude with micro services is that it's a lot of heavy handed isolation where cheaper mechanisms could achieve much of the same effects. You can put things in a separate git repository and force all communication over the network. Or you can put code in different package and guard internal package cohesiveness and coupling a bit and use well defined interfaces to call a functions through. Same net result from a design point of view but one is a bit cheaper to call and whole lot less hassle and overhead. IMHO people do micro-services mostly for the wrong reasons: organizational convenience vs. actual benefits in terms of minimizing resource usage and optimizing for that.
> Or you can put code in different package and guard internal package cohesiveness and coupling a bit and use well defined interfaces to call a functions through.
While I do think actual microservices are over-kill. I don't think I've seen code anywhere that survives multiple years where somebody doesn't use internal state of another package. Like if you don't force people to use a hard barrier (i.e. HTTP) then there's going to be workarounds.
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.
No, I think you’re not reading it literally enough. “Microservices” generally does mean separate HTTP (or at least RPC) servers. Near the beginning, the article says:
A microservice has a very well-defined surface area. Everything that flows into the service (requests) and out (responses, webhooks)
Are you purposely misreading the comment? Where did it say that http was the only form of communication (or even the best) between microservices? Where did it imply there weren't other methods?
> While HTTP can be considered as a transport layer for RPCs between microservices, it seems to me to be a very inefficient and bug-prone solution.
This is so irrelevant to the point being made it's nuts.
Why arbitrarily invent new meanings (for microservices) and new words (microlibraries) when there are already many adequate ways to describe modular, componentized architecures?
A totally valid and important point but it has been diluted by talking about microservices rather than importance of modular architectures for agent-based coding.
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.
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).
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.
Expanding:
Think of it this way: A typical sprint in current best practices is 1-2 weeks. Having to scrap a module and start over loses you a lot of time and money. A typical "AI sprint " is << 20 minutes. Several passes of failing a module and rewriting the spec is still only a few hours.
A typical rant is "You claim only the output is what counts; but what about the human warmth?". Well, this is IT. If you can thoroughly prove that the inputs and outputs are identical to spec you have done the thing.
Harder than it sounds: CDNs and suss libraries no one told you about, abysmal security, half baked features? Uh.... yeah that happens. But if the blast radius is small, it's fixable and survivable. Hopefully.
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
I think of "Federation" as aggregating content from disparate in-situ sources into a common index under a consistent schema. I agree that schema is good, am always tempted by big schema, and seem to always settle for task-specific schema with mappings between schemas strictly as necessary. LLM's seem nice for schema to schema mapping and supernice for binding entities from unstructured sources into schema. But overall I feel it is pointless to talk about structure without talking about hydration - about binding and mapping. Do you see that as "solved"?
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?
The context window framing is compelling but I think the more durable pressure is the "blast radius" problem — not whether the model can hold your whole codebase in working memory, but whether a confident-but-wrong agent can cause cascading failures across the whole system.
Even as context windows hit 1M+ tokens, you'd probably still want bounded rollback units. Clean module interfaces help less with the comprehension problem and more with the containment one. Whether those modules get a network boundary is mostly an ops tradeoff — the architectural principle is the same either way.
I have wondered this as well. Maybe it's trying to train based on which accounts get flagged/ time-to-flag or something? Otherwise... who would bother with this? It's so dumb.
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 incompatibility between some of their versions. Precisely the work you cannot easily automate with LLMs.
I don't think LLMs push us to use microservices as much as Borgers says they do. They don't avoid the problems microservices have always faced, and encapsulation is mostly independent from whether a boundary is a service-to-service boundary:
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?
If this is an issue you must be starting with a blank slate and not giving any direction. If you collaborate on the design you're not going to find it accidentally used microservices.
I had the same thought as I'm working with LLMs. Then I reached the same conclusion as I did without LLMs: you can get most of the benefits without many of the drawbacks using well-bounded 'modules' within a monolith. The article doesn't distinguish these:
> When coding in a monolith, you have to worry about implicit coupling. The order in which you do things, or the name of a cache key, might be implicitly relied-upon by another part of the monolith. It’s a lot easier to cross boundaries and subtly entangle parts of the application. Of course, you might not do such unmaintainable things, but your coworkers might not be so pious.
What it's saying could also apply to a monorepo with distinctly deployed artifacts. The reason many don't think about clear boundaries between modules is that popular interpreted languages don't support them. Using the Java ecosystem as an example, each module can be a separate .jar containing one or more package namespaces. These must have an explicit X uses Y declaration.
The problem I see isn't so much that misuse it's easy (though that's a part of it), it's that there's to clear indication that boundaries are being crossed since calling from one package to another is normal, and the fact that some packages belong to other modules isn't always obvious.
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.
Maybe just a refinement of "LLM as app logic" but "LLM as emergent workflow" seems powerful.
For example, a customer service playbook may have certain ways to handle different user problems, but that breaks down as soon as there are complications or compound issues. But an LLM with the ability to address individual concerns may be able to synthesize solution given fundamental constraints. It's kind of lile building mathematics from axioms.
The "current LLM prices" part is doing a lot of work in that argument though. Prices dropped roughly 10x in the past year, and model routing helps too -- not every inference call in an agent loop actually needs a frontier model. Tool output parsing, formatting, simple next-step decisions can use something that costs 1/100th of Opus without quality loss.
The real shift isn't just that code gets generated faster, it's that people are starting to use LLMs as runtime components. And the cost curve for that use case is moving way faster than most people realize.
Why would you use an LLM to format your code?
Right. The equivalent in handwritten code would be formatting your code by hand. That used to be the normal way to do it!
For handwritten code, the evolution of best practices has tended to be:
- just make your code look neat and tidy;
- follow the style and conventions of existing code;
- follow a strict formatting style guide;
- format automatically using a tool.
I don’t see why it should be any different with LLMs. Why format with an LLM each time, when you can use the LLM once to write the formatter?
Maybe there’s a point at which neural nets replace conventional programming languages for low-level tasks. But I’m skeptical that natural language models will replace programming languages for low-level tasks any time soon.
That had me bogling too. But you know what? A local MoE model roughly equivalent to sonnet mid-2025? Totally possible. Just costs electricity to run, put it in your CI/CD pipeline. Have it apply a bit of intelligence to the thing as well. Uh.... if you've got a spare box, why not?
(the fact that said spare box would cost an arm and a leg in 2026 is... a minor detail)
Why not? Because you can get stronger guarantees of correctness and consistency out of a typical code formatter, which will also probably run about a million times faster.
You're not wrong. Though now I am thinking of ways an LLM in CI might be useful, (dijkstra forgive me).
> 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.
I've been thinking about it lately and I think you are right. LLMs haven't changed what is 'good software'. But they changed some proxies I used to have for what is 'good software'.
In the past I've always loved projects that had good documentation, and many times I've used this metric to select a project/library to use. But LLMs transformed something that was (IMHO) a good indicator for "care"/"software quality" into something that is becoming irrelevant (see Goodhart's law).
I'm not sure llms produce good documentation. I'm open to hear more opinions on this, my feeling is that the documentation of llm-heavy projects is a bit too verbose, a bit off-target, sometimes completely irrelevant, very repetitive.
Not terrible, but I'll just point my own llm to it instead of reading it myself like I would for an actual great documentation
If you are willing to point your LLM to the docs instead of actually reading it why not skip it and send your LLM directly to the source code? That is what I've been doing recently, and that is why recently good documentation became less important for me.
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.
> That's going to be debatable.
It's really not. A service adds complexity. If you have no reason to add it besides to "reduce complexity" - that is an oxymoron.
There are many concrete reasons to have one. Reducing complexity is not one.
That's like arguing you can drive farther forward if you go in reverse. No.
There are reasons to drive in reverse. To move forward is not one of them.
Definitively our approach is ai dev ex first.
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 monolith, you probably want to impose some structure on it. Whenever you get tight coupling and low cohesiveness in a system, it can become a problem spot.
Easy reasoning here directly translates into low token cost when reasoning. That's why it's beneficial to keep things that way also with LLMs. Bad design always had a cost. But with LLMs you can put a dollar cost on it.
My attitude with micro services is that it's a lot of heavy handed isolation where cheaper mechanisms could achieve much of the same effects. You can put things in a separate git repository and force all communication over the network. Or you can put code in different package and guard internal package cohesiveness and coupling a bit and use well defined interfaces to call a functions through. Same net result from a design point of view but one is a bit cheaper to call and whole lot less hassle and overhead. IMHO people do micro-services mostly for the wrong reasons: organizational convenience vs. actual benefits in terms of minimizing resource usage and optimizing for that.
> Or you can put code in different package and guard internal package cohesiveness and coupling a bit and use well defined interfaces to call a functions through.
While I do think actual microservices are over-kill. I don't think I've seen code anywhere that survives multiple years where somebody doesn't use internal state of another package. Like if you don't force people to use a hard barrier (i.e. HTTP) then there's going to be workarounds.
This is also extremely common with LLMs, in my experience. They grep, find something, make it `pub`, etc.
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.
You are taking the article argument too literally. They meant microservices also in the sense of microlibraries, etc, not strictly a HTTP service.
No, I think you’re not reading it literally enough. “Microservices” generally does mean separate HTTP (or at least RPC) servers. Near the beginning, the article says:
A microservice has a very well-defined surface area. Everything that flows into the service (requests) and out (responses, webhooks)
I think a better word would have been "modularization" than "microservices" as I also highly correlate "microservices" with http-based calls.
Really? That seems strange, at least to me.
While HTTP can be considered as a transport layer for RPCs between microservices, it seems to me to be a very inefficient and bug-prone solution.
Can you describe a set up where you used HTTP between microservices?
> Really? That seems strange, at least to me.
Are you purposely misreading the comment? Where did it say that http was the only form of communication (or even the best) between microservices? Where did it imply there weren't other methods?
> While HTTP can be considered as a transport layer for RPCs between microservices, it seems to me to be a very inefficient and bug-prone solution.
This is so irrelevant to the point being made it's nuts.
Why arbitrarily invent new meanings (for microservices) and new words (microlibraries) when there are already many adequate ways to describe modular, componentized architecures?
A totally valid and important point but it has been diluted by talking about microservices rather than importance of modular architectures for agent-based coding.
> describe modular,
Agreed. Modular is what they were probably after.
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.
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.
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.
Expanding: Think of it this way: A typical sprint in current best practices is 1-2 weeks. Having to scrap a module and start over loses you a lot of time and money. A typical "AI sprint " is << 20 minutes. Several passes of failing a module and rewriting the spec is still only a few hours.
A typical rant is "You claim only the output is what counts; but what about the human warmth?". Well, this is IT. If you can thoroughly prove that the inputs and outputs are identical to spec you have done the thing.
Harder than it sounds: CDNs and suss libraries no one told you about, abysmal security, half baked features? Uh.... yeah that happens. But if the blast radius is small, it's fixable and survivable. Hopefully.
Famous last words.
Large context windows cost more money. So the pressure is still there to keep it tight.
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
I think of "Federation" as aggregating content from disparate in-situ sources into a common index under a consistent schema. I agree that schema is good, am always tempted by big schema, and seem to always settle for task-specific schema with mappings between schemas strictly as necessary. LLM's seem nice for schema to schema mapping and supernice for binding entities from unstructured sources into schema. But overall I feel it is pointless to talk about structure without talking about hydration - about binding and mapping. Do you see that as "solved"?
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?
The context window framing is compelling but I think the more durable pressure is the "blast radius" problem — not whether the model can hold your whole codebase in working memory, but whether a confident-but-wrong agent can cause cascading failures across the whole system.
Even as context windows hit 1M+ tokens, you'd probably still want bounded rollback units. Clean module interfaces help less with the comprehension problem and more with the containment one. Whether those modules get a network boundary is mostly an ops tradeoff — the architectural principle is the same either way.
What's the point of flooding this site with slop accounts? Do people just want to see the world burn? Why attack culture?
I have wondered this as well. Maybe it's trying to train based on which accounts get flagged/ time-to-flag or something? Otherwise... who would bother with this? It's so dumb.
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 incompatibility between some of their versions. Precisely the work you cannot easily automate with LLMs.
>Every feature spans 3 services at least
If a feature spans more microservices it seems that the microservices boundaries are not well defined.
I don't think LLMs push us to use microservices as much as Borgers says they do. They don't avoid the problems microservices have always faced, and encapsulation is mostly independent from whether a boundary is a service-to-service boundary:
https://www.natemeyvis.com/agentic-coding-and-microservices/
service-to-service boundary is easiest to keep with the way we are using LLMs to code right now
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.
I think no. But I think it makes sense to break down your app into libraries etc
>> LLM-assisted coding naturally flows towards small microservices
Only if you’re a sufficiently bad programmer to not tell it the architecture it must comply to that hopefully you have the skills to define.
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?
If this is an issue you must be starting with a blank slate and not giving any direction. If you collaborate on the design you're not going to find it accidentally used microservices.