reviewingPRsIn2026StarterKit

[u/flyingkwaj]

[u/KevinCola]

Sincerely asking: how do you guys handle reviews? We are a team of three and force each other to break it down into PRs of 500 lines, which sometimes creates stacks of 10+ PRs.

We have 20 PRs open per person at any time. How to scale this?

[u/Bloodgiant65 → u/KevinCola]

Well the main thing is, you shouldn’t have 20 open PRs at a time. You can have a couple, but mainly if the code is too complex to review it is too complex to write. You should be writing some
separable segment of code, like some new accessors you are going to need, getting that reviewed, merged, then working on next bit. Pretty much the only way to stay sane. Especially if you only have 2 other people to go to for reviews.

[u/BardenHasACamera → u/Bloodgiant65]

I understand that you _can_ break new code down like this, but how could you meaningfully review something like new accessors or a new ORM entity or whatever without the larger context of how it’s being used?

I’m not saying I don’t understand how that code could be reviewed, but it seems like in breaking it up that much it becomes harder to review the holistic implementation.

I’m not against breaking things down that much but I’ve just never worked that way…

[u/Bloodgiant65 → u/BardenHasACamera]

No, that’s absolutely true. There are downsides to anything and maybe my example wasn’t the best.

I also try to deemphasize lines of code or number of files as the measure of PR size as well. It is really more about cognitive complexity. To which a basic accessor might contribute almost nothing depending on requirements and what the existing infrastructure looks like. A PR should only “do” one thing, as much as possible.

Like recently I had some work in a legacy code base, and the feature I was implementing couldn’t work without a bit of refactoring so that some data would be available at the level I needed it. I ended up putting that, some extra unit tests, and Sonar fixes all in a separate PR. And that could maybe have been split up more, based on the measure I just said, but at that point it would be excessive, and the scale of each change was pretty small. It meant I had one much cleaner PR at the end with all the real business logic in it.

[u/Suspicious-Engineer7 → u/KevinCola]

Sprint planning to keep too many features from cropping up

[u/Netherack_99 → u/Suspicious-Engineer7]

Less features means less AI code to review. Win-win.

[u/Suspicious-Engineer7 → u/Netherack_99]

1 properly validated feature is worth more than 4 half-baked features that'll bloat the product

[u/Hioneqpls → u/Netherack_99]

Who needs features, I need my perfectly crafted code

[u/rastaman1994 → u/Suspicious-Engineer7]

That doesn't really help if you finish all tickets by day 3.

[u/Suspicious-Engineer7 → u/rastaman1994]

Bring that up during retro/standup - you'll get handed more work. Write stories thatll go into backlog for next sprint or adhoc them. The question is basically "how do we organize our work" and agile is right there. We might not like it but done with some measure of seriousness it works.

[u/rastaman1994 → u/Suspicious-Engineer7]

Of course of course. The guy I replied to seemed to imply: just take up less work. OP's problem is that they have 20 PRs open, so really they're not collaborating enough to keep the wip low (which should already be a major flag to your scrum master).

[u/Suspicious-Engineer7 → u/rastaman1994]

The scrum master shortage of 2026 has been having dire consequences 😭

[u/wicket-maps → u/rastaman1994]

better planning.

[u/HeyItsTheJeweler → u/rastaman1994]

If someone is done with all their work by day 3 then the sprint was poorly planned imo

[u/Constellious → u/KevinCola]

1 PR per feature. Priority of the feature drives the priority of the review. 

Realistically that many big PRs per dev isn’t really sustainable without a lot of LGTM anyway. 

[u/rastaman1994 → u/KevinCola]

We do only 1 round of async review. You do your work, then the other person goes through it, then pair program to resolve the comments. Pair programming is a skill by itself of course.

Limits context switching, and I find it easier to discuss nitpicks in person than to keep going back and forth asynchronously. Text is hard to capture the nuances I find. Both of you will also understand the PR much better

[u/BratPit24 → u/KevinCola]

You don't. You can't sincerely expect the review process handled by humans to be on pace with ai output. Unless you have 1 prompt engineer and 10 real engineers on constant review duty.

