I have never once said "Go build feature x" and let it run off. Not saying you do, but I feel like this is how a lot of people interact with these tools. I have a very conversational style of building with these tools, and I'm very blunt with them when I think they're wrong, since I'm fairly experienced and I can smell when something is seemingly wrong with the model's thinking.

I typically have a discussion about how I want the architecture to be and my exact desired end state. I make the model repeat back to me what I want and have it produce the plan to the degree I am happy with. I typically do not have it work in building large amorphous systems, I work with and have it plan subsystems of the overall system I'm building.

A lot of my discussion with the model is tradeoffs on the structure I'm imagining and methods it might know. My favorite sentence to send Claude right now "Is go google this." because I almost never take its first suggested response at face value.

I also watch every change and cancel and redirect ones I do not like. I read code very fast and like the oversight, because even small stupidities stack up.

The workflow is highly iterative and I make changes frequently, my non AI workflow was like this too. Write, compile, test, tweak and repeat.

I like this workflow a lot because I feel I am able to express my designs succinctly and get to a place I'm happy with with much less writing than a lot of the actual code itself which in many cases is not an interesting problem, but work that needs to happen for a working system at all.

I do wind up taking over, but feel less than I used to, in edges where its clear there is not a lot of training data or I'm working on something fairly novel or lower level.

I work in Python, Rust and Typescript (Rust by far most often) and the majority of my work is technically challenging but at the systems design level maybe not low level systems programming challenging. Think high concurrency systems and data processing, training models, and some web dev.

To add to this, I find talking to it about code quality or architecture issues can work quite well. Just treating it like another developer. Saying, “I’m not happy with the way the project is going because of X, and Y” and then making a plan for how to get things back on track. Maybe putting a complete rewrite on the table, or maybe just having it record the agreed code style principles in CLAUDE.md, etc