> just give a shell script to a LLM and ask it to add concurrency where needed.

You know, I personally consider the whole LLM revolution a sort of indictment of our whole industry up to this point. We had more than thirty years to figure out and make robust, composable, reusable building blocks, that would not require fiddling and filing away the sharp edges and writing megabytes of gluing boilerplate code — and we failed. Miserably. So now LLMs come in and finally give us the reusability in a very brute-forced kind of way: by being able to regurgitate those pieces of software, slightly adjusted to the context as needed.

So. In a sane world, the shell would already have a bloody "par" builtin that would deal "with piping for example but also how to behave when one subshell fails, how to cleanly interrupt everything if one fails, etc." out of the box, without additional fuss — but we don't. Well, we do have GNU parallel, but frankly, almost nobody knows about, or gives a damn, about anything that's beyond the GNU coreutils. Like, have you heard of e.g. GNU stow? Apparently it's been a thing for decades.

Anyway. We're not living in the sane world, so instead of a simple, robust, widely available built-in tool for parallel execution, we have dozens of little bespoke homegrown systems, cobbled together from xargs, jobs, pid- and lock-files lying around, and goodness knows what else, all of them mostly working 95% of the time but subtly broken in different subtle ways 5% of the time... and so the advent of LLMs which you could just ask "hey, here's the shell script, just parallelize it", and then get the working output in a minute, was a godsend. Of course it was! But that's because most of our software is barely fit for human use and consumption.