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

10 points by meteor333 52 days ago | 15 comments

We are facing flooding and surge in PRs across the teams. AI reviewer tools are good, but not exactly helping in efficiency. Almost all developers are experiencing velocity gains in programming but it's not resulting into eventual productivity or velocity in roadmap. How are you or your org dealing with all this?

antoineMoPa 52 days ago |

Skipping most reviews and waiting for disasters to happen.

sinansaka 51 days ago |

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.

niros_valtos 50 days ago |

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.

meteor333 49 days ago | |

Do you mind sharing how you implanted the trivial checks? Did you spin up your own agent? Also how are determining what is trivial or not?

This is the clearest actionable thing I’ve heard of so far, so it would be good to understand the specifics

ZivenChang 52 days ago |

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.

meteor333 52 days ago | |

What are the strategies your team is doing to cope with it?

k8s-1 51 days ago |

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.

tacostakohashi 52 days ago |

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

meteor333 52 days ago | |

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

sdevonoes 52 days ago |

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

meteor333 52 days ago | |

Can you expand on what strategy did you use? How are you deciding what to ignore?

clemente0620 48 days ago |

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

nulledy 51 days ago |

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.

cloche 50 days ago |

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.

meteor333 49 days ago | |

This is a great take! I agree with the framework on this. I’d love to hear from someone who has implemented this at their org to get learnings so far