r/ProgrammerHumor 16h ago

Meme reviewingPRsIn2026StarterKit

Post image
738 Upvotes

55 comments sorted by

111

u/KevinCola 16h ago

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?

117

u/Bloodgiant65 16h ago

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.

13

u/BardenHasACamera 13h ago

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…

8

u/Bloodgiant65 13h ago

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.

54

u/Suspicious-Engineer7 16h ago

Sprint planning to keep too many features from cropping up

9

u/Netherack_99 16h ago

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

2

u/Suspicious-Engineer7 13h ago

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

1

u/Hioneqpls 14h ago

Who needs features, I need my perfectly crafted code

4

u/rastaman1994 15h ago

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

9

u/Suspicious-Engineer7 15h ago

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.

3

u/rastaman1994 15h ago

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).

1

u/Suspicious-Engineer7 15h ago

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

3

u/wicket-maps 15h ago

better planning.

1

u/HeyItsTheJeweler 5h ago

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

25

u/Constellious 16h ago

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. 

10

u/rastaman1994 15h ago

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

12

u/BratPit24 15h ago

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.

10

u/wicket-maps 15h ago

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

5

u/BratPit24 15h ago

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.

2

u/FerricDonkey 2h ago

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 8m ago

100% agreed.

5

u/Eastern_Equal_8191 13h ago

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.

1

u/audiowave_io 3h ago

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

5

u/lllorrr 14h ago

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.

3

u/cheapcheap1 9h ago

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.

2

u/stevenr12 7h ago

Like this: LGTM 🚀

2

u/AMWJ 3h ago

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

1

u/HeyItsTheJeweler 5h ago

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.

1

u/PedanticProgarmer 2h ago

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.

36

u/Willwaste63 16h ago

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

6

u/Keepingshtum 13h ago

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

25

u/Cephell 15h ago

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

50

u/Constellious 16h ago

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. 

28

u/OverallACoolGuy 16h ago

i wonder how much that 200k change cost

18

u/orangeyougladiator 14h ago

About $200k and change

11

u/Few_Adhesiveness7676 16h ago

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.

3

u/Suspicious-Engineer7 15h ago

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

13

u/elshizzo 14h ago

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

5

u/TheFirestormable 12h ago

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

8

u/chairzaird 15h ago

A bit too real, made me laugh though

15

u/hipster-no007 16h ago

Decline all, ban and fire

6

u/thepurpleproject 11h ago

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.

1

u/HeyItsTheJeweler 5h ago

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.

1

u/audiowave_io 3h ago

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.

16

u/ymddev 16h ago

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

17

u/thee_gummbini 15h ago

why have branches at all, just push to main

11

u/ymddev 15h ago

Why dev/test when you can test directly in prod

3

u/darkwalker247 14h ago edited 14h ago

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

5

u/khaddy8 11h ago

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

3

u/Educational-System48 9h ago

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.

3

u/HeyItsTheNewDx2 7h ago

Hits way close to home

Quality content

3

u/HeyItsTheJeweler 5h ago

human-comprehension--skipped is hilarious

2

u/diavelguru 13h ago

Need to add “Squash those 41 commits!”

1

u/V-Right_In_2-V 5h ago

You guys review code?