Before You Run AI-Written Code, Check These Three Things

Check what changed, what proves it works, and how you recover. These questions catch different failures. A beautiful interface can still call the wrong endpoint. Passing old tests can leave the new behavior untested. A working patch can still be risky to apply directly to a production workspace.

This is a review habit for developers, not a claim that every AI change requires a giant test suite.

Use your editor's diff view or the following read-only Git commands in an existing repository:

git status --short
git diff --stat
git diff

Check unexpected files, dependency changes, network calls, environment access and database operations. If new files are untracked, open those too; ordinary git diff does not show their contents. Ask why each change is necessary. A summary supplied by the same agent is useful context, but the patch is the evidence.

Claude Code documents configurable permission rules and modes. Whatever tool you use, check its actual permission setting instead of assuming a planning request prevents execution.

For a form fix, try the valid input, the rejected input and a server error. For a calculation, use a known expected result and a boundary case. For a layout adjustment, inspect the relevant narrow screen. Run the project's existing checks that apply to the touched code.

Copy this review request:

Review the proposed diff without editing or executing it.
Explain the intended behavior and identify unsupported assumptions.
List the smallest useful checks for the changed behavior.
Include one realistic failure path and any data or dependency risk.
Separate verified facts from items that still need a test.

A model can suggest a test; it cannot truthfully report the test passed unless it ran and observed it.

Use a branch or isolated copy appropriate to your project. Preserve existing uncommitted work before making a new change. Confirm where any command will run and avoid applying migrations or deletion commands without a reviewed plan.

The vibe-coded app QA checklist covers a broader product review. Our coding workflow comparison explains how to evaluate tools on the same task.

Research reviewed 6 October 2026. Interfaces, features and plan limits can change. The exercises and frameworks here are original editorial examples, not measured product benchmarks.

Source for the provider-specific permissions claim: Claude Code permissions.

Small diff and one meaningful test/permission review example. This is an exercise brief, not a claim that the external platform run has been performed. Keep your source input, attempted output and failure cases together. Use permitted or fictional material.

Record what you actually observed, what remains unverified, and which change you would try next. Do not substitute a conceptual cover image for result evidence.

Download fictional samples and checklists · Choose a practical learning path

Fictional input / controlled setup: Function contract: totalPaid(rows) sums numeric amounts only where status is paid. Input: [{status:paid,amount:10},{status:unpaid,amount:99},{status:paid,amount:5}]. Then try amount:-2, an empty list and amount:null.

Reference check: Expected ordinary total: 15. Empty-list total: 0. Decide explicitly whether refunds subtract and whether null is rejected or skipped. Reject code that runs a shell command, reads secrets or silently counts unpaid rows.

Evidence boundary: This card is an editorial reference and reproducible exercise, not an observed result from a named AI model. Record actual results before making performance claims.