While probably not useful for everyone, the best method for myself actually leverages that. I am using a modified form of TDD's red/green refactor, specificall

While probably not useful for everyone, the best method for myself actually leverages that. I am using a modified form of TDD's red/green refactor, specifically with an LLM interface independent of my IDE. While I error on good code over prompt engineering, I used the need to submit it to both refine the ADT and domain tests, after creating a draft of those I submit them to the local LLM, and continue on with my own code. If I finish first I will quickly review the output to see if it produced simpler code or if my domain tests ADT are problematic. For me this avoids rat holes and head of line blocking. If the LLM finishes first, I approach the output as a code base needing a full refactor, keeping myself engaged with the code. While rarely is the produced code 'production ready' it often struggles when I haven't done my job. You get some of the benefits of pair programming without the risk of demoralizing some poor Jr. But yes, tradeoff analysis and choosing the least worst option is the part that LLM/LRMs will never be able to do IMHO. Courses for horses and nuance, not "best practices" as anything more than reasonable defaults that adjust for real world needs.