The answer is the cheap part
When drafting became cheap, the scarce thing stopped being the answer and became the reviewer’s minute. Here is what that changes about the screen.
When a model can draft anything, the expensive part of an AI feature stops being the output and becomes the review. The interface’s job changes with it. It is no longer to present the answer well, it is to let a person disprove the answer fast. That means showing the number they will actually get, the path that produced it, and the cheapest possible way to disagree.
Most AI features I see are still designed as if the answer were the scarce thing. It stopped being scarce about two years ago.
01The expensive step moved
For most of software history, generating a first draft was the costly part. A research report, a repair estimate, a radiology read, a design spec: each took a trained person hours or weeks. Software matched that shape. It gathered inputs, it waited, it presented the result well.
Now the draft costs a few seconds and a fraction of a cent. What did not get cheaper is the part where somebody decides whether the draft is right.
Here is the shape of the problem, and it is worse than “review takes time”. A blank page is honestly empty. You know exactly how much work is in front of you. A draft that is right most of the time is a different animal. Reading it costs something, and when the errors look plausible rather than obvious, reading it closely enough to catch one can cost more than starting clean. I wrote about where that bites in Jobs-to-be-Done for LLM product features. The short version: your model got faster and your reviewer did not.
So the scarce resource in an AI feature is the reviewer’s minute. Design for that, or you are designing for a bottleneck you do not have.
02An explanation is not an inspection
The reflex is to add explanation. Show the reasoning. Show a confidence score. Cite the sources. It feels like the honest thing to do, and it mostly makes things worse.
Bansal and colleagues tested this properly at CHI in 2021, across three tasks, with real people making real decisions alongside a model. People who saw explanations did not decide better than people who saw the prediction alone. What explanations did do was make those people likelier to go along with whatever the model said, whether or not it was right. Read that twice if you build these things. An explanation is a persuasion surface. It moves agreement, not accuracy.
Buçinca, Malaya and Gajos found the intervention that does work, in the same year. Make someone think the problem through before they can see what the model said, and they lean on it less. They measured that. They also measured the price and reported it plainly: people liked those designs less than the smooth ones that let them coast. So the thing that protects the decision is the thing your users will complain about. That is the real trade, and no amount of visual polish removes it.
The distinction I keep coming back to is this. Explaining well makes a reader agree. Designing for inspection makes it cheap for a reader to disagree when they should. Those two pull in opposite directions, and almost every AI interface I open has chosen the first one without noticing there was a choice.
The model side of this has its own literature. Mozannar and Sontag showed you can train a system to decide when to answer and when to hand the case to a human expert, and that the pair then does better than either alone. That work settles who should answer. It does not solve what the person sees when the system hands the decision over. That part is interface design, and it is mostly unbuilt.
03What an inspection surface has to expose
Three things, and I have shipped all three badly before shipping them well.
The number they will actually get. Not the flattering one. On a tuberculosis screening preview I built, the model measured AUROC 0.92 on held-out folds of its training corpora and 0.78 on a hospital cohort it had never seen. The verdict card leads with 0.78 and labels 0.92 as an upper bound on someone else’s data. That felt overcautious when I designed it. Then the dataset audit showed part of the 0.92 was the model recognizing which archive an image came from rather than the disease, and the cautious number turned out to be the true one. The mechanism is dull and worth copying: a calibrated threshold against a validated operating point drives the verdict, and the benchmark figure appears as context with its provenance attached.
The path that produced it. Every stage, what it saw, what it returned, how long it took, which provider ran it. On the research platform I lead, no theme reaches a report unless it traces to at least three supporting interview quotes, and an adversarial review stage has to tie each one back to evidence before the report ships at all.
One caveat, because I have watched people read a trace as proof. A path you can follow is not a claim you can trust. A theme can resolve perfectly to a real line in a real transcript and still describe nobody your product cares about. The path tells a reader where the claim came from. It does not tell them the claim is true, and an interface that implies otherwise has just built a more convincing wrong answer.
The cheapest possible disagreement. This is the one teams skip. If overriding the model takes more effort than accepting it, you have not built a review step, you have built a rubber stamp with extra clicks. In the service-writing work at AutoLeap the split was structural: the model assembles a draft repair order, and the advisor edits and approves before anything reaches a customer. Approving was never a formality, because editing was as quick as accepting. On the screening tool, disagreeing takes one button, and what the reader rejected gets recorded rather than thrown away.
Put plainly: a person who cannot afford to disagree is not reviewing anything.
04What this costs, and where the evidence stops
Cognitive forcing makes your product feel slower and less pleasant, and the study that shows it works also shows people prefer the version that does not. If you slow someone down, slow them down where they decide and nowhere else, and expect them to rate the product lower for it.
I should also be careful about how much weight these three examples carry together. The AutoLeap numbers I can point to, ACV up 20%, NPS up 15 points, churn down 23%, came out of four initiatives over a stretch of time, not out of the review pattern alone, and I am not going to attribute them to one design decision after the fact. The screening tool is solo research and makes no clinical claims. The research-platform numbers come from a paper under peer review, measured with one fixed judge, and the paper itself says the scores are instrument-relative. Three systems that share a pattern is a pattern worth naming. It is not a controlled experiment, and I would rather say so than let the story sound cleaner than the evidence.
05Where this goes
Agents will draft more per hour than any team can check, and that gap widens every model release. When a system can write more than anyone can read, what limits the product stops being what the model can produce and becomes how fast a person can tell whether it got it right. I think that becomes the thing products actually compete on, well before the underlying models stop improving.
Which gives you a metric you can take to work tomorrow. Hand one output from your last AI feature to somebody who did not build it, pick one specific claim inside it, and time how long it takes them to find out whether that claim is true. Do not help them. The number you get is your real interface metric, and it is usually embarrassing the first time.
If it takes them more than a minute, you did not ship an inspection surface. You shipped a presentation, and the review step you think you have is decoration. The wider argument about where the harness belongs in the interface is in AI-native product design, and the rest of the research sits on my research page.
I am curious where this breaks for other people. What is the fastest you have made it for a reader to disprove one thing your system produced, and what did you have to give up to get there?
06References
- Does the Whole Exceed its Parts? The Effect of AI Explanations on Complementary Team Performance
- To Trust or to Think: Cognitive Forcing Functions Can Reduce Overreliance on AI in AI-assisted Decision-making
- Consistent Estimators for Learning to Defer to an Expert
- Auditing Class-Conditional Acquisition Confounding Across Five Open Tuberculosis Chest X-ray Corpora
- Grounded Simulation: Task-Preserving LLM Personas for Synthetic User Research
07Further study
Branching by what you are trying to do next.
If you are about to add explanations to an AI feature.
- Does the Whole Exceed its Parts? — read the results section before you write the ticket; explanations moved acceptance, not accuracy.
- To Trust or to Think — what did work, and the satisfaction cost of using it. The honest pair to read together.
If you are deciding which step the model should own.
- Jobs-to-be-Done for LLM product features — write the job with no technology in it, split it into steps, then choose the one step a model may touch.
- Consistent Estimators for Learning to Defer to an Expert — the model-side version: train the system to know when to hand the case over.
If you are deciding what number to put on the screen.
- What my 92 was measuring — why the flattering benchmark number can be measuring the wrong thing entirely, with the audit that proved it.
- Auditable AI research — the evidence-chain argument this piece assumes, written out properly.
If you want to argue with me. The strongest objection is that inspection is a luxury of low volume. If a person has to review a hundred outputs an hour, no interface makes each one checkable in a minute, and what you actually need is sampling and a way to catch drift across the batch rather than a beautiful surface for each item. I think that is right, and it is the version of this problem I have not solved. If you have, I would rather hear it than not.