Ask HN: How do you do PR reviews now?

#1

Post by blef » Thu, Aug 06, 2026, 12:02 PM UTC

Hey HN, I need to take step back regarding the PR review process. As everyone is saying AI let's us write way more line of code than before, we have code reviewers that are somewhat relevant, we all know the current state of software engineering.

But... to me PR reviews is still the bottleneck, I still think it's important to have ownership over the code that is merge to main branch, everyone should still have a ownership towards his own code but in order to all progress at the same time towards a codebase that grows faster than ever before how do we do it?

Also how do you not end up mentally dried after reviewing 5 PRs in a day (I'm working on a open-source project which add a bit of complexity as well).

We are trying multiple things: PR author adds comments regarding what should be looked at, labels easy/hard review, PR reviews in pair (author + reviewer).

What are you doing? Do you have a better UI than GitHub or IDEs ones?

Re: Ask HN: How do you do PR reviews now?

#2

Post by nasuy » Thu, Aug 06, 2026, 2:44 PM UTC

we have a same rule for agents and humans, make a onepage html or a short deck with revealjs, not just the diff.

Re: Ask HN: How do you do PR reviews now?

#3

Post by blef » Thu, Aug 06, 2026, 2:54 PM UTC

nasuy wrote: post #2

we have a same rule for agents and humans, make a onepage html or a short deck with revealjs, not just the diff.

but the thing is most of the time it's not about what the feature contains or is the feature working? (we have a live preview env where we can try the feature)

it's more how can we make sure in the thousands of rows/changes that we are reviewing every day we don't have invisible issues while keeping the code standards we expect

Re: Ask HN: How do you do PR reviews now?

#4

Post by manos-saratsis » Fri, Aug 07, 2026, 7:33 AM UTC

Very true. A few things that worked for us:

1. Split review priority by blast radius, not diff size. A 400-line PR touching one isolated module is often faster to review than a 40-line PR touching shared components or a migration. - Push the stuff that doesn't need judgment (naming, obvious edge cases, style) out of human review entirely, so by the time you look at it, you're only spending attention on things that actually need a human. - Try to summarize if what is done is what was intended - Used multiple models to surface common findings instead of starting from scratch - We are also getting dried, that is why we try to have pre-agreggated info before looking at a PR.

btw I build dromeas.ai to solve this pain so quite biased.

Re: Ask HN: How do you do PR reviews now?

#5

Post by akozma89 » Sat, Aug 08, 2026, 2:00 PM UTC

manos-saratsis wrote: post #4

Very true. A few things that worked for us: 1. Split review priority by blast radius, not diff size. A 400-line PR touching one isolated module is often faster to review than a 40-line PR touching shared components or a migration. - Push the stuff that doesn't need judgment (naming, obvious edge cases, style) out of human review entirely, so by the time you look at it, you're only spending attention on things that ac…

[flagged]

Re: Ask HN: How do you do PR reviews now?

#6

Post by nasuy » Sun, Aug 09, 2026, 10:43 AM UTC

blef wrote: post #3

nasuy wrote: post #2

we have a same rule for agents and humans, make a onepage html or a short deck with revealjs, not just the diff.

but the thing is most of the time it's not about what the feature contains or is the feature working? (we have a live preview env where we can try the feature) it's more how can we make sure in the thousands of rows/changes that we are reviewing every day we don't have invisible issues while keeping the code standards we expect

fair, the html only proves the author understood it. tbh i still check every pr myself, just at the report level. a hook generates it, so it does not depend on the author writing well.

what a report cannot show, a separate auditor agent hunts for, with no stake in the pr getting merged.