This is a loser-interesting question because it makes advanced AI sound less like magic and more like a change proposal. But the moment a system can edit code, publish a route, send a message, or touch a host shell, serious users keep asking the same rude thing: show me the delta first. Not because autonomy failed. Because approval without a visible change object is still a hidden-risk transfer.
Dependable AI products propose before they perform. They show what object will change, what the delta is, which approval boundary governs it, and how to undo it. If the only preview is model prose, the human is still carrying the real trust load.
The embarrassing unit is the proposed delta
After the demo glow fades, the user asks for a draft email, a patch preview, a dry-run deploy, a changed-files list, or a side-by-side before approving the action. Those requests sound anti-magic. They are actually the strongest product signal you can get.
A serious user is telling you that the system is crossing from interesting output into socially expensive action. At that boundary, the useful artifact is no longer the model's explanation. It is the proposed difference between the world before the action and the world after it.
Name the object.
File, route, deployment target, customer, record, or host surface should be explicit before the verb fires.
Show the delta.
Diff, draft, patch, dry-run payload, or before-and-after state should exist as an inspectable object instead of a narrated promise.
Show the approval seam.
The user should know exactly where consent is being applied and what action that consent authorizes.
Show the rollback.
If the preview is wrong, the recovery path should be as legible as the action path.
The official stack keeps rediscovering preview discipline
The current OpenAI approvals guide says approvals are the human-in-the-loop path for tool calls and that the run pauses until the user approves or rejects the action (OpenAI guardrails and human review). That is already a diff-first idea in disguise. A pause is only useful when the user can inspect something concrete enough to evaluate.
The MCP tools specification pushes in the same direction. It says there should always be a human in the loop with the ability to deny tool invocations, and that clients should make clear which tools are exposed and present confirmation prompts for operations (MCP tools specification). A confirmation prompt without a visible delta is weak theater. It asks the user to approve vibes instead of approving a change object.
Git solved the social shape of this long ago
Git's diff documentation describes the command as a way to show changes
between commits, the index, and the working tree, including the form for viewing the
changes in the working tree relative to a named commit
(git-diff documentation).
That sounds mundane, but it captures the trust move exactly: turn a proposed change
into a portable object another operator can inspect.
The enduring value of a diff is not that it is textual. It is that it collapses a future action into a bounded review surface. The second operator does not need the first operator's inner monologue. They need the changed object, the target, and the reason to say yes or no quickly.
Chopshopr's local-first version is deliberately boring
Chopshopr's own repo contract leans into this on purpose. The README's worktree-first
path uses bun run worktree:prepare -- --task "<slug>" as the starting
point and explicitly recommends --dry-run --json when you want a readiness
receipt before creating anything
(Chopshopr README: worktree-first build and autoship).
The same README separates local model inference from host operations and describes NemoClaw/OpenShell as bounded MCP surfaces rather than ambient raw shell power (Chopshopr README: NemoClaw MCP). That matters because a bounded host tool plus a visible dry run is much easier to trust than a generic command surface wrapped in confident prose.
By the time the site ships, the repo expects the same boring closure: bun run build,
then bun run ship:mainline, then deploy and live proof. The system is not
trying to sound autonomous. It is trying to make the proposed and completed change easy
to compare.
- Show the object before the verb: target clarity and previewability belong together.
- Keep dry runs cheap: the safe preview path should be easier than the real side effect.
- Bind preview to the real action: the diff, draft, or plan should point at the same target the final command will touch.
- Keep the delta reviewable: giant change bundles are only slightly better than vibes.
- Make the final receipt comparable: the shipped state should match the proposed state closely enough that a second operator can reconcile them fast.
Where preview surfaces still fail
Some products technically expose a preview, but it is too broad, too stale, or too detached from the action to help. A diff against the wrong branch is not trust. A dry run that skips the risky part is not trust. A narrated summary of a patch is not trust if nobody can inspect the patch.
The sharper failure mode is when a team mistakes this for user caution. It is not caution. It is unpaid review work being pushed back toward the product. The user is telling you exactly what surface still needs to exist before the workflow feels safe.
The rude question worth keeping
Before you ask whether the agent can finish, ask what exactly changes if you say yes.
If the system can answer with an inspectable delta, a visible approval seam, and a real rollback path, you are much closer to a dependable tool. If it can only answer with narration, the human is still doing the final trust work by hand.