Absolutely. And ironically one thing I discovered while trying to use AI is that it applies to programming too.

I'd heard that one-shot a project with AI, you need a fairly complete design document instead of a short prompt, so I tried to write one.

In doing that, I'd include the unhappy paths as well, e.g. in describing a list/detail interface: the list shows the X's (I thought: but in what order?) in alphabetical order; when an X is selected, the detail is displayed in the detail pane; (lists should work with multiple selection, so) multiple items may be selected at once, in which case the detail pane should display "N items selected" instead of the interface to edit the items; (a list starts empty, so) if no items are selected, the detail pane should display "No items selected", etc.

Laying out the entire system in plain English helped me have the whole thing inside my head, and see cases where presumptions about how the system would work wouldn't actually hold in practice because they weren't even holding in the text I was writing. So I had to edit the draft to fix my wrong assumptions until it made sense.

And of course the AI managed to do a pretty terrible and disappointing job at it in the end, because it made mistakes in the parts I didn't specify, or placed widgets in the wrong places because the layout that was difficult to explain in text, etc. It's somewhat impressive that anything ambiguous is a spot where AI can make the worst assumption imaginable, like it doesn't have the capacity to intuit "oh, we are making THIS sort of app, so it should look like this". But it was a good learning experience.

I suppose it's a great idea to write out what you're about to do before you set out to do it, because it helps you think about it in whole and in detail. It would be terrible if people stopped doing that.