This is a really good point that I definitely failed to grasp when first hearing about these tools. At least for me, the best way to use these tools is as a way to free myself from having to spend time thinking about the things that aren't worthwhile so I can focus on the things that truly are. I've had times in my life spending hours reading documentation and googling random things to try to tease out the correct sequence of commands or the exact right shape of an API to be able to make things work to know that it doesn't make me more productive to do that myself rather than point an LLM at the thing and let it spit out the answer after a few minutes. Meanwhile, I can spend that time thinking about what comes next, or what the correct way to take that one-off output and abstract it to something that can be used meaningfully in more flexible ways.

The only obvious objection I can think of to this line of thinking (at least from a technical perspective) is "how does someone build up the knowledge to be able to use a tool effectively in that way if not by doing things by hand at first?" The honest answer that is "I don't know, but that's also pretty much exactly the type of thing my employers have never been paying me to solve in the first place". Even just a decade into my career, there have already been plenty of times in my career I've struggle to convince people that we should do stuff in a way that won't bite us in the ass a month or two down the line, and in the times I've managed to succeed, it's usually only by putting in more of my own time and effort to make the initial investment seem more palatable. Luckily right now I'm not in one of those times when I'm having to go full throttle to keep the lights on a few months from now, but I don't have enough fuel in reserves to work on a plan for when we need to build a new rocket in another ten years. Maybe ask me next month.