Farol: Find the Code That Still Needs Human Review After an AI Review
An AI reviewer already approved the PR, yet Farol still shows remaining risk. Which files does a human still need to read, and what does that score actually track?
- Farol gives a human approver a map of affected pages and operations, with the files worth reading first.
- Coverage, contract changes and missing evidence explain the assessment better than a score alone.
- Static analysis has limits; Farol reports uncertainty and leaves approval to the reviewer.
The review starts with what a change reaches
Winnin’s Farol is a CLI and GitHub Action intended for the person approving a pull request after an AI review. Its Start here view orders files by risk signals and links changes to affected entry points.
The analysis pipeline uses language parsers and type information to follow code relationships. It builds paths from changed declarations to pages, endpoints and other entry points. These are statically discovered connections, rather than a recording of production requests.
For an approver, that changes the question from how many lines moved to which features depend on them. A shared function can deserve attention even when its diff is short.
Missing evidence is a separate result
Farol consumes existing test, lint and security reports. Its signals describe different parts of a review:
| Signal | What it tells the reviewer |
|---|---|
| Diff coverage | Whether tests executed the changed executable lines. |
| Contract changes | Whether request or response shapes changed, such as a removed response field. |
| not verified | The corresponding report was not supplied. |
| unknown | Some code could not be analyzed and needs closer review. |
Coverage records execution; reviewers still need to examine what the assertions check. A contract warning raises another concrete question: was the change intentional, and have its callers been updated?
A score of 74 is not a measured outage probability
The scoring design explicitly describes its weights and thresholds as heuristics. A value on the 0–100 scale should not be treated as a calibrated prediction for a particular production service.
Marking a file as reviewed removes that file’s items from the remaining score. The number can therefore fall without a code change. It tracks outstanding review attention as well as the initial assessment; checking a box does not repair a defect or perform a manual test.
Check the entry points before trusting the map
The command reference provides routes to list recognized entry points and impact to show a file’s connections. Those views offer a practical starting point for checking whether the tool understands a project. Requirements include Node.js 22 or later and Git, with additional language tools for Go and Python.
Runtime-generated paths and dynamic calls can exceed static analysis capabilities. Language support does not imply support for every framework configuration. Constructs the tool cannot analyze need attention rather than an assumption that the affected code is isolated.
The security design separates the job executing PR tests from the job posting comments, and states that analysis does not execute the target repository’s code. Network behavior is command-specific: analyze stays offline, while comment contacts GitHub and optional usage contacts Datadog.
FAQ
Does Farol approve or block a merge?
No. Its stated role is to inform the human review.
Does a missing report count as a pass?
No. Missing evidence remains unverified.
Use the map to choose what to read and exercise next. The reasons behind the score—and the parts the tool could not understand—are essential to that decision.