This article has a narrow view of "making" which is stuck hopelessly in the past, in my honest opinion. A human in the loop guiding the process is 100% making something, no matter how much you torture the definition of "make."
When I write software with Claude, I'm the one with the agency, not Claude. Without me, the software wouldn't even exist. A director "makes" movies. A collage artist "makes" images. A fisherman "makes" a catch. Someone searching YouTube and clicking on a video "makes" a video. These are widely agreed upon definitions, so it should not be controversial to say you "make" software with LLMs.
Someone clicking on a YouTube video makes that video?
But the author doesn't feel like they are making it.
I feel the same way if the agent moves too quickly. If I ask for a feature in high-level language the LLM will make many guesses and assumptions to carry that out. I don't feel like I'm involved in the creation of that software at all. It feels more like running a find and replace on someone else's code to make it to what I want.
That's why I instruct the LLM at a low level, that is at the level of the code itself. I'll ask for refactors, I'll ask for a new class etc. This cuts down on time spent typing while I still remain on top of the code.
At least that's the idea. But there's still a problem. LLMs are trained to want to write working code. If what you asked for won't work, it'll just fill in the blanks and guess to make it work. And then you don't feel like you made it again.
Basically, we kid ourselves into thinking it's just a supercharged text editor that we control, but it's actually an LLM that just doesn't work that way.
"I made this company goddamnit, I made all of the iPhones because I had my VPs build factories in China that make iPhones." - imaginary Steve Jobs