I once approved a PR without reading it. Not because I was lazy — because the description was blank, the title was "fix", and the diff had six hundred lines across eleven files with no explanation of what any of it did. I ran out of patience somewhere around file four and clicked Approve. Three days later, it took down the checkout flow in production.
That PR had a reviewer. It had an approval. It had zero useful review.
The Pull Request as a concept is sound: before code reaches main, another human looks at it. The breakdown happens when the PR is written as if review is a bureaucratic gate to get past, instead of a conversation worth having. Getting that distinction right changes everything — how fast your PRs get reviewed, how much friction the process creates, and whether code review makes your team better or just slower.
What a Pull Request is
A Pull Request (PR) — or Merge Request if you're on GitLab — is a formal request to integrate the changes from one branch into another. That's the technical side. The human side is where a team looks at code together before it goes anywhere near production.
