The core thesis of this essay is reminiscent of the Lisp Curse [1] / Bipolar Lisp Programmer [2].
It's been a few years since I read these, but if I recall the argument there, it was that Lisp makes it so easy to build stuff and scratch exactly your own itch, that there's no real strong push for lisp programmers to come together and collaborate to build non-trivial and general purpose artifacts. And that is why the landscape of public lisp software is poorer as a result, compared to languages which demand much more effort to get anything substantial done.
Armin seems to be making a very similar point about AI coding.
[1] https://www.winestockwebdesign.com/Essays/Lisp_Curse.html
> compared to languages which demand much more effort to get anything substantial done.
It is not clear at all to me that other languages "demand much more effort" for the same end result.
It is clear that many non-lisp programmers value syntax, and many lisp programmers don't. Even many people who programmed enough lisp to have their minds blown and expanded still prefer not to program in lisp. I'm still awaiting psychological studies on this, but the rift is so large, I think there may be some significantly different brain processing going on between the two groups.
To your point, yes, it is also clear that, to the extent that lisp can match the productivity of other languages, whether it exceeds them or not, one of the tools that is needed to achieve this productivity boost in lisp is heavy usage of homoiconicity, and this results in every serious lisp program being a collection of DSLs, each of which is only understood by one person or very few people.
Au contraire if typescript and rust didn’t steal the whole show it’d be a great time to be a lisp LLM pilot: agents can explain pretty much everything without any confabulations nowadays, so the understanding problem essentially goes away, if you care, which is exactly the point of the article if you ask me.