Your Verification Budget Is Backwards
You can't check everything your agents produce, so you're already triaging. Most of us spend the effort where checking is easy, which is rarely where a mistake is expensive.
How this is checked Law V last tested Sep 2026
- Rests on
- Law V, The Targeting Problem. It has been put to a real test and amended or narrowed under that pressure. Last tested 2 Sep 2026.
- What would prove it wrong
- A system where capability aimed at a target that was a poor proxy for the objective (not a sufficient statistic), with the misfire undetectable or un-re-aimable, nonetheless produced sustained improvement rather than waste or harm. This is the law's test; the essay has no ledger of its own yet.
New here Press F to read with nothing else on screen. Save keeps an essay in this browser so it opens offline, and nothing leaves it. The bar at the foot of the screen holds text size and focus mode. Save keeps an essay in this browser so it opens offline, and nothing leaves it.
This morning an agent wrote two things for me. The first was a throwaway script that reshaped a table so I could look at last quarter’s support tickets by cohort. I ran it and read a few of the rows against the raw data. Fine. The second was a database migration that backfilled a new column across the whole users table. Tests passed. I read the diff, it looked like a sensible migration, and I merged it.
I spent real attention on the script. I gave the migration a read.
Look at why. The script I could check by running it and reading what it produced. The migration would have taken real work to check properly. Whether it was correct depended on what it would do to a few million rows I had not looked at, so I checked what I could see for free instead: whether the diff looked reasonable, whether it read like something I would have written.
That tells me the migration looks right. It does not tell me whether it is right, and the migration is the one where a mistake would be expensive to undo.
You already triage. You have to.
Count the agent outputs you touched yesterday. A dozen commits from a coding agent, a few research summaries, some drafts, a plan. Then count the minutes you had to look at each. The arithmetic does not close. Twenty outputs and a few minutes each means most of them shipped on a glance, and you chose, without ever deciding it, which ones earned more than a glance.
So you are already sorting your outputs into checked and unchecked. The only open question is whether your sorting is any good.
Mostly it is fine. You gate a production deploy harder than a throwaway script, and you are right to, because the deploy matters more and you can also test it. High stakes and a cheap check line up, so the effort lands where it should.
The corner where they come apart is the one that costs you. Some outputs matter a lot and have no cheap way to check: a judgement, a synthesis, a recommendation that rests on reading a situation. They arrive fluent, in your own domain, in the voice of someone who knows the field, which is the voice that feels safe to wave through.
That is checkability bias: attention follows how easy correctness is to establish, even when the cost of being wrong lies somewhere else. An earlier piece here named that cost in one line: checking gets expensive exactly where the model is most tempting to trust, so budget for the check.
Naming the cost is the easy part. The rest of this is how you spend the budget: how to price a check, where the first minute of attention goes and where the last one stops, and what to do about the outputs no check can reach.
Free download: The Looks-Right Trap. A one-page field card with the self-check: list the agent outputs you waved through, mark which you checked because it was easy versus because being wrong was cheap, and find your blind spot. Yours to keep. Get the free card →