It really depends on th SDLC of the codebase. I've sat in the park with a pad and pen and wrote down ideas for a small-ish utility that had both a DB and some low level systems interaction. I designed all the interfaces, control flow, and user facing ui. A decade ago I was designing class diagrams with public and private methods, then coding it up. Today I can articulate it with loose words and have it come to life.

The secrete ingredient here is... Im an experienced programmer, I know what to ask and what to look out for. I know sockets and how devices work under the hood and which knobs are available for me to turn. Juniors just don't have enough experience. The question should really be "what do inspiring programmers do?"

Debugging. Lots of debugging. It will be interesting when the researchers look back in 5-10 years to determine which was easier/better - trying to understand generated code vs generating code one understands.

If a functional reasoning layer is added to the current lookup level, “do you want fries with that?” might be in their “doing”. If this doesn’t appear in a timely fashion, de-slopping code will be their lot.

Design. And redesign.

Probably dance.

Interesting question. I work on AI for document processing, and I have found the same dynamic: generating a first pass is easy, but the real engineering goes into the verification layer.

Edge cases you never think to test: that's where AI output breaks. I deal with this daily in document processing.

Compilers also write code (they write machine code based on high level langs)… yet nobody asked the same question about them (or did they?)

AI needs to be instructed and then some kind of verification of the output is needed. Programmers do that