- very good recall (~74%, e.g. found a lot of the golden issues)
- not so good precision (~12%, e.g. lots of false positives)
- the precision causes the F1 to tank (~20%, if this stays the same on the full 50 sample it would puts it almost last, even less than Kilo+Grok)
akie 4 hours ago [-]
I would say that recall is the most important metric here though. I'd want it to catch all the issues.
False positives are easy to ignore.
witx 4 hours ago [-]
What, no they're not. You still need to analyze them to understand they are false positives. It's time wasted
chaoz_ 10 minutes ago [-]
Agree, it's something that will eventually teach your developers to ignore points raised as it's mostly garbage.
onion2k 3 hours ago [-]
Finding problems is optimizing for the customer. Avoiding false positives is optimizing for the developer. Which is right depends on your org's culture.
evolve-maz 2 hours ago [-]
If I flag every line in your PR as a potential security bug then I have 100% recall.
Obviously you need a mixture of high recall and low false positive rate. If 7/8 flagged items are fine its much more likely people will ignore the warnings, much like they would any security tool with a 90% false positive rate. That is not optimized for the customer.
onion2k 2 hours ago [-]
The ideal is finding all the problems without getting any false positives, but the reality is that you can't often have that. An org's engineering culture should be designed to fix problems with systems. If you're seeing an 87.5% false positive rate that should be seen as another engineering problem to fix. However, that's a separate issue to whether or not you accept false positives in a system designed to find problems.
Presenting it as either a system that misses real problems or a system that has a huge number of false positives is a false dilemma. You can have a system that's designed to find all the problems and then optimize it to reduce the false positives. If you can't reduce the number then you optimize to identify false positives as fast as possible. Just ignoring the identified problems on the assumption that they're false is giant red flag and a signal that the org has a very a broken engineering culture (but, as you say, that's quite common.)
eranation 2 hours ago [-]
Yep. Similarly - you can predict with 99.9% accuracy if a Volcano will erupt today by using a rock that has "No" written on it.
williamdclt 40 minutes ago [-]
> If I flag every line in your PR as a potential security bug then I have 100% recall.
No. A code review isn't about "flagging a line of code", it's about identifying an issue or a risk. If a 10-line PR has one issue and you leave a comment on every single character, if you still miss the issue you have 0% recall.
But the user experience is tricky because if we aim for very low false positives the run time for this kind of workflows is too long, it's then hard to justify blocking PRs.
faangguyindia 8 hours ago [-]
If you've codex what does it add over codex's default app? I am confused. Can't you simply ask codex in another tab to just do a code review?
eranation 6 hours ago [-]
Developers should definitely use whatever tool they use to review the code they (or the tool) just wrote. We have a skill that does this in a loop - spin subagents, review (based on our coding standards), triage the review in another subagent, fix what's applicable, push back on what's not, and we run this in a loop. This is before you even open a PR.
The idea of a PR is for others to find things that you have a blind spot to, and also leave some paper trail on the thought process. E.g. if something was not fixed, there is a history of a comment and a reason on WHY it wasn't fixed. If you do all that only locally, that context is lost.
We noticed that even after doing this self review loop multiple times, we still find issues (either via other models / tools or via humans that have the "tribal knowledge")
Maybe one day AI will write perfect code and can review itself, but even if it's 0.1% chance it has a bug, or 1 in a million it will do something a bit sinister (like open a backdoor just in case you try to shut it down) - then I really think there is always going to be a need for humans to review something.
> Can't you simply ask codex in another tab to just do a code review?
You are likely to get better results if you do not use the same model for review that wrote the code. I typically use Opus for code editing and GPT 5.5 for peer review using an automation with skills.
Training set is different between models. If there are gaps in coverage in one model, you want a different model reviewing the work. The second model will its own gaps, but the gap list is not identical.
sdevonoes 2 hours ago [-]
> You are likely to get better results if you do not use the same model for review that wrote the code
There’s no evidence of this. I guess you are anthropomorphising models (i.e., it’s good that - different human reviews your code)
embedding-shape 47 minutes ago [-]
Yeah, one model over another seems to matter less, they respond differently to the same prompts, so if anything, I'd use multiple prompts over choosing one model over another.
However, using two models to generate two reviews easily beats doing one model and one review, as some models seem to "care" more about certain things, but you'll just miss different things if you change the model rather than add more.
krzyk 4 hours ago [-]
Results also depend on the prompt. You get different results if you ask to review the PR and focus on particular file than if you don't make it focus.
Or if you make it "be a security engineer" with particular focus points.
Or make it a grammar nazi, it will find way more typos than without such focus.
Of course all of those "focuses" needs to be in a separate context (agent/subagent) to make it work.
Art9681 7 hours ago [-]
I would suggest that you reverse those roles. gpt-5.5 as the implementer and Opus as the reviewer.
hombre_fatal 6 hours ago [-]
They find different things, and there's no reason to use one model for review. You want to review it until there's nothing left to be unearth.
And if you put the review effort into polishing an impl plan, then it doesn't matter which model implements it either.
pluralmonad 7 hours ago [-]
How come? I find Opus to have better taste and GPT to have more rigor.
eyeris 8 hours ago [-]
Presumably nothing. Do note the publisher—Alibaba presumably would rather their own tools and models instead of licensing.
They do open source a fair bit of internal tooling, so it’s always interesting to see their approach
krzyk 4 hours ago [-]
It can be used outside of local machine.
We built something similar, it looks for new PRs where the bot is added and does reviews. Makes the code more tuned toward similar rules. I can't assume that a developer run a code review tool himself (just as I don't assume he/she run a build - so we run builds also).
It is just another perspective for code review, besides human. Unfortunately it uses a lot of tokens, and considering that Anthropic, OpenAI and Github Copilot all moved to token based pricing, it is quite a money burner.
esafak 8 hours ago [-]
We'd need a benchmark to tell.
elpakal 8 hours ago [-]
At a kill s@@s hackathon at work, I was able to build something that
uses a node image
installs claude code
runs a /review-like command
puts inline comments to PR
deletes old comments when rerunning
OCR seems cool, but overkill, and I'm definitely not using Code Rabbit after their CEO was on here acting snobbish a while back.
Point being AI code review in Git** itself isn't hard to do and can add a lot of value quickly.
It's very easy to build a basic code review tool.
It's hard to build one that developers won't ask you to turn off because of false positives (or one that will miss your next escaped bug)
I think if all the tool does is run a claude code level /review skill (which all developers should definitely run before they even open a PR) then isn't this a bit of a review theater? Just a guardrail to those developers who don't run a /review-triage-fix skill in /loop before they take the PR out of draft?
I wonder how many PRs in the world got to production where several developers commented on each other's code, and none of them read anything, just used their gh cli / MCP to post / answer comments / fix issues on their behalf.
There is going to be an exponential growth of code generated, and you can't escape AI code review, but also there is no real difference between having Claude Code write the code and review itself locally, vs communicating with itself via a slow and downtime prone medium of "PR comments"
tl;dr - without any human in the loop reviewing the AI code review, or skimming to see what the AI code review missed, there is no real reason to use a "code review" you can just run it as part of the CI/CD and hope AI won't miss anything (according to my linkedin feed, there are people out there who really thing this way...)
krzyk 4 hours ago [-]
I think that in most cases you either agree on a PR comment or you don't. But it has to leave a mark in PR. This is how we do reviews, ignoring PR comment is one of the worst offenses one can make. I don't let it go.
s900mhz 6 hours ago [-]
Yes! Where it gets really interesting is the scenario in which every developer has their own unique review skill/workflow, so the reviews end up being different than you running it yourself, but nobody is reading them still.
gardnr 7 hours ago [-]
How snobbish was the CEO acting?
singingtoday 9 hours ago [-]
I'm interested in trying this.
We have our own internal automated review which has shown positive results, but I would love to drop it if I find something better.
Code review is currently our bottleneck, so any possibility of better automating it is welcome.
Some of them are about general coding guidelines and code quality, not necessarily vetting your current PR against specs! There's AbsolutelySkilled with clean-code and clean-architecture. Linking to older version of repo because they seem to be no longer on trunk: https://github.com/AbsolutelySkilled/AbsolutelySkilled/tree/...
this is a great tool, until you try reading the rule files, I had find a translator to make heads of it. given that it is CLI tool is great dev the tinker with it at no additional cost.
pi-victor 3 hours ago [-]
i did something like this, but somewhat in reverse. you are the one that reviews the code and you instruct AI what to do through code review comments: https://parley.cloudflavor.io.
thinking about it, it would be funny to first run alibaba's tool and then run parley after.
Just a small note, the font on your site is very annoying to read, the characters are not aligned horizontally (Windows w Chrome). Looks to be a scaling issue, if I zoom to 200% it shows fine.
pi-victor 1 hours ago [-]
ah, sorry about that - will try to see what is going on. thanks for letting me know!
sfortis 3 hours ago [-]
Is not working with gpt5.x models (Unsupported parameter: 'max_tokens' is not supported with this model. Use 'max_completion_tokens' instead.) which is hardcoded. I dont know why this is on the front page. My review-with-codex skill is working just fine, consuming my usage and not API tokens.
weird-eye-issue 5 hours ago [-]
> After installation, the ocr command is available globally.
Wish they chose a different acronym...
altmanaltman 5 hours ago [-]
[dead]
atestu 8 hours ago [-]
We've been using Coderabbit, great deal ($30/mo/dev flat) and finds a lot.
I also built a skill I call `/meta-review` that asks Codex, Cursor, and Gemini to review the code (I use Claude Code). It always finds little things claude & I missed.
Not sure why you got downvoted, and I have nothing against CodeRabbit, but this comment feels a bit like a paid ad :)
How do you see CodeRabbit against other AI code review solutions? E.g. cubic.dev, Qodo, Graphite, Greptile, Baz, Augment Code...
An alternative UI to GitHub is well overdue. But once someone will get it right, everyone will copy them...
causal 8 hours ago [-]
Is it actually flat fee? I loved Cursor bugbot which was flat fee but they moved to per-run and that killed it for me, but a lot of others are doing the same.
atestu 7 hours ago [-]
Yes! They just have a rate limit but we never run into it (we’re just 3 people though).
Yea I liked bugbot too but it became pretty pricey.
lukaslalinsky 6 hours ago [-]
I've tried many AI code review tools. Nothing comes close to the depth of CodeRabbit reviews. It's the only such tool that can find real logical bugs. I'd love to be able to get Claude Code to do similar quality of review, but I can't get it right, no matter how I try.
eranation 7 hours ago [-]
I wonder how they do against this benchmark (not that I vetted this benchmark... but still interesting to know...)
I recently moved off Cursor's BugBot because it's no longer a flat $40, and I feel a little lost trying to find a viable alternative because there are so many and the pricing kind of sucks for all of them. Curious if anyone has a recommendation.
lukeasrodgers 8 hours ago [-]
My team tried coderabbit and qodo and they are both trash compared to a tool we quickly built in-house that is more or less a thin wrapper around claude/codex, along with per-repo skills. PR review is triggered by webhooks from github to the review tool's web app. The tool shared by OP from alibaba certainly does some things ours does not and appears more sophisticated, but we have never had the problems they mention.
"The agent can read full file contents, search the codebase, inspect other changed files for context, and produce deep reviews — not just surface-level diff feedback." our tool does all this too. It catches dumb typos as well as more complicated bugs. Not to mention it is great as a ratchet (https://qntm.org/ratchet). It is not a substitute for reviews from other engineers though, since obviously it does nothing to achieve one of the main goals of code review, which is to socialize knowledge of the codebase.
Alibaba's work here is almost certainly more advanced than what we've done, but ours has been perfectly satisfactory and better than the paid offerings we've tried. I think most teams should not be paying SaaS fees for AI code review, that is the kind of business that mostly should not exist any more.
mrklol 2 hours ago [-]
In which areas do you feel like the mentioned are bad? Do they find less and your own solution has more success?
If the latter, do you know why?
kageiit 2 hours ago [-]
gitar.ai is flat with no limits
songting591 1 hours ago [-]
[flagged]
AashmanShukla 4 hours ago [-]
[flagged]
Aegis_01 5 hours ago [-]
[flagged]
xuanlin314 8 hours ago [-]
[flagged]
lizhengfeng101 6 hours ago [-]
[dead]
Rendered at 10:10:02 GMT+0000 (Coordinated Universal Time) with Vercel.
The original rules files (in Chinese): https://github.com/alibaba/open-code-review/tree/main/intern...
- very good recall (~74%, e.g. found a lot of the golden issues)
- not so good precision (~12%, e.g. lots of false positives)
- the precision causes the F1 to tank (~20%, if this stays the same on the full 50 sample it would puts it almost last, even less than Kilo+Grok)
False positives are easy to ignore.
Obviously you need a mixture of high recall and low false positive rate. If 7/8 flagged items are fine its much more likely people will ignore the warnings, much like they would any security tool with a 90% false positive rate. That is not optimized for the customer.
Presenting it as either a system that misses real problems or a system that has a huge number of false positives is a false dilemma. You can have a system that's designed to find all the problems and then optimize it to reduce the false positives. If you can't reduce the number then you optimize to identify false positives as fast as possible. Just ignoring the identified problems on the assumption that they're false is giant red flag and a signal that the org has a very a broken engineering culture (but, as you say, that's quite common.)
No. A code review isn't about "flagging a line of code", it's about identifying an issue or a risk. If a 10-line PR has one issue and you leave a comment on every single character, if you still miss the issue you have 0% recall.
Done that way mainly to see how the Google Translate version compared with a ChatGPT translation (revision: https://gist.github.com/embedding-shapes/7a51d565214bd676890...)
At $work we built a thorough workflow to do security reviews, which is a pure skill to simplify adoption https://www.synthesia.io/post/automating-code-security-revie...
But the user experience is tricky because if we aim for very low false positives the run time for this kind of workflows is too long, it's then hard to justify blocking PRs.
The idea of a PR is for others to find things that you have a blind spot to, and also leave some paper trail on the thought process. E.g. if something was not fixed, there is a history of a comment and a reason on WHY it wasn't fixed. If you do all that only locally, that context is lost.
We noticed that even after doing this self review loop multiple times, we still find issues (either via other models / tools or via humans that have the "tribal knowledge")
Maybe one day AI will write perfect code and can review itself, but even if it's 0.1% chance it has a bug, or 1 in a million it will do something a bit sinister (like open a backdoor just in case you try to shut it down) - then I really think there is always going to be a need for humans to review something.
Like with "SKILL" files in general, it's got to do with Prompt Engineering: https://en.wikipedia.org/wiki/Prompt_engineering#Rationale
You are likely to get better results if you do not use the same model for review that wrote the code. I typically use Opus for code editing and GPT 5.5 for peer review using an automation with skills.
Training set is different between models. If there are gaps in coverage in one model, you want a different model reviewing the work. The second model will its own gaps, but the gap list is not identical.
There’s no evidence of this. I guess you are anthropomorphising models (i.e., it’s good that - different human reviews your code)
However, using two models to generate two reviews easily beats doing one model and one review, as some models seem to "care" more about certain things, but you'll just miss different things if you change the model rather than add more.
Or if you make it "be a security engineer" with particular focus points.
Or make it a grammar nazi, it will find way more typos than without such focus.
Of course all of those "focuses" needs to be in a separate context (agent/subagent) to make it work.
And if you put the review effort into polishing an impl plan, then it doesn't matter which model implements it either.
They do open source a fair bit of internal tooling, so it’s always interesting to see their approach
We built something similar, it looks for new PRs where the bot is added and does reviews. Makes the code more tuned toward similar rules. I can't assume that a developer run a code review tool himself (just as I don't assume he/she run a build - so we run builds also).
It is just another perspective for code review, besides human. Unfortunately it uses a lot of tokens, and considering that Anthropic, OpenAI and Github Copilot all moved to token based pricing, it is quite a money burner.
uses a node image installs claude code runs a /review-like command puts inline comments to PR deletes old comments when rerunning
OCR seems cool, but overkill, and I'm definitely not using Code Rabbit after their CEO was on here acting snobbish a while back.
Point being AI code review in Git** itself isn't hard to do and can add a lot of value quickly.
It's very easy to build a basic code review tool. It's hard to build one that developers won't ask you to turn off because of false positives (or one that will miss your next escaped bug)
I think if all the tool does is run a claude code level /review skill (which all developers should definitely run before they even open a PR) then isn't this a bit of a review theater? Just a guardrail to those developers who don't run a /review-triage-fix skill in /loop before they take the PR out of draft?
I wonder how many PRs in the world got to production where several developers commented on each other's code, and none of them read anything, just used their gh cli / MCP to post / answer comments / fix issues on their behalf.
There is going to be an exponential growth of code generated, and you can't escape AI code review, but also there is no real difference between having Claude Code write the code and review itself locally, vs communicating with itself via a slow and downtime prone medium of "PR comments"
tl;dr - without any human in the loop reviewing the AI code review, or skimming to see what the AI code review missed, there is no real reason to use a "code review" you can just run it as part of the CI/CD and hope AI won't miss anything (according to my linkedin feed, there are people out there who really thing this way...)
We have our own internal automated review which has shown positive results, but I would love to drop it if I find something better.
Code review is currently our bottleneck, so any possibility of better automating it is welcome.
Some of them are about general coding guidelines and code quality, not necessarily vetting your current PR against specs! There's AbsolutelySkilled with clean-code and clean-architecture. Linking to older version of repo because they seem to be no longer on trunk: https://github.com/AbsolutelySkilled/AbsolutelySkilled/tree/...
I've been creating some rules to help with my Java coding: https://github.com/bitkentech/shipsmooth/tree/main/skills/ex.... These are assembled into a SKILL file when this skill file template is built: https://github.com/bitkentech/shipsmooth/blob/main/skills/ex...
thinking about it, it would be funny to first run alibaba's tool and then run parley after.
posted it here a few days ago: https://news.ycombinator.com/item?id=48369782 i guess with AI there are too many Show HN now, and i never got any type of feedback.
Wish they chose a different acronym...
I also built a skill I call `/meta-review` that asks Codex, Cursor, and Gemini to review the code (I use Claude Code). It always finds little things claude & I missed.
Coderabbit just came out with their own PR review UI that's great for big PRs, it groups files together etc. https://www.coderabbit.ai/blog/introducing-atlas-the-first-a...
How do you see CodeRabbit against other AI code review solutions? E.g. cubic.dev, Qodo, Graphite, Greptile, Baz, Augment Code...
An alternative UI to GitHub is well overdue. But once someone will get it right, everyone will copy them...
Yea I liked bugbot too but it became pretty pricey.
https://codereview.withmartian.com
"The agent can read full file contents, search the codebase, inspect other changed files for context, and produce deep reviews — not just surface-level diff feedback." our tool does all this too. It catches dumb typos as well as more complicated bugs. Not to mention it is great as a ratchet (https://qntm.org/ratchet). It is not a substitute for reviews from other engineers though, since obviously it does nothing to achieve one of the main goals of code review, which is to socialize knowledge of the codebase.
Alibaba's work here is almost certainly more advanced than what we've done, but ours has been perfectly satisfactory and better than the paid offerings we've tried. I think most teams should not be paying SaaS fees for AI code review, that is the kind of business that mostly should not exist any more.
If the latter, do you know why?