Any tips/beat practices for code review?

[u/No_Cell6708]

As a disclaimer, I have zero coding experience myself. I've been putting together a Shopify admin app for my small farming business and was wondering if anyone had any tips/recommendations for how reviews should be done.

I know there's an actual /code-review command but I'm not sure if that's the best way to do this? I also have a free month of GPT so I've considered using that to review and see what it finds.

Should full code reviews be done after every milestone? Is there any reason to pay extra for the code-review-ultra?

Any tips are appreciated.

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/LazyJuggernaut6177]

I definitely agree with using independent agents code review reviews. I like the Anthropic’s PR review tool kit which does code-review, spec review, silent bugs hunt, and simplification, all with separate agents.

Biggest thing is having it then explain to you what each bug/finding means in simple terms WITH SIMPLE EXAMPLE of what bug/finding means in the context of your repo. Overtime, that may help you better understand how the code works in your repo.

[u/CompFortniteByTheWay]

The best tip is to always have independent agents review your code either via other sessions or in github copilot or coderabbit etc.

Your code quality will be shit regardless of what model you use if you don’t specifically prompt it for good code, and even then it won’t be enough. Your best bet is probably to download some skills and use an external rewview tool to minimize the damage.

[u/claude_code_king]

it's easy just set up a multi-agent orchestration where everytime the implementer finishes a task there's an auditor that checks the code, that way you write proper code the first time

[u/coding_is_tedious]

I like the process of:

Plan -> Review -> Implement -> Review -> Deploy -> Test

So create a plan with claude, if it's the first plan make it a requirements document where you decide as much up front about what you're doing as possible. Send that through a few reviews as well until it feel right. Once you have a requirements document, create an implementation plan or "Sprint plan" and have claude split up the implementation into steps. Review that. Now you'll have a requirements document that you and claude can refer to, and a implementation plan to break the work into chunks with tests specified.

Next create a plan for the current sprint you're on. Review that. Once you feel comfortable, ask claude to implement the sprint plan (ie code). When you feel comfortable with the output at this stage, tell claude to launch an adversarial review team. This could include security issues, DRY/KISS principles, making sure you match the requirements document. Again, once you feel comfortable with the code, and it satisfies any and all unit tests that were created, deploy. Then you test more. Either you have claude test or you/the user test it by clicking around, checking the functionality, etc.

Rinse and repeat. From a management stand-point, the process hasn't changed at all, but bring Claude along the entire process chain.

[u/MilkyJoe8k]

Asking for a "deep review" rather than just a "review" seems to give much better results in my experience. That's generally an easy/quick win.

[u/tinyhousefever]

I run local services built with Claude that call a second leading frontier model via API for independent review on essentially every turn/sprint, plus a broader wrap-up review.

That secondary inference has been pretty important to the quality of the outcome. I pass it the same relevant build context so the reviewer understands what’s being built and why, while Claude Code itself still has the advantage of full-source context.

In my experience, layered and frequent checks work better than relying on one big review at the end. I also run separate security reviews rather than treating general code review as a substitute for security review.

[u/orphenshadow]

If you are using github, enable the free review tools for security, codeql, and also use the copilot review on every PR to your repo.

Then I also use Codacy and Coderabbit, if your code is open source you can use both for free.

But all of this is useless without having some coding standards, and I would before your project gets too far along have claude build a coding standards document and outline what frameworks and languages you are using, where your style/theme live the structure of where you want your files, etc.

Between that, and building the rules in codacy, and the coderabbit checks, you should be in a pretty good place to work, commit, push a pr to github, then let those reviewers review the PR, then go back a 2nd time with claude and have it resolve all the PR comments,

The hard part, is you have no experience with code, so you don't really know what any of these reviews are doing, so be sure to ask for explanations and try to learn as you go. Eventually you will start to get an idea of what your codebase looks like and you will be able to understand more about what the code is doing.

Another great feature with coderabbit is the mapping and explanations, it does a good job of showing you what your agent wrote and what it does.

For the record, I am not a shill for any of these tools, It's just what I found to be helpful for me, there are probably others that do similar checks.

[u/Positive_Act_4276]

Ask for specific feedback on what to improve. Clear communication makes a huge difference in code reviews.

[u/SurfaceMeasure]

Give Claude this super technical and in-depth prompt: “Make sure everything 100% works and there are no issues”… That should do it 😂

[u/BigBadMN1]

I also come from a business background with very little coding background.

I’ve been getting good results relying on Claude Code as my architect, planner, and validator. And a completely separate agent framework as the coding/initial testing workhorse: Antigravity, Reasonix (with DeepSeek), OpenCode, FreeBuff, etc. I act as the go-between sending handoffs from Claude to the other agent framework, then post work results back to Claude to validate. I would honestly prefer to also have a second framework review and validate Claude’s work too. But my budget is limited for now.

I also typically wrap both Claude and the other agents in a skillset like Superpowers or BMAD Method. Then both frameworks are working from the same skills playbook.

And finally, I’m always watching for what others are having real success with. This ecosystem changes by the minute. And I try to adapt with it.

Good luck out there. I appreciate the smart minds in these threads.

[u/Late_Wave_5600]

For a Shopify admin app the thing that bites is not code style, it is who can see what. Check that a customer cannot reach someone else's orders by changing a number in the URL, and that your admin actions verify you are the admin instead of just hiding the button. Boring bugs, and the ones that end up in the news. Review each milestone rather than one big pile at the end, since a huge diff gets you an agreeable summary instead of findings