The following does
not answer your question. I am me; I'm not "the HN crowd", if there is even one. And if there is such a crowd I wouldn't be the one knowing what it thinks.
The following is only a perspective on the argument of "the product works" and what "code elegance" means. I don't really care much about LLMs but the following is not necessarily tied to them.
Also, I'm retired from professional programming so feel free to ignore all of it as antiquated and irrelevant.
---
Code is not really "a means to an end". Code is better described as a liability.
People you write code may have different perspectives on code but those with more experience generally end up with this idea engrained in their minds. Code is a cost.
Thus, you'd want to have less of it, and you'd want to have code which:
- you at least have some grade of confidence that you can understand as deeply as possible, because that means you can maintain it better and more efficiently. It means that you can, when if fails, quickly/easily find where it failed, sometimes even why it did.
- you can manage in its entirety, which becomes exponentially more difficult when there's more of it and you didn't write it yourself. Not only that, it becomes more difficult to manage it when it has been incorporated in very large chunks that reach all over the codebase, and it becomes a lot more difficult when it lacks consistency, coherence and a certain uniform style.
What you call "the elegance of code" is not an aesthetical quality but a practical one. A developer obviously wants to have something that works, but that it does so well, reliably well. And they want code that is manageable enough that when shit happens -and it always does-, the fix will be hopefully easier and will hopefully make the resulting code more reliable, not less.
And, sure, in some circumstances development speed does matter. The problem is that the circumstances in which it does are frequently "unwanted" ones, usually external pressures, which we already disliked. Usually, you need to develop faster because someone else is pressuring you into putting that speed above reliability, not because it is intrinsically better to do it faster.
The one acknowledged situation in which development speed is tolerated above these other qualities is when doing a prototype. But then again, experienced developers know that prototypes can very easily turn into traps. When doing a prototype, quality is relegated because it is understood that this will not be the final product. It is understood that a prototype's code is disposable. But too often prototypes then become either the product directly or the basis for it. And again this happens because of external pressures. Most of the time because someone says "hey, it's working" without realising that it is barely so, that it's fragile, that it relies on constant tweaking and manual adjustment. But as it appears to be working, it gives the impression of being good enough to make financial sense to build on it.
And when you "ship version 2.0 at an incredible pace" what you're usually doing is shipping prototype 2.0, an unreliable system that requires more constant tweaking and manual adjustment. A system that entraps the developers into more maintenance on each iteration, when they'd want the opposite.
---
All in all, using LLMs to produce code may have its place. But if you focus on the idea of producing vast quantities of it faster, then that may not be the best use.