Yes, unfortunately those who jumped on the microservices hype train over the past 15 years or so are now getting the benefits of Claude Code, since their entire codebases fits into the context window of Sonnet/Opus and can be "understood" by the LLM to generate useful code.

This is not the case for most monoliths, unless they are structured into LLM-friendly components that resemble patterns the models have seen millions of times in their training data, such as React components.

▲

manmal 15 hours ago | parent [-]

Well structured monoliths are modularized just like microservices. No need to give each module its own REST API in order to keep it clean.

▲

randomtoast 3 hours ago | parent | next [-]

One problem is that the idea of being "well-structured" has gone overboard at some point over the past 20 years in many companies. As a result, many companies now operate highly convoluted monolithic systems that are extremely difficult to replace.

In contrast, a poorly designed microservice can be replaced much more easily. You can identify the worst-performing and most problematic microservices and replace them selectively.

	▲	tuhgdetzhh an hour ago \| parent [-]
		> One problem is that the idea of being "well-structured" has gone overboard at some point over the past 20 years That's exactly my experience. While a well-structured monolith is a good idea in theory, and I'm sure such examples exist in practice, that has never been the case in any of my jobs. Friends working at other companies report similar experiences.

▲

bccdee 5 hours ago | parent | prev | next [-]

Conversely, poorly-structured microservices are just monoliths where most of the code is in other repositories.

▲

Yoric 12 hours ago | parent | prev [-]

I guess that the benefit of monoliths in the context is that they (often) live in distinct repositories, which makes it easier for Claude to ingest them entirely, or at least not get lost into looking at the wrong directory.