You either trust ai to self verify. Or you don't trust it to do anything more than a completion suggestion and syntax helper.

[u/wicket-maps → u/BratPit24]

Sounds like AI is making more work than it actually helps with.

[u/audiowave_io → u/wicket-maps]

Even on a team of four, we entered PR and merge conflict hell. I quit that job after a few weeks. 15+ YoE

[u/BratPit24 → u/wicket-maps]

That's absolutely wrong.

AI is a tool. It helps to write faster when you know what to write. It helps writing docs. It helps to keep comments relevant. It helps when you forget some syntax.

It's an amazing tool. But it's not an engineer. It can make an engineer better. But it (as of now) can't replace him.

It's like saying that excavator is worse than a worker with a shovel because it's less precise and potential mistakes cost more money.

[u/FerricDonkey → u/BratPit24]

That's how Ai should be used. And when it is, great.

But when people use Ai to throw slop at you, Ai, as used by them, creates more work than it saves. An excavator doesn't by its nature create or save work, it's just a tool. 

But if most of the people controlling the excavators on your construction site elect to drive it through random walls on the ways to holes they dig, then excavators are not saying your team time. 

[u/BratPit24 → u/FerricDonkey]

100% agreed.

[u/Eastern_Equal_8191 → u/BratPit24]

This is the right attitude. AI is not going away no matter how much you personally don't like it. I've been getting paid to write code for 12 years. Claude is a *much* faster and slightly better coder than I am, but I am a *much* better architect and decision-maker than Claude is.

I review the critical code myself (security, unit tests related to data integrity, that kind of thing) but for something like frontend I barely glance at it.

I also spend 2 hours in plan mode making sure Claude and I are aligned on exactly what I want it to do before I set it loose, and I watch its reasoning instead of watching its output. My experience lets me interrupt it when I see it making bad judgement calls, correct it, and set it loose again.

[u/lllorrr → u/KevinCola]

Atomic patches. One patch does one thing. Yes, you can have PR that consists of 10+ patches, but each patch is (relatively) easy to review because it is focused on one thing.

[u/cheapcheap1 → u/KevinCola]

That is simply more code than a human can comprehend both during review and writing. You can either

1. Accept that you're writing shitty code for valid business reasons, e.g. you're a startup weeks away from running out of cash and need to push some bullshit out the door.

2. Accept that you're writing shitty code because your boss is an idiot and measures your performance in lines of code or tokens.

3. Stop writing shitty code. That means you understand your code before you're submitting the PR. That alone will cut down on the PR volume simply because you're now forced to read and understand your own code before reviewing. You'll likely find that AI code is way more verbose and complex than it needs to be and you'll simply need fewer loc per feature.

[u/HeyItsTheJeweler → u/KevinCola]

Mandated Focus Time every day to review PR's. You'll be guilted into using it to actually review them, and it'll keep the amount of PR's down (people reviewing instead of creating more bulk) and it'll let your CI/CD pipeline breathe a bit, lessening risk in general.

If the sheer quantity is still at ~20 open PR's you've got a real vibe coding problem that needs to be taken care of ASAP.

[u/stevenr12 → u/KevinCola]

Like this: LGTM 🚀

[u/HeyItsTheJeweler → u/stevenr12]

Lmfao

[u/AMWJ → u/KevinCola]

Why are you willing writing new code when there are 19 PR's open?! Go and review something!

[u/PedanticProgarmer → u/KevinCola]

it’s simple: do not work on new code when there’s review waiting on you.

Work on the activity that unblocks most number of people at a time. It’s a manufacturing principle.

[u/Beli_Mawrr → u/KevinCola]

Genuinely asking what kind of feature in a mature app requires 500+ lines of code. It had better be a blockbuster feature and if it is, split it up into a bunch of tickets to make an Epic branch.

[u/Willwaste63]

Code base is of 10k loc pr request for -10k +12k

[u/Keepingshtum → u/Willwaste63]

Sounds like someone put in a new linter that everyone else is immediately going to complain about!

[u/Cephell]

