- I review once the code is functionally doing what I am looking for.
- I try to keep the features small so that the code is manageable.
- After manually reviewing, I ask it to review the code. Assuming you have coding standards well defined, you will find that it may not follow those standards during development so having an isolated review step seems to provide better results.
(using claude code) I force the agent to work in steps where each step changes no more than 4-5 files, where each step has some observable result, ideally unit testable or e2e integration testable, and do a quick git diff/git add after each step. I have a bunch of deterministic checks (custom linting rules) that verify pretty much any repeatable comment I had to provide to Claude code over time (Claude is also writing/maintaining the rules, and unit tests for the rules) so I can focus on identifying new stuff. It took a few months to grow this rule set but now it exists things work pretty smoothly.
One practical layer we've seen work: run parallel security scanning + an auto-fix pass on the AI-generated diff before review, so reviewers spend time on logic instead of CVEs.
5 comments
[ 5.6 ms ] story [ 28.2 ms ] thread1. Explain the goal.
2. Tell it the constraints (readable, simple, don't overengineer).
3. Give it our repo structure and coding conventions.
4. Let another model review it.
5. Group the feedback by category instead of one long list.
It's easier to work through the review that way.
- I try to keep the features small so that the code is manageable.
- After manually reviewing, I ask it to review the code. Assuming you have coding standards well defined, you will find that it may not follow those standards during development so having an isolated review step seems to provide better results.