Skip to main content

AI Code Review Workflow

Use AI to find candidate defects, then verify every finding against the code.

Introduction​

AI review can scan a diff for logic errors, missing tests, unsafe data handling, and things that do not line up. Its findings are guesses. A person has to confirm each one, and still judge intent, design, and how the product behaves.

Run the deterministic tools first. A compiler, linter, or static analyzer beats a model on any rule it can state.

Understanding the Workflow​

An AI reviewer needs to know why the change exists, see the diff, and read enough of the code around it to follow what the change touches. A bare diff hides the rules set by callers, schemas, config, and tests.

A review finding should name a real failure, say what triggers it, and point at the line. Advice with no visible consequence is not something anyone can act on.

Definition

Review Finding

A specific claim that changed code causes a defect or risk under stated conditions, supported by a code location and technical reasoning.

Every finding belongs in one of three states:

StateMeaningAction
ConfirmedCode and evidence support the findingFix it and add coverage where useful
RejectedThe claim is false or outside the change's contractRecord a short reason
UnresolvedAvailable context cannot prove or dismiss itInvestigate or ask the owner

Applying It in Practice​

Start with a clean diff and a one-paragraph description of the change. Add the acceptance criteria, the constraints you know about, and links to related code outside the diff.

Run focused passes instead of one broad request. Useful scopes include:

  • correctness and error paths
  • authorization, input handling, and data exposure
  • concurrency and resource lifetime
  • migration and compatibility risks
  • test quality and missing cases

Ask for findings that name a way the code fails and cite the affected line. Tell it to skip praise, summaries, and style opinions.

Work through each finding by reading the code it cites. Reproduce the problem with a test or a real execution path where you can. Throw out anything that rests on a wrong assumption.

Fix the confirmed issues before a human looks at it. Rerun the relevant checks, and run the focused AI pass again if the diff moved much.

A human reviewer should read the whole diff. They decide whether the change solves the right problem, fits the system, and creates trouble that the local code does not show.

Engineering Considerations​

AI review works best when the bug is visible in the code you handed it. It gets weak when the answer depends on unwritten product rules, how production is wired, or code it never read. Runtime behavior is the biggest blind spot, which is why the React development workflow leans on user-facing tests instead of static checks.

A model can be wrong at length and in detail. Precise wording is not evidence. Check what it says triggers the bug, and trace the data or control flow yourself.

Do not send secrets, customer data, or restricted source to a provider without an approved data-handling agreement. The prompts and replies may need the same retention rules as the code itself.

Run a real security analysis on high-risk changes. A general AI pass is no substitute for threat modeling, dependency scanning, or a reviewer who knows the security boundary. Pair it with a human-in-the-loop review system instead of treating it as the gate.

Scaling and Operations​

Automated review should post a short, ranked list. Flood people with comments and they learn to ignore the whole thing. Keep it to issues someone can act on, and fold repeats into one explanation.

Count confirmed, rejected, and unresolved findings for each kind of review. A high rejection rate means the prompt is short on context or the scope is too wide. Few findings does not mean the review is good, so compare it against the bugs you find later.

Keep prompts and model settings in version control like any other config. Revisit them when the codebase, the threat model, or the provider changes.

AI-generated comments should identify themselves as automated. Keep a human accountable for the merge decision, especially when a coding agent wrote the change as well as the review.

Next Steps​