Quick answer: Prioritize findings by three questions: can the trigger actually fire in a real path, how broad is the blast radius, and does it risk data or a security boundary. A defect that deletes or exposes data on a common path outranks a style issue on a rare branch, regardless of which appears first in the diff. A simple severity model turns a list of suspicions into an order you can work through without treating every flag as equal.
Why order matters
A review can return several suspicions at once, and they are not equally important. If the reviewer fixes them in the order they appear, a low-risk naming flag can consume the time that a data-loss defect on a hot path should have, and the merge decision gets made before the serious item is even read.
Priority is a judgment the reviewer still owns. The tool returns a priority as a starting signal, but the final order should reflect the real trigger and impact as confirmed against the code, not the raw list order.
The three ranking questions
| Question | Why it matters | High-risk answer |
|---|---|---|
| Can the trigger fire? | A bug on an unreachable branch cannot hurt now | A common request reaches it |
| What is the blast radius? | Shared code reaches more operations | A shared helper or table |
| What is at stake? | Data and security are hard to reverse | Deletion, exposure, or auth bypass |
A finding that answers high on all three is the first thing to confirm. A finding that sits on a branch that cannot currently be reached, in a leaf module, with no data impact, can wait even if the analysis labels it loudly.
A practical severity model
- P1, confirm first: a reachable trigger on a common path that can delete or expose data, bypass a check, or break a core flow.
- P2, confirm before merge: a real logic defect with a narrower trigger or a contained blast radius, such as one operation returning a wrong value.
- P3, batch the cleanup: maintainability and naming issues that do not change behavior, handled together after the logic is settled.
Walk this on a real diff. A flagged line that can delete archived notes during a normal selection change is reachable on a common action and risks data, so it is P1 and gets confirmed first. A second flag about a helper that returns a slightly wrong default on an error branch is P2 because the trigger is narrow. A third flag about a variable named after the ticket number is P3 and is batched with the rest.
Re-ranking after confirmation
The first order is provisional, and it should change as the evidence is checked. A P1 that turns out to sit behind a guard that always blocks it drops down, and a quiet P2 that the caller analysis reveals to be on a shared helper rises. Re-rank after each confirmation rather than defending the original label, because the priority is a lead and the confirmed trigger is the fact.
The inline review returns the priority, evidence, and recommendation next to the change, which gives the ranking a basis rather than a vibe.
Powerduck keeps the severity and the code evidence together so the reviewer can re-rank each finding from the trigger rather than from its position in the list.
When two findings tie
Two findings can answer the ranking questions the same way, and the tie is broken by reversibility. A defect that deletes data is harder to undo than one that returns a wrong value that can be corrected on the next call, so the irreversible one goes first even when both are reachable. If they are still tied, the shared-code item precedes the leaf item because its blast radius is larger, and the item with the simpler confirmation goes first when nothing else separates them, since clearing a quick confirmed finding frees attention for the harder one. Write the tie-break reason into the record rather than relying on memory.
Honest limits
Severity ranks the confirmed static evidence, and it does not measure what the diff cannot show. A framework entry point or an external consumer can make a supposedly unreachable branch live, and an AI-only claim stays a hypothesis until a runnable check backs it. A green build does not answer the trigger question, and an empty test result is not a pass.
When the trigger cannot be settled from the code, confirm it with a real request rather than guessing the rank, and keep unverified items visible rather than silently promoting them.
Frequently asked questions
Should I trust the tool's priority label? Use it as a starting signal, then confirm the trigger and re-rank against the real path and impact.
What makes a finding P1? A reachable trigger on a common path that risks data, a security boundary, or a core flow.
Do P3 items get ignored? No. They are batched and handled after the behavioral findings, not dropped.
The bottom line
Rank findings by whether the trigger can really fire, how far the change reaches, and what it puts at stake, then confirm the data-risk items first and re-rank as the evidence changes. The tool's priority is a lead, not the final order, and a reachable data-loss defect always outranks a rare-branch style flag. Keep AI-only claims as hypotheses and confirm the trigger with a real request when the code cannot settle it. Read more in the AI code review guide.
Top comments (0)