Determinism vs. judgment
Every step in an AI-assisted workflow answers one question: does this need to happen the same way every time, or does it need to be figured out? A script always runs. A model usually listens. Most of what goes wrong in agent setups traces back to confusing the two. Most of what goes right traces back to keeping them straight.
The two failure modes
Section titled “The two failure modes”There are exactly two ways to get this wrong, and they’re mirror images.
A guarantee you asked a model to keep. You write “never commit directly to main” into your instructions file and consider the matter closed. It isn’t. That line is advice, and the model treats it as advice: it holds most of the time, then bends exactly when you can least afford it. Anthropic’s guidance on steering Claude Code is blunt about this: anything the model merely reads is advisory. It degrades under pressure, drifts in long sessions as the context fills, gives way to ambiguity, and can be actively subverted by prompt injection. The failure is quiet. Nothing errors. The rule simply doesn’t fire, once, on the day it mattered.
Judgment you hard-coded into a script. The mirror image: you write a regex to decide whether a change is “risky”, a keyword filter to decide whether a message is “urgent”, a line-count threshold to decide whether a diff needs review. The script runs every single time, and is confidently wrong at every edge you didn’t anticipate. Determinism is not correctness. A script guarantees the procedure, not the judgment call, and a judgment call frozen into code is just a guess that can no longer learn.
The spectrum
Section titled “The spectrum”Real workflows are a spectrum from fully scripted to fully reasoned, and the craft is placing each step where it belongs. The two ends have sharply different characters:
| A script (deterministic) | A model (judgment) | |
|---|---|---|
| Behaviour | Same input, same output, every time | Reasons over context; output varies |
| How it fails | Confidently wrong outside the cases you wrote | Quietly skips the rule under pressure |
| What it’s good at | Enforcing, blocking, formatting, counting, gating | Ambiguity, novelty, intent, taste |
| What “it works” means | Proven once, holds forever (until the world changes) | Holds usually; verify per run |
| Ask it to | Guarantee that X happens | Decide whether X should happen |
Read the second row twice. The failure modes are different, and each is tolerable in exactly the place the other isn’t. A linter that misses a subtle design flaw is fine; you have review for that. A reviewer who sometimes forgets to run the tests is not fine; you have a script for that.
The rule of thumb
Section titled “The rule of thumb”Ask: could you write the check as code a junior colleague would follow literally, with no “use your judgment” step anywhere?
- If yes, write it as code. A hook, a CI check, a validation script. Don’t spend a model’s variability on something a script does perfectly, and don’t spend your tokens on it either.
- If no (the instructions genuinely require understanding intent, weighing trade-offs, reading between the lines), give it to a model. Then treat the output as a draft to verify, never as a guarantee kept.
The corollary cuts the other way: if you find yourself writing ever-longer prompt rules to force consistent behaviour (“ALWAYS…”, “NEVER…”, “IMPORTANT:…”), stop. Escalating the phrasing doesn’t change the mechanism. A sterner sentence won’t fix it. Move the rule out of the prompt and into something that executes.
Own your control flow
Section titled “Own your control flow”The production pattern that falls out of this model is well established: reliable agent systems are mostly deterministic code with model steps placed deliberately inside it, not a model improvising the whole pipeline. The 12-factor agents principles put it as “own your control flow”: you decide the structure of the loop (what runs, in what order, what gates what) in ordinary software, and you call the model for the specific steps that need reasoning. The model makes calls inside your structure. It doesn’t get to be the structure.
One sentence to keep
Section titled “One sentence to keep”A rule only a model reads is not a guarantee. It’s a well-phrased hope. Guarantees live in code that executes; judgment lives in models that reason. Knowing which one you’re holding, at every step, is the most portable skill in building with AI.
The practical machinery (skills, hooks, agents, CI, and which mechanism actually enforces what) is the next page.