Guaranteeing the steps that matter
Telling Claude to do something is a request, not a guarantee. It will usually follow a clear instruction, and usually is not always. For the steps that move money, delete something or go out to a customer, that gap is the whole problem. The way to close it is not a firmer sentence in the prompt, it is a check in the code around Claude that will not let the next step run until the one before it has genuinely finished. A prompt asks, code guarantees.
Say it another way
You do not padlock the salt cellar. If a cook over-salts once you remake one dish, so a quiet word is enough. But the till and the walk-in freezer are locked, with only a keyholder allowed in, because a mistake there, cash gone or stock spoiled, is expensive and hard to undo. You spend the lock only where the downside earns it. Enforcing a step in code rather than trusting the prompt is the same call: lock the things that would really hurt to get wrong.
Doing this with Claude Code
When a build has a step that must not go wrong, decide on purpose whether a prompt is enough or the step needs to be enforced.
Ask in the prompt for the cheap steps. Where a rare miss is easy to undo, a clear instruction is the right amount of effort. Do not gate everything.
Enforce the costly ones in code. For anything that moves money, deletes or goes out to someone, put a check around the action so the wrong order cannot physically happen, rather than trusting the model to remember.
Gate on the real result, not the claim. Have the guard read whether the step before genuinely succeeded, so an action never fires off the back of a step that errored or came back empty.
Hand off with the full picture. When something has to go to a person, pass the facts, the cause and your recommended next step, so they can act without piecing the story back together.
Notice what the asking costs. A rule you put in the prompt is charged every time it runs, where the same rule in code is paid for once. At any volume that gap stops being academic, so let it weigh on the choice rather than discovering it on a bill.
Common questions
- Should I gate every step?
No. A gate is effort and rigidity you do not always need, so spend it where the cost of getting it wrong is real. A slightly clumsy summary is cheap to fix, so a prompt instruction is the right amount of effort there. - Which steps are worth gating, then?
Moving money, deleting something, sending a message to a customer. Those are expensive or hard to undo, so a small failure rate stops being acceptable and the step gets enforced rather than trusted. The stakes decide the mechanism. - What should a gate actually check?
What happened, not what the model says happened. Take trusting that a backup was successful: just because the backup was done does not mean the backup was correct. The gate is keyed on the actual successful result, not just that the call ran. - What should happen when a step has not succeeded?
A process that has not completed successfully should block all the processes that depend on it, not only the next one in line. A result coming back is not the same as a result that worked. - What if a step cannot be handled and has to go to a person?
Hand over the whole picture, not a shrug. Someone picking the work up cannot see what came before, so a vague "over to you" makes them start from nothing or, worse, guess at it. - What goes into a good handoff?
The facts, what caused the work to stop and what you would suggest doing next. That way the person spends their time deciding rather than reconstructing what already happened. - Is there a bigger question underneath all this?
Yes. Some of what a system does needs judgement and the rest of it has a right answer, and those two want different machinery at very different prices. Telling them apart is When to use AI and when not to.
Back to For developers. The craft around it is Working with AI.