Note
Deterministic where possible
A useful boundary for AI systems is to keep judgement in the model and move invariants, validation, and repeatable transformations into code.
LLMs are useful precisely because some software tasks are not cleanly specified in advance. They can interpret ambiguous language, compare competing explanations, and make context-sensitive judgements.
That does not mean the surrounding system should also be probabilistic.
A useful default is to ask which parts of a workflow have an answer that can be deterministic. Schema validation, state transitions, retry budgets, permission checks, calculations, exact matching, formatting, and idempotency are usually better represented as code or data constraints.
The model then operates inside a narrower role: interpreting evidence, proposing a plan, classifying an uncertain case, or explaining a trade-off.
This boundary does two things. It reduces the number of behaviours that need prompt engineering, and it gives evaluation something stable to hold on to. A model can still be wrong, but the system around it does not need to be vague as well.