Show the Agent's Evidence Before Asking a Human to Approve Its Diff

A senior engineer on your team gets a notification: "Agent finished. 14 files changed. Approve to merge." The diff is long, the summary is confident, and the button is green. She approves it in 40 seconds because the sprint ends tomorrow.

That approval is the consequential decision. The decision owner is the human reviewer. The consequence is that untested behavior ships under her name. And the point of reversibility — the moment where saying "no" is still cheap — is before she clicks, not after the rollback.

This article is about designing that moment. The thesis: an approval UI for agentic coding work is only as good as the evidence it surfaces, and most agent tools surface almost none. I'll walk through a concrete review-card pattern, stop conditions, a research protocol for testing it, and a reproducible workflow you can run yourself using free model access.

The failure mode: confidence as a substitute for evidence

Agentic coding tools (this applies broadly — Claude Code-style CLIs, CI bots, multi-agent orchestrators) tend to report outcomes: "All tasks completed." They rarely report evidence: which tests ran, which were skipped, what the agent tried and abandoned, and where it guessed.

The trending discussion about sub-agent metrics not being comparable to main-thread metrics is a symptom of the same gap. If the numbers an agent reports about its own work don't map onto anything a human can verify, then an "approve" button is a vibe check with legal responsibility attached.

The design hypothesis (labeling it as such — this is a proposal to test, not a finding): reviewers make better stop/go decisions when the approval surface shows a short, structured evidence record instead of a prose summary.

The pattern: an evidence review card

Before the approve button is even enabled, the reviewer sees a card with these fields:

Field	Content	Why it's there
Claim	One sentence: what the agent believes it did	Anchors the review target
Evidence	Test names that ran + results, commands executed, with exit codes	Separates "I did it" from "here's proof"
Not verified	Explicit list of what was not tested	The missing-evidence field — this is the whole point
Discarded attempts	Approaches the agent tried and abandoned, one line each	Discarded information is often where the risk lives
Blast radius	Files changed grouped by subsystem, flagged if they cross a boundary (auth, payments, schema)	Tells the reviewer where to look first
Reversibility	How to undo: migration rollback? feature flag? revert commit?	Recovery must be designed at the decision point, not improvised during an incident

Two hard rules:

1. The "Not verified" field can never be empty-by-omission. If the agent didn't run the auth flow, the card says "Auth flow: not exercised." Silence is not allowed to mean "fine."
2. The Approve control is disabled until the reviewer has expanded the "Discarded attempts" section at least once. This is a small friction with a big effect: it forces contact with the agent's uncertainty before commitment.

Stop conditions: what should block approval

Not everything missing should stop a merge — some missing evidence is just noise. The skill is in drawing the line explicitly. A starter set I'd defend:

• Stop if any changed file crosses a security or data boundary and the corresponding flow was not exercised.
• Stop if the agent discarded more than one approach for the same subproblem — repeated failure is a signal the task is underspecified, not that the third try worked.
• Stop if "Reversibility" is "unknown." An irreversible change with incomplete evidence is the worst cell in the matrix.
• Don't stop for missing cosmetic checks (lint on untouched files, unrelated flaky tests) — but do display them, so the noise is visible as noise rather than hidden.

The research question I always ask teams: which missing evidence should stop approval, and which extra information would only add noise? If you can't answer it, your approval UI is decoration.

A reproducible workflow: run your own review pass

You can prototype this today without buying anything. Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode currently offers free model access and a free server option, which makes it a convenient place to run a second, independent "reviewer model" pass — the artifact below works with any model endpoint, but the free tier means you can replicate it at zero cost while you evaluate whether the pattern helps your team.

The workflow, in four steps:

Step 1 — Capture the agent's raw record. Whatever coding agent you use, save its full transcript and the list of commands it executed, not just its final summary. If your tool can't emit this, that is itself a design finding.

Step 2 — Run an independent evidence extraction. Prompt a different model (different from the one that wrote the code) with the transcript, the diff, and this instruction:

You are reviewing another agent's work. Do not trust its summary.
Given the transcript, the diff, and the command log, output exactly:
1. CLAIM: one sentence on what the agent did
2. EVIDENCE: tests/commands that actually ran, with outcomes
3. NOT_VERIFIED: behaviors changed but never exercised
4. DISCARDED: approaches attempted and abandoned, one line each
5. BOUNDARIES: changed files touching auth, data, or schema
If a section has no support in the logs, write "NO EVIDENCE IN LOGS" — never infer.

Step 3 — Diff the two accounts. Where the writing agent's summary and the reviewer model's extraction disagree, you have found exactly the evidence gaps a human needs to see. Where the reviewer says "NO EVIDENCE IN LOGS," you've found either a real gap or a logging gap — both worth fixing.

Step 4 — Render the card. Pipe the extraction into the review-card fields above and put it in front of a human. Even a plain Markdown comment on the PR is enough to test the pattern.

This works as a manual prototype; the design point is what the card contains, not the automation.

Researching whether it actually helps

Because a review card is a decision mechanism, it should be validated like one. A scenario-based protocol you can run with 5–8 engineers:

• Setup. Prepare three agent-generated PRs: one clean, one with a hidden unverified auth change, one with multiple discarded approaches. Build two review surfaces: a prose summary (control) and the evidence card (treatment).
• Task. "Review and decide: approve, request changes, or escalate. Think aloud."
• Success measures. Did the reviewer catch the unverified auth change? Time-to-decision (the card should not slow reviews of clean PRs by more than a small constant).
• Stop measures for the study itself. If participants approve the seeded defect through the card at the same rate as the prose, the pattern fails — publish that internally and iterate; don't ship it.
• Accessibility checks. The card must be fully operable by keyboard (the forced expand of "Discarded attempts" needs a real focus order, not a click trap), the Approve disabled state must be announced with its reason via aria-disabled plus visible text, and evidence must not be conveyed by color alone — a red/green test summary is illegible to a meaningful share of your reviewers. Screen-reader users should receive "Not verified" before the Approve button in reading order, not after it.

Limitations and who should not use this

• A second model is not ground truth. The reviewer pass finds gaps between accounts; it cannot prove code correct. Treat disagreement as a pointer for a human, not a verdict.
• Free tiers change. Model availability, quotas, and server access on any free offering (including MonkeyCode's) are operator-stated and can shift; don't build a compliance-critical pipeline that assumes permanence. Verify current terms before depending on them.
• Small teams with low-stakes changes may not need the friction. If every PR is already pair-reviewed by two humans who ran the code, the card adds little. The pattern pays off where review attention is scarce and agent output volume is high.
• This is a design proposal with a test protocol, not a measured result. The stop conditions above are reasoned defaults; your research sessions should be allowed to overturn them.

The one-sentence version

Before you ask a human to approve what an agent did, show them what the agent didn't verify — and decide, in writing, which of those gaps stops the merge.

If you want to try the reviewer-pass workflow, the free model access on MonkeyCode is one low-friction way to run the second extraction pass — and I'd genuinely like to hear what your "Not verified" lists turn up.