How I Use AI to Automate My Daily Code Reviews

Why I Let AI Triage Reviews First

I do not let AI approve code. I use it for the dull first pass.

That sounds like a minor distinction, but it changes the whole workflow. In a steady review queue, the bottleneck is usually not deep analysis. It is sorting: which diffs are low risk, which ones need tests, which ones touch auth or payments, and which ones should stay in a human's hands a little longer.

My workflow is simple:

• AI reads the diff first
• it assigns a rough risk level
• it points out likely missing tests
• I review the high-signal items myself

That saves time without pretending the model understands the system better than the team that built it.

The Review Workflow I Actually Use

I keep the workflow tied to the pull request, not to the entire codebase. The model gets:

• the changed files
• the commit message
• the PR description
• a short checklist for the repo

Then I ask for three things:

1. a risk score
2. a list of behavior changes
3. likely review questions

That is usually enough to catch the obvious issues. It also avoids the trap of getting a wall of generic advice that sounds useful and says very little.

What the AI checks well

AI is most useful when the review task is pattern matching.

It does well at spotting:

• missing test updates when code paths change
• risky refactors that touch auth, validation, or serialization
• suspiciously broad deletions
• duplicate logic that should have been shared instead of copied
• brittle conditions that depend on string matching or exact object shape

It is strongest when the diff is small and the surrounding code is consistent.

Where I still review manually

I still read the parts that need judgment:

• permission checks
• data model changes
• anything that affects money, user state, or deploy behavior
• code that looks clean but changes failure modes
• migrations and rollback paths

The model can point to the right file. It cannot tell you whether the app can survive a broken migration at 2 a.m.

Prompting the Tool Without Losing Signal

The best prompts I have found are narrow and boring.

Keep the prompt narrow

I do not ask for a “full security review” unless that is really the goal. That wording tends to produce vague output. Instead I ask for a constrained task:

• “Review this diff for regressions and missing tests.”
• “Identify user-visible behavior changes.”
• “Call out risky assumptions in validation or permission logic.”

Short prompts keep the output closer to the code.

Feed it diffs, not whole repos

Whole-repo prompts are where signal goes to die.

A repo dump gives the model too much unrelated context, too many naming collisions, and too many chances to invent a relationship that is not there. Diffs keep the review grounded in what actually changed.

If I need more context, I add only the surrounding functions or schema definitions that the diff touches.

A Safe JavaScript Example

Here is the kind of helper I use to triage incoming reviews before I read them.

function scoreReviewRisk(files) {
const weights = [
  [/auth|permission|role/i, 5],
  [/payment|billing|invoice/i, 5],
  [/migration|schema|db/i, 4],
  [/validation|sanitize|parse/i, 4],
  [/test|spec/i, -2],
  [/docs?|readme/i, -1],
];

return files.map((file) => {
  const path = file.path || "";
  const content = file.diff || "";
  let score = 0;

  for (const [pattern, weight] of weights) {
    if (pattern.test(path) || pattern.test(content)) {
      score += weight;
    }
  }

  return {
    path,
    score,
    needsHumanReview: score >= 4,
  };
});
}

function findReviewFlags(diffText) {
const flags = [];

if (!/test/i.test(diffText)) {
  flags.push("No obvious test update in the diff");
}

if (/any/.test(diffText) || /Object.assign(/.test(diffText)) {
  flags.push("Check for loose typing or brittle merges");
}

if (/TODO|FIXME/.test(diffText)) {
  flags.push("Leftover marker in changed code");
}

return flags;
}

Scoring risk from changed files

The score is not truth. It is triage.

A path like authz/permissions.js deserves attention even if the diff is tiny. A path like docs/api.md usually does not. The point is to make the model spend attention where the blast radius is larger.

Flagging missing tests and brittle patterns

I also have the model scan for simple review smells:

• changed logic with no test diff nearby
• broad guards that now accept too much
• stringly typed checks that should be explicit
• code paths that depend on implicit defaults

Those are not proof of a bug. They are good questions to ask before merging.

Failure Modes I Watch For

False confidence

The biggest failure mode is not wrong output. It is polished wrong output.

If the model says “looks safe” with a confident tone, I ignore the tone and inspect the evidence. I want specific references: file names, line ranges, and the exact behavior that changed.

Style bias and noisy suggestions

Models also have a habit of pushing code toward whatever style they have seen most often. That is not always your style, your stack, or your constraints.

I ignore suggestions that only improve aesthetics unless they also reduce risk or maintenance cost. A prettier abstraction that hides behavior is not a win.

How I Measure Whether It Helps

I measure this in plain terms:

• Did it reduce the time to first meaningful comment?
• Did it catch missing tests I would have asked for anyway?
• Did it surface one or two real risks early?
• Did it avoid flooding the review with junk?

If the answer is mostly no, I tighten the prompt or remove that step from the workflow.

A review assistant should save attention, not consume it.

What Still Needs a Human

Humans still own:

• approval decisions
• security-sensitive changes
• product tradeoffs
• rollback judgment
• subtle API compatibility issues

That is the boundary I keep in mind. AI can sort, summarize, and highlight. It should not be the last reader on code that can break production.

Conclusion

The useful version of AI in code review is not “replace the reviewer.” It is “clear the noise before the reviewer starts.”

When I keep the prompt narrow, feed it diffs instead of repos, and treat its output as triage rather than verdict, I get a faster review loop with fewer missed basics. That is enough.