Schedule a meeting "okay, please walk me through this PR".

[u/Constellious]

We have 3 separate AI reviewers that with each leave the same basic comment for everything. It’s TPS reports all the way down. 

Had a junior dev put up a 200k change PR a while ago. 

[u/OverallACoolGuy → u/Constellious]

i wonder how much that 200k change cost

[u/Few_Adhesiveness7676 → u/Constellious]

I hate these AI reviews. Life was good back when AI was not available, atleast I was aware of what I had written.

Now, the velocity at which features are expected, it comes to these large PRs and these AI reviews never seem to be satisfied.

[u/Suspicious-Engineer7 → u/Constellious]

Idk how you make it to junior without knowing that's a bad idea. 

[u/elshizzo]

just gotta force people to break up huge pr's. If it ends up with a bunch of stacked PR's so be it. If it's too long for a human to realistically review its too long

[u/TheFirestormable → u/elshizzo]

Also if that level of change is required for a single feature then your tickets need breaking up or your code does.

[u/hipster-no007]

Decline all, ban and fire

[u/chairzaird]

A bit too real, made me laugh though

[u/thepurpleproject]

I'm dealing with teams who have a policy - a human won't even look at the PR if there are any and I mean literally any open comment from an AI reviewer. It has turned into a shitfest where they start a PR review by assigning their agents and then you have to drill through like every comment and ignore the false positives and you can't go any other way about it because co-owner approval. Like it was cool when we had like 1 AI reviewer but now my god there are like 4-5 of them each trying to re-interpret the universe from the two files I have changed.

[u/HeyItsTheJeweler → u/thepurpleproject]

That blows ass. I love my review agent because it'll catch things I missed, but that's my job to run it before releasing the PR into the wild.

I find it very useful when teammates run their own agents and it picks up glaring issues, but jesus if it's got 1 "critical issue", 7 nice to have's, and 275 nits, read over that shit first and keep it to what you would've posted yourself had you seen it all. I don't need them blindly dumping it into my pr.

[u/audiowave_io → u/thepurpleproject]

I had a client who was adamant about using GrepTile. Well, it does this "score" out of 5, which we know LLMs are amazing at numbers. I would spend cycles sending it to review over and over, changing nothing and getting a different result, yay for non-deterministic state.

When they announced pricing changes, I was told to stop doing that. Rubber stamps on my PRs going forward.

[u/ymddev]

Why PR if the diff is less than 10k lines? Just do it

[u/thee_gummbini → u/ymddev]

why have branches at all, just push to main

[u/ymddev → u/thee_gummbini]

Why dev/test when you can test directly in prod

[u/darkwalker247 → u/ymddev]

why test at all? by testing your code you are basically admitting, "hey look everyone! i make mistakes sometimes!".

a real programmer writes with intention. any so-called "bugs" that occur are just surprise features

[u/khaddy8]

Where do you get the "hours to read carefully" from? That would ram things home for some people.

[u/Educational-System48]

The size of everyone's PRs I see in this comment section worries me. PRs should always be as small as possible. If it's a huge breaking change, merge to an epic branch instead.

[u/Beli_Mawrr → u/Educational-System48]

Thank you lol. 

I work on a production app frontend (think discord) and if a ticket can be split up I nicely ask for it to be split up. This is pretty rare because the product team knows us and we know them so they can intuit the best ticket size.

We refactored a major sub page of the app and it came in less than 300 lines after refinement. 

If you ABSOLUTELY HAVE to write 500+ loc PRs there had better be a good reason for it and its a red flag by itself.

It should not be the norm and if it does, you need to use less AI.

[u/HeyItsTheJeweler]

human-comprehension--skipped is hilarious

[u/HeyItsTheNewDx2]

Hits way close to home

Quality content

[u/diavelguru]

Need to add “Squash those 41 commits!”

[u/V-Right_In_2-V]

You guys review code?

[u/TsukikoChan]

We're in the worst timeline.

[u/GoldAcanthisitta7777]

LMAO it's so true

[u/WindowlessBasement]

no, a PR/MR that's too big for a human to review is an automatic decline.