AI Code Review Tools Need Receipts

AI code review tools are safest when they hand a human reviewer evidence to check, not when they quietly stand in for the reviewer. An AI review receipt is a short, reviewer-owned record of what the agent looked at, what files changed, what tests ran, and what risk is left over. Let Codex, Claude Code, or Codex inspect the code all you want, but ask for that receipt before anything merges.

Here is the moment this is built for. The team is shipping, one agent opens a fix, another agent comments on the pull request, and the human is stuck on the oldest question in code review: what actually changed, and why should I trust it?

Why does fluent review text not equal a real review?

Because more review-shaped text is not the same as accountable evidence. A coding agent can write three paragraphs about your diff that read beautifully and still skip the file that breaks production.

The usual trap looks reasonable. You ask an agent to review the PR, paste its output into a comment, treat the confident tone as coverage, then roll the same prompt out to the whole team and call it governance. It feels tidy. It is mostly vibes.

The real gap is missing review state. The agent might know the diff, the repo rules, the test output, and the linked issue, but your reviewer sees only a summary of all that. The gap widens fast once teams wire in MCP servers, issue trackers, design docs, and private knowledge bases.

So aim for a receipt a human can argue with. The agent inspects, compares, searches, and proposes. The team keeps the merge call. That one habit is the spine of any serious AI coding governance program.

How do I build the review loop around evidence?

Watch for four failure modes, and fix each with something the reviewer can see.

The summary-only review is the first. The agent says "looks good" or lists generic worries. Fix it with a changed-file ledger: make the agent name the files it inspected, the files it skipped, and why each risky file matters. A vague ledger means the review is not finished.

Tool memory drift is the second. Each tool keeps its instructions in its own place. Codex, Anysphere's AI code editor, supports agent workflows plus repo guidance like rules and AGENTS.md notes. Claude Code, Anthropic's coding agent, keeps durable project context in CLAUDE.md, skills, hooks, slash commands, and MCP. Codex, OpenAI's coding agent and CLI, reads repo instructions like AGENTS.md and runs verification loops. Put your review rules where the repo can version them, not in one giant prompt nobody can audit.

Over-broad tool access is the third. MCP is a protocol that connects coding agents to outside systems such as repositories, issue trackers, databases, and document stores. A review agent that can read logs, tickets, and design docs is handy. One that can mutate unrelated systems mid-review is a hazard. Keep review tools read-mostly and require explicit approval for writes.

Test theater is the fourth. The agent reports that tests passed without showing the command, the environment, or the failing cases it stepped around. Ask for command-level proof: exact commands, exit status, skipped checks. Treat review evidence as a build artifact, not a chat transcript. That is the spirit of the Review step in our methodology.

This mapping keeps teams consistent without pretending every tool is identical:

A good test of the whole thing: a reviewer should be able to replay your judgment without replaying the entire agent session.

What goes in the receipt?

Copy the block below into a PR comment, a commit note, or a review checklist. Keep it tight. If it runs past one screen, the agent is probably hiding uncertainty in prose.

# AI Review Receipt

PR:
Reviewer:
Agent used: Codex / Claude Code / Codex / other
Date:

## Change intent
- User-facing goal:
- Non-goal:
- Linked issue/design doc:

## Files reviewed
- Reviewed:
  - path/to/file: reason it matters
- Skipped:
  - path/to/file: why skipped or out of scope

## Review checks
- Architecture rule checked:
- Security/privacy rule checked:
- Backward compatibility checked:
- Migration/data risk checked:
- Docs or comments checked:

## Verification evidence
- Command run:
- Result:
- Logs or failing output:
- Tests not run and why:

## Agent findings
- Must fix before merge:
- Should fix soon:
- Safe to ignore because:

## Human decision
- Reviewer decision: approve / request changes / block
- Remaining risk owner:
- Follow-up ticket:

How do I roll this out per tool?

Put the same expectation in each tool's native home before the agent starts touching code, so the rule travels with the repo instead of living in someone's head.

- [ ] Codex: write the boundary into a .mdc rule or AGENTS.md note before the agent edits.
- [ ] Claude Code: put the same expectation in CLAUDE.md, a skill, or a review checklist before the session starts.
- [ ] Codex: run the Codex CLI verification loop against the changed path before the PR counts as reviewable.

Three small habits keep this honest. Keep a short scope note that names the artifact, its owner, and the files the agent may touch. Make the reviewer see the changed rule, checklist, or verification output before they approve. Park the fastest safe undo path next to the change so anyone can roll back without reconstructing the session. If your team is new to this, a short training run is the cleanest way to make the habit stick.

Common questions

• How should a team start with AI code review tools?

  Turn the idea into one visible rule, not a loose preference. In practice that means a short repository convention, a review checklist the agent has to fill in, and one named owner who is allowed to reject agent output when the evidence is missing. Start there before you add a second agent or a fancier prompt.

• Which artifact should we standardize first?

  The smallest one your reviewers already touch. A shared rule file, a review checklist, or a handoff receipt beats a thick policy doc nobody opens. The goal is not documentation volume. It is a single place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do we know the convention is actually working?

  It works when a reviewer can approve or reject from the artifact and evidence alone. Watch whether pull requests name the rule they used, include the checks they promised, and stop forcing reviewers to replay a long agent session just to understand what changed. If those three hold, you are in good shape.

• Should the agent ever merge on its own?

  No. The agent can inspect, compare, search, propose, and fill in the receipt, and it can do all of that fast. The merge decision stays with a human who owns the remaining risk. Keeping that line bright is what lets you move quickly without losing the thread of who is accountable for the change.

Where to go next

Open the related training topic and make your first exercise prove scope, verification, and ownership right in the PR body.

Further reading

• Google: creating helpful content
• Google: using generative AI content
• MCP specification (2025-11-25)
• Codex agent overview
• Claude Code getting started
• Codex quickstart
• OWASP Top 10 for LLM applications
• NIST AI Risk Management Framework
• OpenAI Codex on GitHub
• Anthropic skills on GitHub