Getting Claude to review my code before opening a PR. Does it actually cut down on review comments?
Before opening a PR, I started pasting my code into Claude for a quick review first, just to catch anything obvious before it goes to the lead.
A few times it caught things clearly worth fixing: a missed null case, a variable name that didn't match the rest of the file's convention, a catch block that swallowed the error without logging it. Stuff that, if the lead caught it instead, would've meant another round of comment - fix - push.
But there were also times it gave generic "best practice" suggestions that didn't fit our team's actual conventions, so I had to filter through what to actually apply versus ignore.
Not always a time-saver either, for small PRs, the lead's review still came back basically unchanged after I'd already run it through Claude, so that step felt redundant. The benefit was clearer on PRs with more complex logic.
Anyone else doing something similar, like running code through AI before a real human reviews it? Does it actually reduce back-and-forth rounds, or just catch small stuff here and there?
Replies
i think the biggest value is not replacing the reviewer but making sure the PR is cleaner before it reaches them.
@_tallha_ijaz Yeah, agreed. Though "cleaner" ends up meaning different things depending on the PR. For small ones it barely moves the needle. For bigger ones it's caught stuff that would've taken the lead two review rounds to spot.
I've noticed AI is better at catching obvious issues than understanding team specific decisions. the context part is still hard.
@akhilesh35602 This is the part that lines up with my experience the most. It's confident about "best practice" even when that practice doesn't apply to how our team actually works, so I end up spending time filtering its suggestions instead of just applying them.
I use AI reviews mostly for a second pair of eyes. sometimes it catches something i completely missed even aftr reading my own code.
@haider_murtaza3 That tracks. The value isn't that it's smarter than me, it's that it hasn't been staring at the same code for an hour, so it notices things I've gone blind to.
The lint-style catches are the ones that save the least, since a linter already flags those. The times it's actually saved a round trip with the lead were cross-file: a function renamed in one place but not everywhere it's called, which needs the whole diff in view at once to notice, not just the file you're staring at.
@abdullah_javaid3 This adds a layer I hadn't thought about. The null-check / naming-convention type catches are still useful as a first filter, but you're right that those overlap a lot with what a linter already does. The cross-file case is a good example of something that genuinely needs "seeing the whole diff at once". That's a different kind of value than just flagging obvious stuff.
@kailong_20 The one that gets me most is a shared value getting duplicated during a refactor, like a theme constant that moves to a new file but the old import still technically resolves because the symbol exists in both places. Nothing errors, nothing warns, it just quietly stops being the value you think it is. Same "need the whole picture" bucket as the renamed function, just a step subtler.
@abdullah_javaid3 The cross-file point is the one that matters most, especially in security reviews. A new endpoint gets added that mirrors an existing one, but the auth middleware or permission check from the original doesn't get copied over. Nothing in that single file looks wrong on its own, it only shows up once you compare it against the route it was modeled on.
The swallowed error catch block from the original post is the same category of miss. A failed auth attempt, a rejected input, a permission check that fired and got caught instead of logged, all of that goes quiet instead of showing up anywhere useful. Small to look at, but that's usually the difference between catching something in review and finding it during an incident.
@adammcclarintx The auth middleware example is a sharper version of the same bug. Mine just loses a value quietly, yours loses a permission check quietly, and the second one is the one that actually gets someone in trouble.
@abdullah_javaid3 This is a good distinction I hadn't thought about. The null-check stuff overlaps a lot with what a linter already catches. The cross-file case is a genuinely different kind of value, seeing the whole diff at once instead of just one file at a time.
Smaller pull requests probably do not benefit much from an extra AI review, but complex changes seem like a different story. Using it as a first pass instead of a final authority feels like the right balance.
@eriberto_puppypound This matches exactly what I saw - small PRs, the lead's review came back basically the same either way. Complex logic is where the extra pass actually pays off.
Oscar Chat
AI code review is like asking a very confident junior developer to check your work: great at spotting missed null cases, but occasionally determined to refactor the entire architecture because it read a blog post 😄 Useful as an extra lint layer, not a replacement for the lead.
@kseniia_shevchenko2 Haha, the "confident junior" bit is spot on. Though someone below made a good point. Dtuff like null checks is basically linter territory anyway. The real "wow it caught that" moments for me were less about individual best-practices and more about spotting something a linter physically can't, like a variable that got renamed in one place but not another.
@kseniia_shevchenko2 Someone else below made a good point too that the null check stuff is basically linter territory anyway. The real value I've seen is less about individual best practices and more about spotting things a linter physically can't, like a rename that didn't make it everywhere it needed to go.
Tried something similar a few months back. The biggest shift for me was treating it less like a reviewer and more like a pre-flight checklist, you're not looking for architectural feedback, you're just trying to make sure you didn't leave the landing gear up before handing it to someone whose time is expensive.
The generic best-practice noise is real though. I got around it by adding a few lines of context upfront, like "we don't use X pattern, ignore suggestions about Y" and it filters down a lot faster after that.