Quick answer: AI code review is a tool that reads the code you changed, along with a bounded amount of related context, and returns prioritized findings with evidence and a recommendation. It works on top of local git differences and parsers that resolve definitions, callers, and imports. It does not run the application, and it does not prove the code is correct. You assess each finding and decide what to act on.
What it actually reviews
The input is not a vague scan of the whole repository. It starts with your local git diff, the set of added, removed, and modified lines you are about to ship. On top of that, the review pulls in bounded related context: the definitions a change references, the callers of a function, and the imports that tie files together.
Each finding comes back with three parts:
- Priority, so you can tell a blocking defect from a minor note.
- Evidence, the concrete reason the finding was raised, not just a label.
- Recommendation, a suggested next step rather than an automatic edit.
The review starts only when you request it. It does not rewrite the file by itself, and it does not approve or merge anything.
How it fits the desktop workflow
When you choose a code folder, the project structure opens first. You can then open a file and see its full source, with views for source only, full comparison, and changes only. Added and removed lines are marked, inline character highlights show exactly what moved, and navigation plus search help you move through a large diff.
Structure filters add signals that are hard to get by eyeballing a folder:
| Filter | What it tells you |
|---|---|
| Heavily referenced files | Where a change can ripple across many callers |
| Temporary-name candidates | Files that look like scratch work left in the tree |
| Identical content | Duplicated blocks that may be copies rather than shared logic |
| No incoming references | Files nothing resolved points to, worth a closer look |
These are cues for review, not verdicts. A file with no incoming reference is not automatically safe to delete, and identical text does not mean two pieces of code behave the same way.
The evidence model behind the findings
Findings are not all the same kind, and treating them that way leads to bad decisions. The review distinguishes evidence classes:
- Static signals such as typecheck, lint, build, and references to an API that does not exist.
- Dynamic signals from tests, coverage, and smoke runs.
- Contract signals from schema and type drift.
- AI hypothesis, anything that comes from the model with no deterministic check behind it.
A model-only claim is always a hypothesis, never a confirmed defect. When you run project checks, a missing script is reported as unverified rather than passed. If no evidence comes back, the result is inconclusive, because an empty result is not a pass.
Honest limits
Powerduck can miss defects or raise false suspicions, and it does not run the app. Dynamic loading, framework entry points, and external consumers can be missed by static analysis. A review narrows where you spend attention and gives you a structured way to read a change, but the call on each finding stays with the engineer.
You can also export an agent task package as a Markdown handoff that carries the context and revision anchors. Modification is optional, and the receiving agent assesses every suspicion independently rather than trusting the export.
Frequently asked questions
Does AI code review replace a human reviewer? No. It organizes the diff and surfaces evidence-backed findings, but a person still judges each one and keeps the context that static analysis cannot see, such as product intent and external systems.
Does it run my tests or the application? It can run detected project commands as explicit checks, but it does not run the app itself. A missing script is marked unverified, not passed.
Can a finding be wrong? Yes. The review can raise false suspicions, and model-only claims are hypotheses. Confirm the evidence before you change code.
Does a clean review mean the code is correct? No. A review does not prove correctness, and there are documented blind spots including dynamic loading and external consumers.
The bottom line
AI code review is a focused reading of your diff with bounded context, returning priority, evidence, and a recommendation for each finding. Its value is that it separates static, dynamic, contract, and hypothesis signals so you know how much to trust each note, while keeping the decision in your hands. Treat it as a fast, structured first reviewer that can miss things and can be wrong, not as a correctness certificate. Explore more in the AI code review guide.
Top comments (0)