All posts

Most Pull Requests Are Already Fixed Before a Human Opens Them

In July we reviewed 322 pull requests. Developers fixed 96% of the issues they engaged with, usually within minutes of opening the PR. By the time a reviewer looked, there was nothing left to catch.

Uri Gonfaus
A pull request timeline split into two zones, before senior reviews and when senior reviews, with Revix flagging an issue and the developer fixing it in the first zone and only approval and merge in the second

A reviewer opening a pull request is usually the last person to see it. By then the code has been sitting there a day or two and the author has moved on to something else.

In July we reviewed 322 pull requests. Most of that waiting turns out to be avoidable, because the fixing does not have to wait for the reviewer.

The loop runs in minutes, not days

Revix reviews a pull request the moment it opens and posts findings on the exact lines, typically two or three minutes after the author pushed. The author is still in the file. They have not context switched, and they do not need to rebuild the change in their head to understand the comment.

So they fix it, right there, before anyone else has looked.

Developers fix things when the feedback is fresh

of engaged issues were fixed
96%
dismissals across the whole month
2
of reviewed PRs came back completely clean
1/3+

When a developer engaged with something we flagged, they fixed it 96% of the time. Two dismissals in a month across 322 pull requests.

That surprised us. The usual assumption is that developers resent automated review comments and argue with them. They argue with comments that arrive three days late about code they have stopped thinking about. Given a specific finding on a specific line while the change is still open in their editor, they fix it and move on.

More than a third of the pull requests came back clean with nothing to say at all. A reviewer that invents something to say is worse than silence, which is why precision matters more than coverage. We went into that in what 200 pull requests taught us.

What this changes for the reviewer

The reviewer's job stops being a search.

Most of what gets caught in review is not architecture. It is an endpoint missing the permission check every sibling endpoint performs, a role test that passes for the wrong reason, a retry loop with no backoff. Authentication and permissions was our biggest category in July. Finding those means reading the diff line by line with the surrounding module in your head, and it is the first thing to go when someone is reviewing between two meetings.

When that class of issue is already fixed, approval becomes a judgment call about whether the change is the right change, which is the part a human is better at.

The third-ranked repository is one we review ourselves

Across every repository on the platform, the third-highest count of issues found belongs to a client codebase our own team reviews.

We are the reviewers there, not the authors, and the issues still show up in volume. Careful human review does not make them stop happening. It decides how early they surface.

If you want to see what your own loop looks like, connect a repository at revix.ai. Every team starts with a 14 day free trial, no card required.