Ask HN: How is your org managing PR review load as AI multiplies code output?
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?
AI didn’t remove the bottleneck, it just moved it from writing code to reviewing, validating, integrating, and deciding what actually deserves to ship.
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?".
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?".