Comment by le-mark

3 days ago

What size of code base are you talking about? And this is your personal experience?

Overall Codebase size vs context matter less when you set it up as microservices style architecture from the starts.

I just split it into boundaries that make sense to me. Get the LLM to make a quick cheat sheet about the api and then feed that into adjacent modules. It doesn’t need to know everything about all of it to make changes if you’ve got a grip on big picture and the boundaries are somewhat sane

  • Overall Codebase size vs context matter less when you set it up as microservices style architecture from the starts.

    It'll be fun if the primary benefit of microservices turns out to be that LLMs can understand the codebase.

  • So "pretty good at picking up existing codebases" so long as the existing codebase is all microservices.

    • I work with multiple monoliths that span anywhere from 100k to 500k lines of code, in a non-mainstream language (Elixir). Opus 4.5 crushes everything I throw at it: complex bugs, extending existing features, adding new features in a way that matches conventions, refactors, migrations... The only time it struggles is if my instructions are unclear or incomplete. For example if I ask it to fix a bug but don't specify that such-and-such should continue to work the way it does due to an undocumented business requirement, Opus might mess that up. But I consider that normal because a human developer would also do fail at it.

      1 reply →

  • It doesn't have to be micro services, just code that is decoupled properly, so it can search and build its context easily.