Launching today

LiveReview
Free, Risk-Aware Code Review: Auto Approve Low-Risk Changes
266 followers
Free, Risk-Aware Code Review: Auto Approve Low-Risk Changes
266 followers
Most AI review tools flag issues. LiveReview promises production results: fewer incidents, fewer rollbacks, less senior reviewer load. Every PR is risk-scored. The lowest-risk 30-50% are safely auto-approved; the risky ones go straight to the engineers who should see them. The approach is inspired by Meta's highly successful internal AI review system, where production incidents fell 50x and rollbacks 3x. LLM + incident-trained ML + code-graph analysis. Free and self-hostable.







Free Options
Launch Team

LoomHit record, hand off to AI
Promoted
In February, you helped git-lrc reach #3 Product of the Day. Thank you.
git-lrc fixed one problem: developers committing AI-written code they hadn't read.
As teams adopted it, a bigger problem showed up at the pull request.
AI made code cheap to write. Reviews stayed expensive.
Every PR waited in the same queue for the same few senior engineers.
A renamed variable and a rewritten payment flow got the same attention.
Seniors became the bottleneck. They skimmed. RISKY changes slipped into production.
Most AI review tools add more comments to the thread.
We measure review by production outcomes: fewer incidents, fewer rollbacks, less senior reviewer time.
LiveReview follows the approach behind Meta's highly successful internal AI review system, RADAR: score every change for risk, fast-track the safe ones, and send the risky ones to the right reviewers.
At Meta, this led to 50× fewer production incidents, 3× fewer rollbacks and 35% faster reviews.
Here's how LiveReview does it:
- Auto-approve: the lowest-risk 30–50% are approved instantly. The rest ALWAYS get a human reviewer.
- Risk-first review: high-risk PRs go to the top of the queue with comments sorted by blast radius, sent to the engineers for review.
- Cognitive Coverage: walk through a PR as slides or a summary, or quiz yourself on it before it merges. Your team still understands the code AI writes.
- Livi Assistant: ask about your engineering data in plain English, on the web or in Slack, Teams and Discord. Track adoption, ROI and the teams that need attention across 50+ actionable graphs.
- Integrations: GitHub, GitLab, Bitbucket, Gitea and Azure DevOps.
- Any AI model: reuse the Claude or OpenAI key you already pay for, or any of 15+ AI providers, or use the LiveReview model.
LiveReview is FREE and SELF-HOSTABLE. Run it on your own infra.
See how it works, then hit Try Free: https://hexmos.com/livereview/
If you like what we're building, star it to help devs discover LiveReview: https://github.com/HexmosTech/LiveReview
@shrsv
noticed you feed production incidents back into the risk score unlike coderabbit.
btw how many merges or rollbacks does the ML need to process before that 30-50% auto approve rate actually becomes reliable for a new team?
@mohsinproduct That's highly org/codebase/deployment specific, but even a few days worth of data can will quickly capture "hotspots" and improve the classification significantly. There are also "high severity" but "rarely changed" things -- which do not become exposed this way. But for most orgs even 2 weeks good enough to capture the landscape I'd say.
@mogabr Hoping to make a contribution to the world of engineering -- including newcomers entering this field!
congrats on the launch shrijith. auto approving low risk prs is where i would be careful. a tiny pricing or config change can look harmless in code but still affect customers. can those be marked as risky too?
@agshin_rajabov Thanks Agshin, for engaging!
Short answer: Yes, the size of the code is only one of the signals we use. We have blast radius analysis based on AST, production feedback, keywords, approval levels and such things to make it more intelligent.
On top of that -- the ML system can learn over time from production behaviors (incidents, rollback) to know which parts of code are tricky, etc as well.
The thing is -- over time -- the system level performance will improve -- lower downtime, reduced incidents, rollbacks, etc. So we aim for that.
By the way you can read Meta's RADAR paper on how this kind of system works in a real world case study: https://arxiv.org/abs/2605.30208
Free and self-hostable with my own Claude key is the part that would actually get me to try it — I don't love routing my code through another hosted reviewer. As a solo dev, the Cognitive Coverage bit is what caught my eye: walking a PR as slides before merging is a nice answer to the 'AI wrote it, I skimmed it' problem.
@jcbuilds We do have a docker image at our Github, you're welcome to try it out. Although we also have a cloud version for quickly understanding how it all works at a high level. And we support pretty much all major providers (you can mix and match) -- so that shouldn't be a problem as well.
before an org has recorded any reverts or incidents, how much weight does the custom ml model get in the risk score?
@bbueno Hi Bruno, thanks for engaging!
When there is no production feedback data, there is no impact from the ML learning component. We go by graph based blast radius analysis, LLM semantic analysis, keyword analysis, code complexity metrics, reachability and many other such signals.
@shrsv makes sense, thanks Shrijith
Does anyone on your own team actually take the quiz before merging?
@leoheo It's not an enforced thing (I feel it's too much to ask), but I do take a look at it whenever I'm shipping something complex. Not for usual fixes, etc.
The slide view is something we use even more extensively from comprehension perspective.
Does Cognitive Coverage also run on the PRs that get auto-approved, or only on the ones routed to a reviewer?
@naw103 Hi Nick, thanks for checking LiveReview out! Cognitive coverage is available on every new review, whether auto approved or not.
Congrats on the launch. Can we customise some particular kind of diffs so that they go to the reviewer despite having lower risk score?
@muhammedrasin Do you have a particular example in mind?
We do have customization for increasing the importance of various dimensions such as correctness, security, performance, cloud costs, etc.
You can also specify employee levels, so interns, etc always get reviewed (until their level increases).
We are also planning "keyword based" assignment -- so if particular trigger words there it'll goto reviewers.
But if you're thinking some other way of doing this -- let me know, happy to support.