HN Explorer

Ask HN: How do you do PR reviews now?

3 points by blef ↗ HN
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?

3 comments

[ 0.30 ms ] story [ 5.7 ms ] thread
nasuy
we have a same rule for agents and humans, make a onepage html or a short deck with revealjs, not just the diff.
manos-saratsis
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.