I generally don't know where in the code to "defend" until I've actually written the algorithm -- I don't start writing during whiteboard coding or coding sessions with a solution in mind, I start with the first (okayish) thing to come to mind and iterate from there as I run into problems or edge cases. (Example: do I need to guard empty lists or not? Well, it depends on if I for-all over the list or try to index explicitly.)

So in terms of writing flow, it usually goes something like core work function/code, often as helper functions -> control flow structure -> guarding, edge cases, etc.

This also works well for a conversation: how do we model/solve the core problem? how do we want this to actually execute? what are our constraints, special cases, etc? You're moving from the general (abstract problem) to the specific (guarding bugs in my code).

This has worked out reasonably for me.