PTN—27
Verification affordances
Build checking into the interface — diffs, previews, traces, one-tap source access — so verifying is cheaper than trusting blindly.
Every AI product implicitly bills the user for verification; the only question is the rate. If checking an output means opening three tabs and re-deriving the answer, nobody checks, and “review the AI’s work” becomes a policy nobody follows. Verification affordances drive that cost toward zero: the diff view that shows exactly what an agent changed, the source passage one hover away, the citation that opens to the highlighted quote, the preview that runs the generated code before it merges.
The strongest affordances verify the change, not the output. Nobody can meaningfully review 400 lines of regenerated code, but anyone can review a 12-line diff — which is why Cursor renders every agent edit as an accept/reject diff and why GitHub structured Copilot’s agent around pull requests: decades of review affordances, inherited for free. Show what moved, not the whole world re-printed.
Match verification depth to stakes. A brainstorm needs none; a database migration needs a dry-run preview and an explicit diff before anything executes. And treat the affordance as load-bearing product surface, not a power-user extra: when verification is one interaction, people sample AI work the way a good reviewer samples a trusted colleague’s — lightly, but genuinely. That sampling is what lets confidence scale with the system instead of being taken on faith.
When to use
- AI modifies existing material — code, documents, data — where a diff can carry the review.
- Agents take multi-step actions whose intermediate work needs to be auditable after the fact.
- Output feeds consequential decisions and spot-checking must be cheap enough to actually happen.
- Generated claims trace to sources and the gap between claim and evidence is one interaction wide.
Design considerations
- 01Show diffs, not full rewrites — reviewing the delta is tractable; re-reading everything is not.
- 02Make source-checking one interaction: hover or tap from claim to highlighted passage, never claim to homepage.
- 03Keep an inspectable trace of agent actions — which tools ran, what they returned — reviewable after completion.
- 04Provide safe previews for consequential operations: dry-run the query, render the email, stage the change.
- 05Scale friction to stakes — inline accept for prose edits, explicit review gates for migrations and sends.
- 06Design for sampling: make spot-checking one item easy instead of demanding all-or-nothing review.
- 07Instrument the affordances; if nobody opens sources or expands diffs, your verification story is decorative.
Pitfalls
- ✕Verification theater: an “always review AI output” banner with no tooling that makes review feasible. The policy exists; the practice cannot.
- ✕The full-rewrite dump — replacing a document wholesale so the person must re-read everything to find what changed. Unverifiable in practice, whatever the UI claims.
- ✕Rubber-stamp conditioning: approval prompts so frequent and low-stakes that accepting becomes muscle memory, spending the person’s attention before the change that matters.
- ✕Traces that evaporate — agent steps visible only during execution, so the moment something looks wrong there is nothing left to audit.
In the wild
- Cursor
- Every agent edit lands as an in-editor diff with per-file accept and reject — the diff is the interface, not an afterthought.
- GitHub Copilot
- The coding agent delivers work as a pull request, inheriting diffs, review comments, and CI as ready-made verification machinery.
- Perplexity
- Claim-to-source is one hover; the snippet preview means most verification never requires leaving the answer.
- Claude
- Agentic coding surfaces show proposed file edits and command output for approval, and artifacts render generated code live so behavior can be checked, not just read.
- Notion AI
- AI edits arrive as suggestions to accept or discard rather than silent replacements of the page.