Ask HN: How is your org managing PR review load as AI multiplies code output?

I have a few strategies - which are all based on reciprocation.

If the code is reasonable and diligently created, be it with AI or not, I will provide a diligent and timely review.

If the code is totally unreadable AI slop that does not appear to have been read by the person who created the PR, I will use AI to review the code and share the output, without reading it.

If the code is of middling quality, I will find one or two token areas that could use improvement, and suggest a better alternative like "How about doing this with 2 syscalls instead of 4?" or "How about refactoring this duplicated code into a method, and calling the method?", or whatever. If the person responds intelligently, I will proceed to review the rest of the code and work together. If the person responds by sharing their AI's justification, I will politely disengage.

Occasionally, I will share remarks like "I'm noticing a lot of churn here - if this is a bugfix/patch for a prod issue, I'd expect to see a PR with the smallest delta that fixes the problem" or "I'm not clear on whether this approach is optimized for runtime efficiency, maintainability, resilience, or something else - could you share the outcome you're looking to achieve with this change?".

Thanks for sharing. It’s smart to filter or prioritize it diligently or sometimes even turn it away

[flagged]

My take is that PR reviews are primarily for knowledge sharing. If reviews are slow, plan a face-to-face / video meeting / demo for it. Comment in the PR what the code change is for. Keep changes focused and small. This is about respecting other people's time.

[flagged]