▲ | flowerthoughts 3 days ago | |
I predict microservices will get a huge push forward. The question then becomes if we're good enough at saying "Claude, this is too big now, you have to split it in two services" or not. If LLMs maintain the code, the API boundary definitions/documentation and orchestration, it might be manageable. | ||
▲ | urbandw311er 3 days ago | parent | next [-] | |
Why not just cleanly separated code in a single execution environment? No need to actually run the services in separate execution environments just for the sake of an LLM being able to parse it, that’s crazy! You can just give it the files or folders it needs for the particular services within the project. Obviously there’s still other reasons to create micro services if you wish, but this does not need to be another reason. | ||
▲ | fsloth 3 days ago | parent | prev | next [-] | |
Why microservices? Monoliths with code-golfed minimal implementation size (but high quality architecture) implemented in strongly typed language would consume far less tokens (and thus would be cheaper to maintain). | ||
▲ | arwhatever 3 days ago | parent | prev [-] | |
Won’t this cause [insert LLM] to lose context around the semantics of messages passed between microservices? You could then put all services in 1 repo, or point LLM at X number of folders containing source for all X services, but then it doesn’t seem like you’ll have gained anything, and at the cost of added network calls and more infra management. |