Where a person should look
Some of the work a system does can safely run on its own. Some of it needs a person to look before it counts, and deciding which is which is a design decision set by the cost of getting it wrong. 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 Ways to run it for real.
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.
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.
Common questions
- Why is one overall accuracy score the wrong thing to look at?
Because an average can look fine while one slice is quietly failing. A system that is 97% accurate overall can be near-perfect on most of its work and failing badly on one kind of input. - How should accuracy be measured instead?
In slices. Per document type, like typed invoices versus handwritten ones, and per field, like the date versus the total, so a weak slice cannot hide behind a good average. - Which cases should go to a person?
Only the ones genuinely in doubt: the low-confidence work, or the cases where two sources disagree even if each looked sure on its own. Everything the system is confident about flows through. - Why not just check everything?
Checking everything wastes the little review time you have, and checking nothing is how the expensive mistakes get through. The aim is to put the checking exactly where it changes the outcome. - Once a part is running unchecked, is it done?
No. Automating something is never set and forget. Just because it worked today does not mean it keeps working, because the source systems and the data flowing through them are not frozen. - So how is automation earned?
One segment at a time. Switch off the human only for the segments that have proven themselves and keep a human on the ones that have not, rather than granting it across the board. - What do I do after a segment is automated?
Keep spot-checking a small sample of the automatic work as an early warning, so a slow slide is caught long before it becomes a widespread problem.
Back to For developers. The craft around it is Working with AI.