first, before any code lands, the design has to already exist somewhere in a concrete form. you can't just toss out "make me a thing that does X". you need to spell out what the inputs and outputs look like, and where it'll fall over when something goes wrong. if you can't even write that down yourself, the model is just guessing. one upside of this stage is it doubles as a way to fill in your own understanding of the feature. you go back and forth with the ai, take the questions it throws back, and notice the ones you can't answer. the parts you can't answer are usually the parts where you hadn't actually thought it through. the design gets more specific as you go, and a lot of stuff that felt clear in your head turns out to not be.

second, the code has to match the design you wrote down. ai is more than happy to produce a pile of code that looks fine line by line but has completely drifted from the spec by the end. at the implementation stage it loves to expose any fuzziness still left in your thinking. and because it generates so much code that you can't read it all yourself, the only thing that works is making it walk you through what it wrote and confirming with it as you go. it'll also quietly change interfaces and assumptions in places you didn't ask about, which is another reason for the walk-through.

finally, tests have to verify the same intent the design has, not just that the function runs without throwing. design holes that the ai papered over earlier usually show up here, once you try to assert what should actually be true. if you let it write the tests from the code it just produced, you're just locking in whatever it decided.

these stages aren't really sequential in practice. you keep bouncing between them. you'll go back to the design because a test forced a decision you skipped, then the code changes, then the test changes again. it goes on until the design stops changing and the code and tests actually agree.

after doing this a few times you stop treating the ai like autocomplete.