Show What an AI Agent Did Not Inspect Before Asking for Review

Agent review screens usually emphasize activity: files changed, tests passed, and a confident summary. Review quality also depends on negative evidence—what the agent did not inspect or could not verify.

Absence is not failure by itself. Hidden absence is the problem.

An inspection-coverage model

type EvidenceItem = {
  target: string;
  status: "inspected" | "partially-inspected" | "not-inspected" | "unavailable";
  reason?: string;
  consequence?: string;
  nextAction?: string;
};

Group the card by decision consequence, not by a long chronological tool log:

Ready to review
- 3 files changed
- unit tests passed (42/42)

Not verified
- integration tests: database unavailable
- generated client: not rebuilt
- payment callback: file outside granted workspace

Decision
[Open missing evidence] [Request follow-up] [Approve scoped patch]

“Approve scoped patch” must identify what the approval covers. It should not imply that unavailable integration evidence somehow passed.

Write reasons that support action

Weak: “Some files were not read.”

Better: “The payment callback was outside the granted workspace. This patch changes the event type it consumes. Grant read access or ask a reviewer familiar with that callback.”

The second version connects missing evidence to consequence and recovery without pretending the agent knows the outcome.

Avoid false completeness

A percentage such as “92% inspected” can look precise while hiding the one uninspected file that owns authorization. Prefer named coverage by risk area:

• changed files;
• direct callers and dependents;
• tests requested and tests executed;
• generated artifacts;
• external services and environment assumptions;
• security- or data-sensitive paths.

Let repositories define critical paths so the interface can elevate them above ordinary context files.

Research five scenarios

Ask reviewers to make a decision with realistic cards:

1. all requested tests pass;
2. one low-risk documentation check is unavailable;
3. a critical integration test is unavailable;
4. a relevant file is outside permissions;
5. the summary says “complete” while the evidence list is partial.

Observe whether users notice the gap, understand its consequence, select an appropriate next action, and can later explain what they approved. Do not measure success only by time-to-approve; a faster unsafe approval is not an improvement.

Accessibility and recovery

Place the “Not verified” heading before approval controls in reading order. Use text and icons rather than color alone. When follow-up evidence arrives, preserve the earlier card and show what changed instead of silently replacing history.

Trust does not come from making uncertainty disappear. It comes from presenting the boundary of inspection clearly enough that a reviewer can make a narrower, accountable decision.