its rather theoretic, papers instead of ai apps, but might be useful. Fe if code review in your organization is used to sync people - ai assisted code review might be not helpful. Or if you value evolvability/maintainability/simplicity points in good review - agents won't help here with additional knowledge base either.
Besides local review via codex and Claude code, we are using GitHub Copilot with custom instructions. We just assign it as a reviewer in GitHub and a couple minutes later, the review is done. It raises a lot of issues which are valid and which I never had found. https://docs.github.com/en/copilot/tutorials/customize-code-...
Built my own using Claude Code; inside a gitlab job we call Claude Code headless. This works well. There is a tiny mcp server exposed to Claude so it can post inline comments. All existing comments are fed into the reviewer to avoid double posting. The quality of feedback is high. Most complexity is in the SHA management. For example after a rebase. Luckily LLMs understand git very well otherwise it would have been impossible for me.
Claude-Code and Codex in combination, combined with an IDE such as Google Antigravity or VisualStudio-Code are very powerful tools, if your company can invest in hardware the new Mac Studio and MacBook Pro allow optimized local inference through open-source tools such as: https://github.com/antirez/ds4
I don't use these tools, but wouldn't it be better to use them only after you do a manual review to see if they find anything you missed? Otherwise I could see reviewers getting false confidence and doing a less thorough review. This happens with seeing that unit tests pass.
Opencode, mainly because I appreciate how one of the founders treats the UX as a first class concern. Its a great tool to learn since it can help us pivot from the potential impending provider crisis where teams may start having to consider things outside of the large labs.
As my daily driver at home, I use Pi though because it doesn't get in your way and forces you to understand how the sauce is made.
Honestly I get awful results using this skill. The output is way better when I simply ask it to review the changes on my branch compared to origin/main
I have a special section related to code review in ai knowledge wiki here: https://github.com/sermakarevich/ai_knowledge_wiki/tree/mast....
its rather theoretic, papers instead of ai apps, but might be useful. Fe if code review in your organization is used to sync people - ai assisted code review might be not helpful. Or if you value evolvability/maintainability/simplicity points in good review - agents won't help here with additional knowledge base either.
Besides local review via codex and Claude code, we are using GitHub Copilot with custom instructions. We just assign it as a reviewer in GitHub and a couple minutes later, the review is done. It raises a lot of issues which are valid and which I never had found. https://docs.github.com/en/copilot/tutorials/customize-code-...
what custom instructions did you give it? standard stuff about your practices?
Built my own using Claude Code; inside a gitlab job we call Claude Code headless. This works well. There is a tiny mcp server exposed to Claude so it can post inline comments. All existing comments are fed into the reviewer to avoid double posting. The quality of feedback is high. Most complexity is in the SHA management. For example after a rebase. Luckily LLMs understand git very well otherwise it would have been impossible for me.
I mostly use CodeRabbit via GitHub PR
https://www.coderabbit.ai/
does it work well for you? did you do any fine tuning worth mentioning?
Claude-Code and Codex in combination, combined with an IDE such as Google Antigravity or VisualStudio-Code are very powerful tools, if your company can invest in hardware the new Mac Studio and MacBook Pro allow optimized local inference through open-source tools such as: https://github.com/antirez/ds4
I don't use these tools, but wouldn't it be better to use them only after you do a manual review to see if they find anything you missed? Otherwise I could see reviewers getting false confidence and doing a less thorough review. This happens with seeing that unit tests pass.
that's a good point and surely something to test out and see what works and what not
For Claude Code, I think the standard is Codex + Gemini. Why these two? Because it “covers” the blind spots the others would miss by themselves.
Github copilot is a little too opinionated, but we still use it to catch obvious stuff.
Codex on top of that with specific rules and syntax requirements.
Opencode, mainly because I appreciate how one of the founders treats the UX as a first class concern. Its a great tool to learn since it can help us pivot from the potential impending provider crisis where teams may start having to consider things outside of the large labs.
As my daily driver at home, I use Pi though because it doesn't get in your way and forces you to understand how the sauce is made.
Rolled our own with OpenCode, seems to work quite well and meets the goal of being vendor agnostic :)
/review in claude code - the skill pulls the PR from remote and review it. Can post comments also.
Honestly I get awful results using this skill. The output is way better when I simply ask it to review the changes on my branch compared to origin/main
claude code and github copilot
Frankly, coding with Claude Code and having Copilot read through the PR is complementary and helps to catch some things that slipped through
[flagged]
[flagged]
[flagged]
[dead]
[dead]
[dead]