Farol Explained: A Pull Request Risk Map After AI Code Review

Winnin's Farol is an open-source tool that helps a human decide where to spend attention after an AI code review. Its current npm release arrived on October 24, followed by a Show HN introduction on October 25. It maps changed code to affected pages and APIs, then ranks review priorities.

The useful distinction is that Farol does this with static analysis rather than another model. A coding agent can explain a diff, but a reviewer still needs to know which existing workflows depend on the changed function. That is the question Farol tries to make easier to answer.

What Farol actually adds

The project offers a command-line tool and GitHub Action under the MIT license. It produces JSON, Markdown and an interactive HTML report, with three review categories: fast track, quick review and careful review. It advises the reviewer without approving a pull request or blocking its merge.

Its first public source release was October 21. Version 0.1.2 added the root-level Action entry used for GitHub Marketplace, while the current 0.1.3 npm package removes Python bytecode from the distribution. Those packaging milestones should not be confused with all its analysis capabilities appearing this weekend.

Imagine an agent changes a shared price-formatting function. The diff may be small, yet the function could feed several customer-facing pages. Farol follows the code relationships and shows the route to affected entry points, giving the reviewer a more useful starting point than the number of changed lines.

How the risk map works

Farol compares the branch with its merge-base and builds a graph of code relationships. TypeScript analysis uses the compiler API and type checker, Go uses its parser and type information, and Python uses its abstract syntax tree with local type inference. The technical documentation describes where each approach is precise and where it falls back to broader module-level analysis.

The tool traces changed declarations back to supported pages, endpoints, jobs and other entry points. Coverage, lint and dependency-audit reports supplied by the team's existing pipeline add context. Missing coverage is shown as unverified rather than silently treated as a passing result.

For the pricing function, this separates two questions: which pages might change, and whether tests actually execute the changed lines. A heavily reused function with little coverage deserves a different review from an isolated addition, even if both pull requests contain similar amounts of code.

What the score does and does not mean

Farol combines weighted signals into a score from 0 to 100. Reach, uncovered changes, dependency changes and contract findings contribute to it. A breaking backend contract can require careful review even when the headline score alone would suggest less attention.

Treat this as a review-priority score, not a measured probability that a deployment will fail. The weights are heuristics. Farol's own calibration uses later reverts or fix-labelled commits touching the same files as a proxy for problems, which can miss defects or associate an unrelated fix with a change.

The project's decision log reports calibration across 662 commits in four repositories. That is useful early evidence, but it is not an independent benchmark across arbitrary production systems. No deployment or benchmark was run for this article.

There is another important detail in the scoring implementation: marking a file as reviewed removes its items from the remaining score. Reading code has not changed the deployed program. The falling number therefore also represents review progress, and should not become an automatic permission to merge.

Setup and supported projects

The CLI requires Node.js 22 or newer and Git. Go projects also need Go, while Python projects need Python 3.11 or newer. The package is available as @winninjs/farol; configuration tells it which language and routing structure to inspect.

The sensible first step is its routes command. Before relying on an impact map, check whether it recognizes the project's real entry points. Analysis can then compare a base and head commit, reuse existing test reports and generate the HTML review view.

Supported frontends include Next.js, React Router route tables and file-based TanStack Router. Backend support includes selected TypeScript, Go and Python frameworks, with contract analysis for GraphQL, FastAPI, Go handlers and gRPC. Support varies by stack rather than covering every routing convention uniformly.

The limits matter more than the verdict label

Runtime-built registries, dynamic imports and framework conventions outside the supported adapters can reduce visibility. The documentation explicitly excludes Vue and Svelte frontend adapters and Django REST Framework routers. When analysis cannot resolve a relevant construct, Farol is designed to flag uncertainty or widen the assumed reach.

The core analysis runs without executing the target application's code. That should not be stretched into a claim that the entire workflow has no network activity: GitHub commenting and optional Datadog enrichment use external APIs, and the HTML route graph can load a pinned Mermaid script.

Several commenters in the launch discussion questioned the report's density. Those are early reactions, not a usability study, but they identify a practical test: does the map reduce the reading needed to understand a change, or add another document to inspect?

For teams producing more code with agents, the practical opportunity is a clearer handoff to the person responsible for approval. A useful report shows why the shared pricing function deserves attention and what to test. Whether that improves release quality still depends on the reviewer following that evidence, rather than replacing judgment with another green-looking score.

I'm Paras. I work across AI, engineering and distribution.

I help technical founders turn product launches and engineering decisions into clear stories developers can understand and share.

Book a 30-minute call.