AI 智能體編寫及審查程式碼後，farol 如何指引最終審批者先看哪些檔案？

Nowadays we are creating a lot more pull request, mostly using AI, and we are also using an AI reviewer to do the first pass. The bottleneck resides now in the last approval which still is human-based (and should be). When a person opens a 30 file PR, he doesnt know which files deserves more attention, giving it roughly the same attention (in most cases almost none), as no tools shows which files deserves more attention.

Risk in a PR is distributed evenly, so attention also shouldn`t. A one-line change in a model used by several endpoints, a new route shadowing old ones, a major dependecy bump, or the changed lines that no test ever run deserves more attention then a renamed variable in a leaf component.

farol is an open source tool that was created to answer, basically, two questions for the approver before they start:

1. How risky is this merge? A grade from 0 to 100 and a verdict: fast track, quick review or careful review. No LLM involved, just static analysis, idempotent and predictable.
2. Where does the risk live? Which files, untested code, contract broken in API. Also what to test/check by hand. It builds a call graph for every change, the more central is the node in the graph, the riskier is the change.

How it works

farol is static analysis ONLY. No AI/LLM is involved in the score, so it is idempotent and reproducible by construction, no hallucination and it never executes the code nor touches the network while analyzing it.

It works building the project's dependency graph using the standard tools (Typescript compiler, go/types for Go and ast for Python), and for each changed file it works out the REACH of it, and walks back from every changed line to the entry points using it: React routes, Next.js pages, GraphQL operations, REST endpoints, CLI commands, FastAPI routes, Go handlers, Temporal workflows and more.

Then it reads the coverage report your CI already creates and keeps only what touches the changed lines:

• diff coverage: how well covered by test the changed lines are and which changed lines ran in the tests;
• lint and security on changed lines;
• dependency changes and advisories: a major bump, a 0.x minor, a vulnerable package;
• API contract changes: removed response fields or new required argument.

It weights each signal becomes a weight and the final score is sum of it.

The more central a file is (more entry points reach it) bigger is the weight, it decreases when the more the changed lines are covered by tests. A breaking contract change weighs a lot. A file that only declares types weighs almost nothing.

What the reviewer sees

The final result is an HTML artifact which farol can post as a comment on the pull request:

• the merge risk and the verdict;
• one sentence on where the risk comes from;
• Must check: what has to be verified by hand (breaking API changes, security findings, vulnerable dependencies, anything farol could not read);
• the High and Medium risk files, each with its share of the score and its coverage.

With this you can decide if you want to approve directly or review the files deserves more your attention, every time you check a file or risk it recalculates automatically the total risk, so you can approve as soon as you feel confident. It also includes other relevant informations, like who knows the file (through git blame). At the end, Results gives you a Markdown summary of what you checked, to paste back into the PR.

There is a live demo on a FastAPI + React PR where you can try the whole flow.

A real example

The demo is the artifact based on PR to FastAPI full-stack template. It gives a score of 69/100, with careful review needed, the first comment is:

Most of the risk comes from a breaking change to GET /api/v1/items/ and a security finding in items.py.

The PR added a breaking change when it removed the count field from the API response. It also finds a security issue on a SQL created using f-string. Neither of it is in the biggest file in this PR. The model file used in 23 endpoints is fully tested and for this reason it weight less in the final result.

What it does not do

It does not approve or blocks anything. The idea is to inform the person so he can decide the amount of effor he will put in this PR. It also does not replace reading the code. The point is to tell you which part to read first and most carefully.

It uses a heuristic. On large PRs it saturates (a 37-file PR easily reaches 90+), and there the count of reviewed files says more than the number. But even in that scenario you can easily find what are the riskiest files and give more attention to it, as it shows the individual risk for each file.

How it got here

The first version was posted on Show HN last weekend. We received a lot of feedback on the final report being larger than it should be, and also bad UI/UX. But even with that we received 100+ stars in a single day on github, it sinalizes to me that other people are suffering the same problem. Since the feedback i've already launched a new release with way better UI/UX and more straightforward findings.

farol also reviews itself.

Try it

To see it working and get the comment and the report on every pull request on your repo, add the GitHub Action (setup in the README) and point it to your coverage and lint reports.

Currently we support: React (React Router, Next.js, TanStack Router), TypeScript backends (GraphQL, REST, CLIs), Go (chi, gin, echo, net/http, gRPC) and Python (FastAPI, Flask, Django, Celery and more). MIT licensed.

Feedbacks are highly welcomed, and would love to know which languages/frameworks you wanna see it supporting next.

If anything looks wrong on your code, please open an issue. That is how we can keep improving the platform.