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

We hit this too, and what helped wasn't more reviewers. We pushed the trivial checks (style, obvious bugs, secret and other deterministic scanning) onto automation so humans only look at intent and design, and the trap to avoid is letting AI both write and "review" the code, since you want the review signal independent of what generated it. There is another way we are experimenting these days too - building a gauge of how much a human in the loop is needed based on our confidence on the changes AI analyzes.

We’re seeing much higher PR volume from AI-generated code, but review time hasn’t improved, so PR review has become the main bottleneck instead of coding.

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?".

Cut by half AI usage. Works wonders. Focus on the good stuff, ignore the rest

I think we'll need to evolve code review. Rather than simple rules like every review must have 1 or 2 approvals, we should be moving towards dynamic rules for when a human needs to be in the loop. For example, an agent can output a risk score for how risky the change is. Teams can then configure to auto approve PRs for the risk level they are comfortable with. Any risk level above that goes to a human reviewer. The advantage with this system is that it will help avoid massive vibe-coded PRs. If devs want to get their PRs deployed quickly, it will encourage a positive feedback loop of good engineering practices like keeping changes small and focused - that doesn't go away in an AI world.

Perhaps a summary is sent out to the team at the end of the day for all auto-approved PRs so that developers can review them quickly to stay up to date on the codebase.

AFAIK Github doesn't support anything like this today (maybe through actions?) so your company may need to use a tool that evolves in this way.

Skipping most reviews and waiting for disasters to happen.

Code reviews dont scale, inherently bottlenecked by how fast you can read code + cognitive capacity. But there are ways to make it easy to make sure PRs dont break prod and keep the quality stable: linters with best practices + company specific coding guidelines, dev environments per PR, comprehensive e2e tests that verify both correctness and performance. Not so easy to setup, but benefits are worth it.

Im working on karinja.ai which I lets teammates share live agent sessions backed by cloud sandboxes, that way you can centralized your agent config within a team so that the output is consistent and results can be previewed without even leaving your browser.

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.

AI first handles most MR reviews, scores them by quality, content and impact, then decides whether manual review is needed.

The engineer that wrote the prompt owns the review and the resulting code. If it breaks because they missed something in code review, it's on them.