It is useful to know the level of how "hands-off" to specify directions for each task. With some experience one can learn when to specify the high level require

It is useful to know the level of how "hands-off" to specify directions for each task. With some experience one can learn when to specify the high level requirements, and when to stop and think about the problem at hand. For example, with frontend, I can get an LLM to design half a page 80% to my satisfaction with two paragraphs worth of a prompt. "It should look like so, and have a text box here, and room for a demo there". With ML training or backend or user-facing code, I might instead spend a paragraph thinking out my design intentions for a single function or even a single line, more for myself than the LLM. A harness generates a plan based on that paragraph, which one can then comment on and review the pseudocode it provided, ensuring it aligns with expectations. Lastly have the LLM output some sort of documentation and "here's what I did" after each change. Your final step is to handwrite (paraphrasing what it gave) into any docs or commit messages, and ensure your commits are small enough to keep this maintainable. Paraphrasing the LLM, rather than the LLM paraphrasing you, is helpful to ensure the commit messages make sense to you three months from now.