Doing "more" of the same, throwing more bodies at it, rewriting the world
    because your UI or ORM needs a reboot, trying to attach checksums and
    technical proxies for dependencies as a substitute for the basic fact that
    you need to know what code you are running and why to be a responsible
    software vendor; none of this will work.

You're assuming that the "bodies" being thrown are going to continue to be human. But what if they aren't? We've already seen what can be done with the very early, relatively primitive AI programming assitants that we have today. What happens when we're competing against an army of Java/Python/Go programmers, all of whom have extensive AI assistance?

I love Lisp. All Lisps. Common Lisp. Scheme. Clojure. Even elisp. And, for a long time I thought Lisp was the future. I thought, like you, that the ever expanding size of codebases written in more conventional programming languages would necessitate a switch to something more functional and more amenable to building non-leaky layers of abstraction because that would be the only way to continue to build without introducing at least one bug for every new feature.

However, the advent of LLM powered coding assistants (like OpenAI's Codex, or Github's Copilot) has made me reassess my view. LLMs benefit from having more training data. Now, the thing that I thought would kill Java/Python/Go codebases, i.e. the sheer number of lines of code required to do even the simplest thing, turns out to be a strength. Because each line (and all its variants) now represents a datum point in the training set for the AI.

Can Lisp be enhanced with AI support. Sure it can, in theory. But in practice, there's far less Lisp code out there. Primarily this is because far fewer people use Lisp on a regular basis. But it's also because, for any given task, far less code is required to accomplish it. Just like Java's greatest weakness turned out to be a strength in a world where we have AI assistance, Lisp's greatest strength turns out to be a weakness.

I'm going to continue to use Lisp wherever I can. If not at work, then in my projects at home. But I'm far less sanguine today about the eventual dominance of Lisp (and Lisp-like languages) than I have been at any time in the past.