|
| ▲ | onion2k 2 days ago | parent | next [-] |
| 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. |
| |
| ▲ | baq 2 days ago | parent [-] | | That was the whole point for humans, too. | | |
| ▲ | gf000 2 days ago | parent [-] | | Except it doesn't work the same way it won't work for LLMs. If you use too many microserviced, you will get global state, race conditions, much more complex failure models again and no human/LLM can effectively reason about those. We somewhat have tools to do that in case of monoliths, but if one gets to this point with microservices, it's game over. |
|
|
|
| ▲ | magicalist 2 days ago | parent | prev | next [-] |
| So "pretty good at picking up existing codebases" so long as the existing codebase is all microservices. |
| |
| ▲ | heartbreak 2 days ago | parent | next [-] | | Or a Rails app. | |
| ▲ | enraged_camel 2 days ago | parent | prev [-] | | 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. | | |
| ▲ | aprilthird2021 2 days ago | parent [-] | | With all due respect those are very small codebases compared to the kinds of things a lot of software engineers work on. |
|
|
|
| ▲ | phito 2 days ago | parent | prev [-] |
| It doesn't have to be micro services, just code that is decoupled properly, so it can search and build its context easily. |