I admit I have a hard time following this logic. If an agent has a baseline intelligence, you can... instead of using boring technology, just DIY/NIH the simplest custom solution which fulfills your requirements. And you'll usually do a better job than a general-purpose software library.
Even if in the other approach, the LLM knows the stack better, you're just going to push the complexity into your client code, so it's not like it's a huge gain to use boring tech stack.
That’s definitely not true, and I’ll give two incredibly common examples:
1: arraylist. A library will probably do better than you. It’s already written and common.
2: webservers. Sure, you can write one yourself with sockets and a bunch of buffers and string management… or, you could use one of the 100s of existing ones. Which one? Probably a stable and established one.
1. This isn't true whatsoever. You can easily do better than std::vector (trivial relocation support, non-inlined grow), better than C# List<T> (ref T accessor, batch add API, maybe even an add-uninitialised API or in-place constructing specific things), better than a Python list (this one is obvious), etc.
2. This is a better point but depending on your workload, I don't think this is unheard of. Or at the very least, if your workload is simple, you can grab one off the top of the benchmarks, point AI at it to customise it a bit then you're good. But to be fair this one's a bigger structural investment so I do see your point. For smaller utilities the tradeoff is pretty clear.
Is it obvious? Those existing APIs have known performance characteristics and deep integration into several other libraries. The moment you custom-roll your own root library, you break integration with all existing other libraries that depend on the defaults. To add, your LLM has to think about your new custom version rather than looking at the billions of lines of examples using the one it already knows works from decades of historical data.
If you really, really need some ultra-micro-optimization, you’re obviously not the target of this; but unless you’re doing HFT or the most inner loop of a game engine, the standard library and all its deep integration and battle-testedness is worth the 1% perf hit.
How many times has the stable and established X surprised you with some unexpected behavior?
Once upon a time I wanted a URL /like/this/with%2Fslashes/ where a path parameter could, in rare cases, contain an encoded slash. Legit according to every RFC I checked. Works fine in browsers. But I couldn't get the web server to not convert it to a / before hitting my code. And woe betide thee who wants to make nginx return a custom error code 444.
How many times have existing APIs made by experts in their fields had bugs.
How many of those are you willing to let your own services and your customers’ data be hit by whole classes of bugs that battle-hardened APIs have already fixed?
You sure you can get an LLM to handle every single one of them on first pass? Would you stake your company reputation and the PII of all your customers on it?
See now, we keep assuming without evidence that the old thing is actually better.
Sometimes it's true. I don't trust myself to write a non-trivial DBMS. I reach for Postgres. And there are some things I just don't want to do - like any kind of cryptography or compression. (I also wouldn't trust myself to avoid cryptography side channels.)
But existing APIs tend to do a lot more than you want, and that brings its own bugs. Consider the sqlite WAL-reset bug that Tailscale found when it corrupted several tailnets' control plane data. They were using a separate database file per network and a custom backup system too clever for its own good. How much control plane data do they have in a network? I'd imagine under a megabyte. They could have written the entire thing in JSON and committed with an atomic rename, and not had the bug. (On the other hand they could've used a single large Postgres.) I don't fault them for the corruption as sqlite is normally extremely reliable, but it just shows how adding things to a system can make it worse.
Or any reverse proxy when you do an HTTP Request Smuggling attack. If you hadn't used a reverse proxy, you wouldn't have been vulnerable because the attack is only relevant to reverse proxies (and forward proxies). Do you need a reverse proxy? Sometimes yes but other times no. You can also prevent that attack by using SCGI, FastCGI or WSGI instead of HTTP as your backend protocol.
I bet there's at least one vulnerability caused by X-Accel-Redirect processing, too.
Remember Log4Shell? The Log4J library had too many features, and some of them could be combined in an unintended way to cause remote code execution. Code worked exactly as intended, it just had too many features. You don't want that.
Remember Heartbleed? The old "battle tested" system turned out not to be.
RFC 3986 treats %2F as a reserved character that behavior becomes app specific.
Agents can’t one-shot the problems that boring technology solves. So I think your first premise is mistaken. There is no trivial “just DIY” option for Postgres or Django or Kubernetes.