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.
Open Code Review – An AI-powered code review CLI tool
41–50 of 89 posts
Re: Open Code Review – An AI-powered code review CLI tool
#42If 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?
> 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…
> 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)
Re: Open Code Review – An AI-powered code review CLI tool
#43Earlier quoted context omitted.
What, no they're not. You still need to analyze them to understand they are false positives. It's time wasted
Finding problems is optimizing for the customer. Avoiding false positives is optimizing for the developer. Which is right depends on your org's culture.
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.
Re: Open Code Review – An AI-powered code review CLI tool
#44I like the pattern of making a dedicated cli/harness and just build a skill to teach coding agents to use it.
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.
Re: Open Code Review – An AI-powered code review CLI tool
#45Earlier quoted context omitted.
Finding problems is optimizing for the customer. Avoiding false positives is optimizing for the developer. Which is right depends on your org's culture.
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.
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.
Re: Open Code Review – An AI-powered code review CLI tool
#46Ran it on a subset of 10 of the 50 PRs in this benchmark https://codereview.withmartian.com - 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)
[flagged]
Re: Open Code Review – An AI-powered code review CLI tool
#47I 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.
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…
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?
Re: Open Code Review – An AI-powered code review CLI tool
#48Rule files are in https://github.com/alibaba/open-code-review/tree/main/intern... (in Chinese)
An English rendering of the Java.md (Google Translate): https://github-com.translate.goog/alibaba/open-code-review/b...
Re: Open Code Review – An AI-powered code review CLI tool
#49I 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.
gitar.ai is flat with no limits
Re: Open Code Review – An AI-powered code review CLI tool
#50Earlier quoted context omitted.
Finding problems is optimizing for the customer. Avoiding false positives is optimizing for the developer. Which is right depends on your org's culture.
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.
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.)