Verify an AI-generated change before you commit

Your agent (Claude Code, Cursor, Copilot, Codex) just edited your repo. The diff looks plausible. This guide is the short loop to run before you commit it , so you commit evidence, not hope. Every step is keyless, local, and works offline.

When to use this

Any time an AI wrote or modified code you are about to keep: a feature, a refactor, a "quick fix." Plausible-looking diffs are exactly where AI changes go wrong , a call renamed on one side only, a test quietly deleted, a change that reaches further than it looks.

The loop

1. Look at what actually changed

Start from the real diff, not the agent's description of it.

openthunder review-diff

You get the files touched, the risk level, likely-missing tests, and breakage risks for the current change. If you only have a raw diff (no repo open), the in-browser diff review does the same with nothing uploaded.

2. Check the blast radius

A one-line change in a file everything depends on is not a one-line change. Ask what this change can reach:

openthunder risks          # the risk register: churn hotspots, security-sensitive files
openthunder lens           # the architecture map, to see where the touched files sit

If the change lands in a hub or a fragile zone, treat it as high-risk regardless of how small the diff is.

3. Run the security check

openthunder security check

This fails on new critical findings, secrets, or unauthenticated protected routes , the failure modes AI changes most often introduce by accident.

4. Get the ship verdict

Condense verification, findings, and confidence into one decision:

openthunder can-i-ship

You get SHIP / CAUTION / HOLD with file:line evidence. See Decide if a change is safe to ship for how to read it.

5. Keep the evidence

If it passes, capture the receipt so the change carries proof into review:

openthunder pr-evidence

That assembles a pull-request-ready Evidence Pack , what was checked, what held, and the provenance of each conclusion.

For high-risk work, promote it to a mission

For auth, billing, database migrations, or anything security-sensitive, do not verify inline , run it as a mission so an independent reviewer challenges the change before it is accepted. See Decide if a change is safe to ship and openthunder mission.

Let your agent do steps 1–4 itself

If you connect your agent over MCP, it can run this loop without you copy-pasting commands: it pulls the change context, blast radius, and findings as resources, and requests the verdict as a tool. OpenThunder still observes reality and decides , the agent asks, it does not get to declare the change verified. See Connect your AI agent.