Show HN: Farol – A risk map of a pull request for the person who approves it

An engineer where I work built something like this so that when QA is about to deploy, they have a better indication of who to call and what is potentially going to be impacted. Our implementation is done prior to production deploy (which requires human approval) and compares currrebt deployed build code to new build changes diff and then analyses. I think there is a lot of room for tools like this in the future. Scoping/homing/etc

IDK lot of noise in report, I need more signal to noise ratio, already reading so much AI output as it is.

But the example PR... It said code generate with Claude, is it really still this bad? Last I was using SQLAlchemy with Claude was Opus 4.5, and it took some heavy coaching and skill gen not to generate code like this--but why even use SQLAlchemy at all if you're just going to use string interpolation jeez

https://github.com/erich-oliveira-winnin/full-stack-fastapi-...

    owner = "" if current_user.is_superuser else f"WHERE owner_id = '{current_user.id}'"
    query = f"SELECT status, count(*) FROM item {owner} GROUP BY status"
    rows = session.execute(text(query)).all()

it's hard for me to imagine something made with so little taste can be any good...

This looks nice, but I would use it with caution.

There was a post here recently, "Using LLM for confidence scoring is a bad idea", my mind went immediately to using LLMs for scoring risk. Seems like a bad idea. If there's anything we still need a human for, it's assessing risk.

Good idea. Do you take bribes to exclude certain lines from the risk map? Asking for my good friend Jia Tan.

>> Claude Code lives in its own repository, separate from the monorepo

I thought mono meant one.

I think tools like this are needed and will become standard in the near future.

However, the backend demo report seems longer and more complex than just reading the code. I’m trying to build something similar as well, and no one has quite nailed this yet.

The risk map / assisted review needs to be succinct and information dense, to guide your attention. My current philosophy is that we need to be annotating code, not replacing the entire code review interface with a bunch of text.

Looked at the backend demo, and the first lines suggested to look at were importing things. Exactly what I really don't need to be reviewing

I want off this train. Please, make it stop…

why is the only comment by the OP flagged and dead? Is it because they were supposed to include that data in the description text rather than a comment, was it flagged as AI generated, or..?

Trying to understand why the poster's own comment was flagged and killed but the original article remains up.

I like the concept, a risk map could be useful in some circumstances but I absolutely hate the UI design; it reeks of AI with no human thought or care put into it.

Or you could, you know, read the changes your approving

[flagged]

[flagged]

[flagged]

[flagged]

[flagged]

Hi HN, I built farol at Winnin, where we open-sourced it (MIT).

AI agents now write a lot of our code, and AI reviewers catch a lot of the line-level problems. But someone still has to press "merge", and that person has the same question every time: how risky is this, and where should I spend my attention? A 40-file PR where 38 files are isolated is very different from a 3-file PR that changes a model used by 23 endpoints.

farol is a CLI (and a GitHub Action) that answers that statically:

- classifies the PR (global / touches-existing / isolated / unknown) and gives a 0-100 merge risk score - ranks the files by risk and says why: what each one reaches (routes, endpoints, jobs), contract breaks in API responses, dependency changes, security patterns - diff coverage from your existing coverage report, so "38% of the changed lines are tested" sits next to the risky files - an HTML report where you mark files as reviewed and the score and test plan follow; incremental mode for "what changed since my last review"; suggested reviewers from git blame

How: it uses the TypeScript compiler API for TS/React (React Router, Next.js, TanStack Router) and TS backends, a small go/types helper for Go, and Python's ast for FastAPI/Flask/Django and friends. No LLM, no network during analysis, and it never executes the analyzed repo's code. It's deterministic and informs only; it never blocks a merge.

Live demo (two reports from a real PR, nothing to install): https://winnin.github.io/farol/demo/

Try it on a branch: npx @winninjs/farol --help

Limitations: only TS, Go and Python for now, and the reachability is static, so dynamic dispatch and reflection make it fail closed ("unknown") rather than guess. I'd love feedback on the risk score and on false positives in your codebase.

[flagged]

[flagged]