Keeping PRs small won't solve your code review bottleneck

Posted by StableStack@reddit | ExperiencedDevs | View on Reddit | 5 comments

The vast majority of engineering teams seem to be struggling with how to handle code reviews. And a big issue is the size and volume of PRs, you know the drill :-)

And there is one thing that is often mentioned as THE solution: "we keep our PR small so that humans can review them".

We've tried that; it does not work:

Asking dev/agents to split PR into smaller ones adds more work
Developers end up having to review changes across multiple PRs to get the full picture
Small PR was good for human scale, we are past that

Here is what has been working for us

Change PR requirements

Require the following as part of a checklist:

The Why and What: MUST be written by humans.
Rollback/Revert plan: detailed exactly what to do, including data fixes
Access-controlled verified: no amount of automated checks will catch that
Expectation logged with context: so that it can be easily investigated
Set up a triage bot that assesses risk

Have the bot assess complexity and impact to categorize the PR. We have 3 categories: low, medium, and high.

To illustrate the point:

risk:lowA PR behind a feature flag, with no migration, no shared contract changes, shipping to internal users first.
risk:highA PR that alters a database index on a table with 50 million rows?

Based on this risk, the PR receives varying levels of human attention.

Optimize for rollout

Have everything behind a feature flag and instrument your code. When deploying, enable for the team first, then a handful of customers, then 10%, then everyone. If anything fishy appears in your observability, roll back.

For us, the summary was that the size of the diff stopped being a useful signal. The blast radius is.

Curious to see if others are using similar or different methodlogies?

[-]

soggycheesestickjoos@reddit

Asking devs to split PR into smaller ones adds more work

That’s probably the main problem, don’t split a completed task into smaller PRs, split larger tasks into smaller ones before working on them.

from the article “AI agents don’t work that way. They think in features”

No, they think how you tell them to, work with them to create maintainable tasks instead of tackling entire features.

vzq@reddit

Sounds like bollocks to me. All modern agent frameworks are happy to give you focussed PRs that address a single change.

I'm guessing the real problem is that the codebase (whether though human or agent action) has developed in a way that leads to massive change amplification. Where to change one thing, you need to change lots of things. That's a killer right there, because then trivial changes lead to huge PRs that you can't meaningfully split up.

spez_eats_nazi_ass@reddit

“vast majority” show me your sample size and study methodology in making that statement or get fucked. Have never experienced this.

positev@reddit

So your teams are heavily utilizing AI and able to keep up with reviews such that changes are properly vetted before integrating? Can you elaborate on your process?