>. They fall on their face trying to work in sprawling codebases.
>However, they are excellent at writing small bespoke programs
For programmers I predict a future of a million micro services.
Sprawling has always been an undesirable and unnecessary byproduct of growing code bases, but there's been no easy solution to that. I wonder if LLMs would perform better on a mono repo of many small services than one sprawling monolith.
Micro service systems are just huge sprawling code bases with more glue code. Calling something over a network instead of via a local function call is still calling something.
For years one of my favorite experiences (amusing given your username) was being on calls for incidents where they get the dev on for X thing and an exec goes "I thought we got rid of that" and a bunch of people sheepishly explain it wasn't really retired... it was repurposed as an API. I especially loved it when the "retirement" of the broken thing was the execs big achievement. (The comedic nuance often being the thing could have been retired for real, but they demanded a timeline that necessitated the "fake" retirement)
It still happens but it's not a favorite experience anymore. It's just a source of loathing for MBA culture.
Another way to look at it is - why force the agent to grapple with the whole code base when they can rapidly standup many single purpose services instead?
A large code base with modules with clear interfaces accomplishes most of this and is more efficient. Often vastly more efficient. Compare the cost of a function call or an in process message queue with a network API call over http.
Cloud providers make more money the more they can get people to use inefficient designs with more moving parts to rack up more charges. Bonus if it also locks you into managed services. Double bonus if those are proprietary. Complexity benefits cloud hosts.
Microservices, like all patterns, sometimes make sense. Like all patterns they often get overused.
Yep all true. Im not really arguing a point so much as thinking out loud - I guess the core idea I'm chewing on is whether LLM assisted development is enough of a paradigm shift that things that were formerly bad ideas become good ideas - but perhaps this particular line of thought (microservices) is the wrong one.
Micro-services are part of a system, so to create anything meaningful with them your context window has to include knowledge about the rest of the system anyway. If your system is large and complex, that means a huge context window even if your code itself is small.
Yeah i mean either they can or they cant handle large code contexts. I guess the theory is that a more organized and concise expression of your code base (not necessarily the raw code) is easier for agents to digest.
The issue as I have observed it is that software is written to cover as many use cases for as many users as possible. Obviously executives want to sell their product to as many hands as possible.
But end users often only need a tiny fraction of what the software is fully capable of, leaving a situation where you need you need to purchase 100% to use 5%.
LLMs can break down this wall by offering the user the ability to just make a bespoke 5% utility. I personally have had enormous success doing this.
Yeah if code-gen gets to a point similar to image-gen, where a user can prompt a full micro utility, then we will see the dual erosion of more DIY and also lower barrier of entry to the industry. Still most software value today is not about the utility but the IP, the network, and convenience. I suppose convenience is the main pillar at stake here.
>However, they are excellent at writing small bespoke programs
For programmers I predict a future of a million micro services.
Sprawling has always been an undesirable and unnecessary byproduct of growing code bases, but there's been no easy solution to that. I wonder if LLMs would perform better on a mono repo of many small services than one sprawling monolith.