Comment by tptacek
3 days ago
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 only be gained by coding. I want them to tell me what details I missed when I described an approach. In other words, I'm interested in their description of the problems they run into. I want their follow-up questions. Do coding assistants ask good questions yet?
No, they don't, but our preferences differ sharply there! I definitely do want to read code from teammates.
You can ask it to critique a design or code to get some of that - but generally it takes a “plough on at any cost” approach to reaching a goal.
My best experiences have been to break it into small tasks with planning/critique/discussion between. It’s still your job to find the corner cases but it can help explore design and once it is aware they exist it can probably type faster than you.
Get Coderabbit or Sourcery to do the code review for you.
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.
> * When it gets the design wrong, trying to talk through straightening the design out is frustrating and often not productive.
What I have learned is that when it gets the design wrong, your approach is very likely wrong (especially if you are doing something not out of ordinary). The solution is to re-frame your approach and start again to find that path of least resistance where the LLM can flow unhindered.