Quick answer: Judge a finding by the evidence behind it, not by how confident the wording sounds. Check whether the claim rests on a deterministic check you can reproduce, see which files and lines it actually covers, and confirm the defect before you change code. Anything that comes only from the model is a hypothesis until you verify it.

Read the evidence class first

Every finding belongs to an evidence class, and the class tells you how much weight it deserves before you read a single line of detail.

Evidence class Basis Default trust
Static Typecheck, lint, build, hallucinated API High if the command passes or fails
Dynamic Test, coverage, smoke High when a real run produced it
Contract Schema, type drift High against the spec version
AI hypothesis Model reasoning only Low until verified

A model-only claim is always a hypothesis, no matter how specific the sentence reads. If a finding points at a typecheck failure, rerun the typecheck. If it claims a test fails, run that test. The verdict is produced deterministically with no model involved, so drift or failing evidence fails on its own merits.

Reproduce the command

Each evidence item carries a reproducible command and the raw process output. That is the basis for trust, and it is the fastest way to separate a real defect from a stale result.

  1. Run the exact command the evidence names.
  2. Compare your output with the recorded raw output.
  3. If they disagree, the context may have changed, so re-run the review rather than trusting either result.

A finding you cannot reproduce is not a confirmed defect. It may be a false suspicion, an environment difference, or a result taken before the latest edit. Keep it open until you can explain the discrepancy.

Check the scope the finding covers

A finding is bounded to the diff and the related context the review resolved. Before acting, confirm what it can and cannot see.

  • Does it reference the real definition and the callers, or only the local line?
  • Is the affected file heavily referenced, meaning the change can ripple?
  • Could dynamic loading or an external consumer be outside the resolved context?

Static analysis can miss dynamic loading, framework entry points, and external consumers. A note that looks definitive may simply be reasoning over an incomplete graph. No incoming reference does not mean a file is safe to delete, and identical text does not prove interchangeable behavior.

Handle false positives deliberately

When you confirm a finding is a false positive, do not just ignore it. Note why it does not hold: the referenced call exists on a path the parser did not resolve, the behavior is intended, or the condition cannot occur. This keeps you from re-litigating the same note on the next review and helps you read similar findings faster.

A tool that shows the diff in context and resolves the surrounding callers makes this step concrete, because you can trace the claim to the actual definition instead of arguing with a generic message. Powerduck presents each finding with its evidence and lets you confirm the dependency yourself rather than acting on an auto-applied edit.

Decide what to do

After verification, a finding lands in one of three buckets:

  • Act now: a deterministic check fails and you reproduced it.
  • Watch: the claim is plausible but unverified, often a hypothesis or a path outside the resolved graph.
  • Dismiss with a reason: you confirmed it is a false positive or intended behavior.

The review does not prove correctness, and an empty result is inconclusive rather than a pass. Keep unverified items visible instead of treating silence as approval.

Frequently asked questions

How confident should I be in an AI hypothesis? Treat it as a lead, not a fact. A model-only claim needs you to reproduce the problem or trace it to a real definition before it becomes a confirmed defect.

What if I cannot reproduce the finding? Keep it open and investigate the environment and whether the code changed since the review. Do not treat an unreproduced note as confirmed, and do not assume it is harmless without an explanation.

Should I fix every high-priority finding? Priority helps ordering, but evidence decides truth. Even a high-priority note can be a false positive; verify the command and scope first.

The bottom line

A finding earns action through evidence you can reproduce, not through confident wording. Lean on deterministic static, dynamic, and contract checks, keep model-only hypotheses at arm's length until verified, and dismiss false positives with a written reason. The review narrows your attention and gives you the raw command and output to check each claim, but the final verdict on every finding stays with you. Continue with the AI code review guide.