Comment by qsort

Yeah but this is exactly why using LLMs doesn't actually preclude problem solving. You still have to do all these things. You just don't have to physically type out as much code.

Yeah. LLMs make this a lot easier, is the thing.

Obviously I was referring to a hypothetical option where it's still your body that get stronger. Sticking with this metaphor - I don't care about the weights going up, but rather about my muscles getting stronger, and if there were an easier and less accident-prone way to do that without the weights, then I would take it in a heartbeat.

And going back to programming, while I sometimes enjoy the occasional problem-solving challenge, in the vast majority of time I just want the problem solved. Whenever I can delegate it to someone else capable, I do so, rather than taking it on as a personal challenge. And whenever I have sufficiently clear goals and sufficiently good tests, I delegate to AI.

I suspect you are in the vast minority. Most folks are moving weights around for the result feedback, the fitness. Similarly, a lot of engineers are writing code to get to the end result, the useable product. Not writing code to be writing code.

> Complex argument parsing is something that I'd only generally be doing in python, which is handled by the argparse library.

Yes, I'm referring to argparse. If you had to write a new script every few days, each using argparse, would you enjoy it?

argparse was awesome the first few times I used it. After that, it just sucks. I have to look up the docs each time, particularly because I'm fussy about how well the parsing should work.

> otherwise write it once and then copy it to use in other projects. Same with loggers.

That was me, pre-LLM. And you know what, the first time I wrote a (throwaway) script with an LLM, and told it to add logging, I was sold. It's way nicer than copying. Particularly with argument parsing, even when you copy, it's often that you need to customize behavior. So copying just gets me a loose template. I still need to modify the parsing code.

More to the point, asking an LLM to do it is much less friction than copying. Even a simple task like "Let's find a previous script where I always do this" seems silly now. Why should I? The LLM will do it right over 95% of the time (I've actually never had it fail for logging/argument parsing).

It is just awesome having great logging and argument parsing for everything I write. Even scripts I'll use only once.

> Depends on how I'm extracting input from a config file, what kind of config file, etc. One of my favourite things to do in programming is parsing file formats I'm not familiar with, especially in a white-box situation.

JSON, YAML, INI files. All have libraries. Yet for me it's still a chore to use them. With an LLM, I paste in a sample JSON file, and say "Write code to extract this value".

Getting to your gym analogy: There are exercises people enjoy and those they don't. I don't know anyone who regularly goes to the gym and enjoys every exercise under the sun. One of the pearls of wisdom for working out is "Find an exercise regimen you enjoy."

That's a luxury they have. In the gym. What about physical activity that's part of real life? I don't know a single guy who goes to the gym and likes changing fence posts (which is physically taxing). Most do it once, and if they can afford it, just pay someone else to do it thereafter.

And so it is with programming. The beauty with LLMs is it lets me focus on writing code that is fun for me. I can delegate the boring stuff to it.

That's all fine and good, but there is always boilerplate that you can't design away.

Even the most succinct cli command definition and argument parsing library you could devise is going to require a bunch of option name definition.

It's just a fool's errand to think you can stamp out everything that is tedious. It's great that we now have tools that can generate arbitrary code to bridge that gap.