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.

You are taking the article argument too literally. They meant microservices also in the sense of microlibraries, etc, not strictly a HTTP service.