Launching today
LiveReview
Free, Risk-Aware Code Review: Auto Approve Low-Risk Changes
135 followers
Free, Risk-Aware Code Review: Auto Approve Low-Risk Changes
135 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
Dropbox Sign APIBuild eSignatures into your app with less work.
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.
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
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.
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.
curious how it handles a tiny diff in a scary file, like a one line change to auth config. that's the kind of pr i'd never want auto approved
@gevorgarakelyann It has a huge list of signals feeding into it. File size is only one of the parameters. We build a graph analysis of the entire code base -- for example if many other parts of code depend on auth module -- the risk profile will reflect that. We also have traditional ML, plus LLM semantic analysis. And the thing learns over time, so it gets better as you use it.
@shrsv the dependency graph part makes sense, small change + lots of things depending on it = high risk. thanks for explaining
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.
@lucasjpols Thank you, Lucas, for the support!
@lucasjpols Thanks Lucas <3