> code is just a means to an end?

Exactly. Which is the reason why code that increases maintenance friction and costs, or decreases the product's operability or fitness for purpose, does not properly serve the end of advancing the business. Not in competitive industries anyway.

There's this whole manufactured narrative going on geared toward reframing the quality of code design and structure as an aesthetics problem. If you think code design and structure is an aesthetics problem, you will not understand the pushback.

A much more interesting question, I think, is why bad AI code is perceived as a worse problem than bad human code.

My observation is that bad human code ultimately slows down its own maintenance: the speed at which the human can add bad code decreases as the human adds more bad code. So it's a self-limiting problem. Whereas AI will quickly and efficiently add extra layers of bad code to work around the issues introduced by its own earlier bad code. If you let that go on, you can end up in runaway complexity scenarios where only AI can maintain the code at all, until even it can't. There have been a lot of arguments on HN that such scenarios are not a problem because AI will keep getting better, but to me this amounts to a Ponzi scheme for tech debt, which I find undesirable.

And that's not to even mention the externalities.

So, basically, depending on whether you care about all of the above, or not, the machine that supercharges your LoC-per-day metric will be seen as a good thing or a bad thing, and it's not a divide that can be reconciled because it boils down to what individuals care about. We can all agree about the end of writing code, but that doesn't mean you can't be wrong about the ways to get to that end, I guess.