Confession first. My most useful reviews of the last year have all happened in a shared doc, an ADR draft or a twenty-minute call, before anyone wrote a line of the change. The pull requests that followed were mostly paperwork. So when The New Stack published "Move code review before the code" on July 19, framing the pull request as roughly twenty years old and arguing review should move upstream of the code itself, I sat with the headline for a while. It matched what the good weeks already look like on my team.
Where PR review starts to feel late
The pull request has been the CI/CD review venue for so long that the entire pipeline is shaped around it. Draft, push, wait for CI to turn green, request review, negotiate, squash, merge. It has been fine. It has also been the point where I have watched teams argue about names, module boundaries and library choices that were locked in ten hours earlier, when someone ran git add. By the time a diff is on screen, the shape of the answer is already sunk cost. That is the part that stings, and it stings whether the reviewer is a human or a bot.
You will feel this most on the changes that actually hurt: the refactor that touches everything, the migration that has one right answer and three seductive wrong ones, the "small" schema tweak. The comment that would have mattered is the one a reviewer would have made before any typing began, asking what problem you are actually solving and whether this is the smallest thing that solves it. Once the diff exists, that question feels rude. Once you are three days deep, it feels hostile.
What "upstream" actually looks like in a team
The New Stack's argument is that review should move upstream. In practice that is less exotic than it sounds. An RFC or ADR document that describes the change before the branch exists. A short design note pinned to the issue. A twenty-minute walk-through on a call, with notes captured after. A comment on a proposal in the tracker, weeks before the PR. All of it is asynchronous or nearly so. All of it lives in text you can grep later. None of it is new.
What would be new is the willingness to treat the design step as the primary review step and the PR as the sanity check. That change asks less of a CI/CD workflow than the average pipeline tool already asks. A shared doc costs nothing. Blocking a PR on "did we discuss this first?" costs a checkbox. The hard part is cultural. People who spent years polishing their PR etiquette do not love being told the review they optimised for is the wrong venue.
Where the pull request still earns its keep
I am not ready to throw the PR out, and I do not think the argument is that anyone should. Small changes, dependency bumps, obvious refactors, a config tweak with a test attached: the PR is a fine review venue for those, and the design-doc overhead is not worth it. The trap on the upstream side is real too. I have watched a beautiful ADR sail through review and then meet the compiler and lose. Design review that never touches code drifts into fiction. The good version is both: cheap upstream review that catches the shape of the change, then a fast PR review that catches the reality of it.
If a bot reviewer is going to sit somewhere in this loop, I would rather it read my design doc than my diff. That is the honest end state of the argument, and it is the one I would like to try on a small team next quarter.
What I am watching next
Two things. First, whether the platforms that own the PR flow start to treat the design document as a first-class artefact linked from the change, instead of a URL buried in the description that everyone opens once. Second, whether the AI code-review tools evolve to read intent before diffs, since right now most of them reinforce the "review the code, argue about the design later" habit the piece is critiquing. Both are quiet product decisions. Both would move the day of an engineer waiting on review from tense to calmer, and after twenty years of the pull request, calmer sounds pretty good.
Top comments (0)