What AI Code Review Cannot Catch

Quick answer: AI code review cannot see code that is reached through dynamic loading or framework entry points, external consumers outside the repository, or the runtime behavior of the application, because it does not run the app. It can also miss defects or raise false suspicions, and it does not prove correctness. Knowing these blind spots tells you which parts still need a test, a smoke run, or a person's judgment.

The structural blind spots

The review is built on local git differences plus parsers that resolve definitions, callers, and imports. Anything outside that resolved graph can be missed.

A file with no incoming reference is a cue, not a verdict. It is not automatically safe to delete, because an external consumer or dynamic loader may be the real caller. Identical text does not prove interchangeable behavior either, since two matching blocks can sit in different runtime contexts.

What static analysis cannot determine

Some questions only have answers once code runs. Static reading cannot tell you whether a branch behaves correctly under real data, whether a side effect fires in the right order, or how a change interacts with a live service. That is why dynamic evidence from tests, coverage, and smoke runs is a separate class rather than an assumption.

A dynamic run still only covers the paths it reaches, so an unexercised branch carries no evidence. When a project script is missing, the check is unverified rather than passed, and an empty result is inconclusive, not a green check.

The reasoning limits

Model-only notes are AI hypotheses, and they can be wrong. The model does not know product intent it has not been given, and it can raise a false suspicion that reads as confident. A model-only claim is always a hypothesis until you reproduce it or trace it to a real definition.

The deterministic verdict protects you in one direction: failing evidence fails, and no verified evidence is inconclusive. It cannot, however, invent evidence for paths the tooling cannot see. A clean review means the checks that ran did not fail, not that every possible path is sound.

How to cover the blind spots

Use the review for what it does well, then close the gaps deliberately.

1. Run dynamic tests and smoke calls to cover behavior static analysis cannot reach.
2. Exercise framework entry points and dynamic loading paths explicitly.
3. Map external consumers so unused-looking files are not removed by mistake.
4. Keep a person on design and product-intent decisions.
5. Re-run the review after adding checks so the verdict updates.

Powerduck states these limits rather than hiding them, and it keeps each finding tied to reproducible evidence so you can tell what was verified and what remains unknown.

Frequently asked questions

Does a clean review mean the code is safe to ship? No. It means the checks that ran did not fail. Dynamic loading, external consumers, and runtime behavior can still hide defects, and the review does not prove correctness.

Can I delete a file with no incoming references? Not on that evidence alone. Dynamic loading or an external consumer may call it. Confirm there is no runtime or outside caller first.

Does the tool run the app to catch runtime defects? No. It does not run the app. Use tests and smoke runs for runtime behavior, and treat missing scripts as unverified.

The bottom line

AI code review is a strong structural reader, but it has fixed blind spots: dynamic loading, framework entry points, external consumers, and runtime behavior are all outside its static view, and model-only notes can be wrong. Cover those with dynamic tests, smoke runs, and human judgment, and never read a clean review as a correctness certificate. The tool narrows your attention; it does not remove the need to verify what it cannot see. More in the AI code review guide.