Surely there has to be some level of "getting stuff done"/"achieving a goal" when /making/ things, otherwise you'd be foregoing for-loops because writing each iteration manually is more fun.

I think you misunderstand the perspective of someone who likes writing code. It's not the pressing of keys on the keyboard. It's figuring out which keys to press. Setting aside for the moment that most loops have a dynamic iteration count, typing out the second loop body is not fun if it's the same as the first.

I do code golf for fun. My favorite kind of code to write is code I'll never have to support. LLMs are not sparking joy. I wish I was old enough to retire.

I have a 10-year-old side project that I've dumped tens of thousands of hours into. "Ship the game" was an explicit non-goal of the project for the vast majority of that time.

Sometimes, the journey is the destination.

Sure, but, in the real world, for the software to deliver a solution, it doesn't really matter if something is modelled in beautiful objects and concise packages, or if it's written in one big method. So for those that are more on the making /things/ side of the spectrum, I guess they wouldn't care if the LLM outputs code that has each iteration written separately.

It's just that if you really like to work on your craftsmanship, you spend most of the time rewriting/remodelling because that's where the fun is if you're more on the /making/ things side of the spectrum, and LLMs don't really assist in that part (yet?). Maybe LLMs could be used to discuss ways to model a problem space?