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

A developer proposes a design for AI agent review screens that explicitly shows what the agent did not inspect or could not verify, arguing that hidden absence undermines trust. The approach groups evidence by decision consequence rather than chronological tool logs, and recommends named coverage by risk area instead of misleading percentage metrics. The goal is to enable reviewers to make narrower, accountable decisions by clearly presenting the boundary of inspection.

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. 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. 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. A percentage such as “92% inspected” can look precise while hiding the one uninspected file that owns authorization. Prefer named coverage by risk area: Let repositories define critical paths so the interface can elevate them above ordinary context files. Ask reviewers to make a decision with realistic cards: 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. 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.