> It doesn't have to be a single sentence, I write a whole paragraph or even pseudocode most of it and tell it to use the pseudocode as comments for the code it will produce. It'll give me a plan and I'll refine the plan until it seems to be what I want. Then we'll get it to start writing and I'll give it feedback and keep it on track. If it tends to overthink a problem, I'll interrupt it and have it talk over the issue, until it gets a clear understanding of what I want.
That sounds like programming with extra steps.
Here's my No-AI workflow: I read the requirements and devise pretty much instantly have a solution. I Check the web/manuals/docs/source code for missing information so I can refine the solution from a hunch to an implementation plan. This can be pretty fast or can be the slowest part. I start coding, building a small subset that work and iteratively adding on top, feeling the design as I go, refactoring if necessary. Then after testing, I send it to review.
The "finding information" part is the most important one as accuracy is paramount. And for most AI workflows, it seems that's very much an afterthought.
The "coding" part is the relaxing one, except for a few moments where some nuggets of information are lies or misleading. Again, there's no practice to catch those in AI workflows.
If you have a good testing methodology in place, the last part can be fast tracked, where you mostly scanning for bad practices and modifications to important areas. Again in AI workflows, you see that either they rely on preexisting test suites (the big rewrites), or mostly trust the generated suite with no evidence that it's actually suitable.
The questions I have are: How do you ensure the accuracy of the software's model of the domain? And What do you do to retain the knowledge of that model (as in you have a good intuition of the current behavior of the software or at least can easily locate the code responsible)?