AI code review

A typical AI reviewer is triggered by a pull-request webhook or a CI job. It assembles context from the diff hunks, the surrounding code of each changed function, related files found through a repository index or embeddings, the pull-request description and linked issue, and any repository instruction files; it then asks a model for findings and maps each one to a file and line range posted through the code host's review API. More elaborate tools run as agents that can open further files, run the test suite or invoke static analysers before commenting. Some teams also use the same machinery for summarising the change for human reviewers, which is often more reliably useful than the findings themselves.

The engineering problem is precision. A reviewer that posts ten speculative comments per pull request trains developers to ignore it, so products filter by confidence and severity, deduplicate, restrict comments to changed lines, and let teams suppress categories. LLM reviewers are comparatively good at local defects visible in the diff: missing null or bounds checks, off-by-one errors, unescaped input reaching a query or shell, swallowed exceptions, and mismatches between code and its docstring or tests. They are weak where the relevant fact is outside the context: business rules, cross-service invariants, authorisation that depends on configuration elsewhere, concurrency, and whether the change is the right design at all. Output is non-deterministic, so the same diff can yield different findings on a rerun.

AI review complements rather than replaces static application security testing. SAST tools apply deterministic, CWE-mapped rules with reproducible results and SARIF output suitable for audit trails; an LLM reviewer finds some issues rules cannot express but cannot demonstrate coverage. A known weakness is correlated blind spots: when the same model family that generated the code also reviews it, both may share the same misconception.

Two governance points matter. First, the pipeline itself is an attack surface: on public repositories the pull-request text and code are attacker-controlled and can carry prompt injection aimed at suppressing findings or, if the job has secrets or a write-scoped token, exfiltrating them, so the reviewer should run with read-only permissions and without secrets on fork contributions. Second, accountability stays human. NIST SP 800-218 (SSDF) practice PW.7 calls for reviewing and/or analysing human-readable code to identify vulnerabilities; an AI reviewer can be one documented input to that practice, but branch protection should still require an approving human review, and bot comments should never count as approval.