A few weeks ago I pointed a hand-built risk digest at unkey, a real open-source auth and API-keys codebase with 58 open pull requests, and asked it one question. If I were the senior on this team, which five would I want to look at before they merge?
Here is what came back at the top.
A billing change pushing month-to-date deploys to Stripe that also carried a database migration, bumped a dependency lockfile, and had failing CI. A second Stripe change, only 265 lines, but it touched subscription deletion...money-handling code where a small mistake is expensive. A 1,720-line database migration with no test files touched at all.
Notice what put those at the top. It was not size. The second one was tiny. They are at the top because of where they land and what they carry: money code, a schema migration, a dependency lockfile, a red build. Blast radius and correctness, not line count. That is the thing I have spent years learning to scan for the second a PR shows up.
The digest was not perfect, and I will be honest about that. It also flagged a dark-theme CSS change as touching authentication, billing, and secrets. It was wrong, for a dumb and useful reason: it matched on file paths that sit under routes named "auth" and "keys," not on code that actually touches auth. Touching a sensitive-named path is not the same as touching sensitive logic. I am still building this thing. But even when it was wrong, it was wrong in a fixable way, and it was right about the ones that mattered.
Here is what I keep coming back to. On a small team, senior attention is the scarcest resource you have. And the review pipe treats every pull request exactly the same...a 4-line config change and a 1,720-line migration wait in the same queue for the same eyes. The risky ones do not announce themselves. So the thing that actually breaks is not that nobody reviews. It is that the scarce attention gets spread evenly across changes that carry wildly different risk.
What I want is easy to say and apparently hard to get. I want the scarce attention to go where the risk actually is.
And once you start looking at it that way, you notice the question "where should attention go?" does not start or stop at the pull request. It starts when the ticket gets written, because some planned work is risky before a single line exists, just from what it will touch. It runs through the PR, the part I just showed you. It shows up in patterns across the team, the areas that keep generating risk, the places where someone is working in unfamiliar territory and could use a second set of eyes. And it rolls all the way up to a question every engineering leader should be able to answer and almost none can: how much risk are we carrying right now?
That is what I am building. It is called Merge Lantern, and it is a risk intelligence platform for engineering teams. One connected view of where risk lives across your whole software delivery lifecycle: from the ticket that gets written, to the PR that gets merged, to the patterns that emerge across your team, to how much risk you are carrying as a business. It does not review your code for you. It tells you where to look first, and how much risk you are holding.
The risk you ship hides in the dark.
The PR risk digest is the piece that is real today: every morning, a short list of the open PRs most likely to need senior attention, with the reasons attached. The other three layers are the roadmap, and I am building them in the open, one at a time.
If "send me that every morning" is something you would want for your team, I am opening the waitlist now. mergelantern.com
Top comments (1)
Great write-up — the framing of “risky PR signals” is especially useful because most teams only evaluate PRs at code level, not system impact level.
One thing I’ve seen work well in practice is adding a lightweight “blast radius layer” before human review. Instead of only looking at diff size or files changed, you can enrich PRs with:
Ownership map (which services/modules are touched)
Runtime exposure (API routes, cron jobs, background workers)
Change type classification (logic vs config vs dependency vs infra)
Hidden risk flags (auth, payments, migrations, concurrency paths)
Then combine that with a simple risk score surfaced in CI (not to block, just to guide reviewers). It makes the “this feels risky” intuition explicit and consistent across teams.
Also interesting direction: pairing this with feature flags + automatic rollback hooks can reduce the review burden even further, because high-risk PRs become safe-by-deployment instead of safe-by-review-only.
Curious if you’ve tried formalizing risk signals into tooling, or if you mostly keep it as reviewer intuition + checklist today?