Where a person should look
Some of the work can safely run on its own. Some of it needs a person before it counts. The aim is not to check everything, which wastes the little review time you have, nor to check nothing, which is how expensive mistakes slip through. It is to put the checking exactly where it changes the outcome. The wider set of decisions this sits inside is Prompt engineering with Claude.
Some of the work a system does can safely run on its own. Some of it needs a person to look before it counts. Deciding which is which is a design decision, set by the cost of getting it wrong. A low-stakes guess can run unchecked, while anything where a mistake is expensive earns a human, or a fresh separate review pass, in the loop. The aim is not to check everything, which wastes the limited time you have, nor to check nothing, which is how costly mistakes slip through. It is to put the checking exactly where it counts.
The trap to avoid when judging whether something is safe to leave unchecked is a single overall score. A system that is 97% accurate on average can be near-perfect on most of its work while quietly failing on one slice, whether one kind of input or one particular field, so the average hides it. That is why you check accuracy in slices, by type and by field, not just as one number. Letting a part run unchecked is then earned slice by slice, only where it has proven itself, rather than granted across the board off a flattering average.
Say it another way
Think of a head chef at the pass on a busy night. There is not time to inspect every plate. The dishes from cooks who have proven themselves go straight out, but anything the line flags as doubtful, or where two cooks disagree over whether it is done, gets pulled for the chef to check. The chef’s attention lands only where a decision is actually needed. The rest of the service flows.
With that in hand, the rule for a person’s time is simple: send them only the cases that are genuinely in doubt. The work the system is confident about and that has no conflict in it flows through. What gets pulled for a human is the low-confidence work, or the cases where two sources disagree even if each looked sure on its own. That way the limited review time lands on the handful of cases where a person actually changes the outcome, not on re-checking the easy, certain ones.
One last thing: letting a part run unchecked is never set and forget. The data flowing in keeps changing, new formats, shifting quality, fresh edge cases, so a part that was safe when you validated it can drift. You keep checking a small sample of the automatic work over time, as an early warning, so a slow slide is caught long before it becomes a widespread problem.
Doing this with Claude Code
When part of a build can run without a person, set up the checks on purpose rather than trusting it blindly.
Ask for a confidence on each part. Have the model return how sure it is per field, not one score for the whole thing, so you can act on the doubtful parts without holding up the rest.
Route only the doubtful work to a person. Send the low-confidence or conflicting cases for review and let the confident, clear ones through, so limited attention lands where it matters.
Earn automation slice by slice. Check accuracy by type and by field before you stop reviewing a segment, so a weak slice cannot hide behind a good average.
Keep sampling after you automate. Spot-check a sample of the automatic work over time, because the inputs drift, so a part that was safe yesterday is not guaranteed safe tomorrow.
Back to Prompt engineering with Claude. The craft around it is Working with Claude.