How I Turn Code Review Feedback Into an AI Workflow

AI becomes useful in code review when it is part of a loop, not a shortcut.

My goal is not to let the model decide whether a PR is good. My goal is to use it to compress the boring parts of review so I can spend more attention on architecture, product intent, and edge cases.

I use the same sequence most of the time:

1. Inspect
2. Frame
3. Draft
4. Reduce
5. Verify
6. Record

Each step has a narrow job.

I start by reading the diff once without prompting the model. I want a human sense of what changed, what is risky, and what is probably noise.

Then I write a short brief that tells the AI what matters. I include intent, constraints, and what to ignore.

I ask for risks, not praise. The prompt should surface likely failure modes and ask for file references.

I trim the output aggressively. Most AI review notes are either duplicates, too vague, or not worth interrupting the author for.

This is where the workflow becomes real. I check the change with a local command before I trust the notes:

If the review touched content, I also read the rendered output or run the build path that exercises the route. The point is to confirm that the code and the content agree.

I keep a short note about what the review caught and what it missed. That helps me tune the next prompt instead of repeating the same vague ask.

I avoid prompts that ask the model to approve the PR. Better prompts ask for concrete risks, missing checks, and places where the diff could mislead a reviewer.

That keeps AI in the right role: a fast second pass that expands attention, not authority.