Earlier quoted context omitted.
I'm like 60% there with you: * When it gets the design wrong, trying to talk through straightening the design out is frustrating and often not productive. * I've learned to re-prompt rather than trying to salvage a prompt response that's complicatedly not what I want. * Exception: when it misses functional requirements, you can usually get a session to add the things it's missing.
Here's the thing, though. When working with a human programmer, I'm not interested in their code and I certainly don't want to see it, let alone carefully review it (at least not in the early stages, when the design is likely to change 3 or 4 times and the code rewritten); I assume their code will eventually be fine. What I want from a programmer is the insight about the more subtle details of the problem that can on…
I tend to do a fine tune on the reviews they produce (I use both along with CodeScene), but I suspect you'll probably luck out in the long term if you were to just YOLO the reviews back to whatever programming model you use.