In almost every engineering organization, when you want to make a change to the code, you make a "Pull Request", or PR.
Typically your PR is looked at, or "reviewed" by at least one other engineer on the team. The reviewer often leaves feedback or requests changes. You address them and re-request a review. Finally, your code is either approved or rejected, your PR is either "merged" or "closed".
This is done every day, dozens if not hundreds of times a day, by every member of the team. It's like some strange mating ritual that you have to perform to get your code into the product.
How on earth did we ever accept this bunk?
A brief history of Pull Requests
Before Git, version control was centralized. CVS and Subversion had a simple model: you check out code, make changes, and commit directly to the repository. There was no "pull request" because there was no need for one. You either had write access or you didn't.
Then Linus Torvalds created Git in 2005 to manage the Linux kernel. Git was distributed by design. Every developer had a full copy of the repository. The workflow was simple: patch files sent via email. Maintainers would review patches, apply them, and push to the canonical repository.
GitHub launched in 2008 and changed everything. They introduced the "Pull Request" as a way to formalize the email-patch workflow. It was a social layer on top of Git. You fork a repository, make changes, and open a PR to propose merging your fork back into the original.
This made sense for open source. Random strangers contributing to your project should have their changes reviewed. You don't know them. You don't trust them. The PR is a gate.
But then something strange happened. Companies started using GitHub for private repositories. And they cargo-culted the entire PR workflow along with it.
Why every engineering team still uses them
"Code Review"
The most common justification is quality. We need code review to catch bugs, enforce standards, share knowledge.
In practice, most code reviews are rubber stamps. The reviewer glances at the diff, maybe leaves a nitpick about formatting, and clicks approve. Real bugs slip through all the time. The ones that get caught are usually obvious enough that the author would have found them with a second look.
Types of comments found in code reviews
Better yet, just use an agent. If the goal is actually quality, tools like OpenCode's /review are already better at this than we are. Agents don't get bored, don't have egos, and actually trace the logic instead of just nitpicking your variable names. If a reasoning model can't find a flaw in your diff, your distracted teammate definitely won't.
The CI/CD industrial complex
Pull requests have become the centerpiece of an entire ecosystem. GitHub Actions, CircleCI, automated testing, linting, security scanning. All of it triggered by PRs. The tooling assumes PRs exist.
It's a self-reinforcing loop, and a lucrative one. The CI/CD tools market is worth over $5 billion and growing at nearly 20% a year. Just recently, GitHub tried to charge people for using their own runners on CI, only to backtrack after the backlash. With so much money on the line, is it really surprising to see oodles of money thrown at marketing this workflow?
Influence hoarding
Pull Requests feed into one of the most uncomfortable truths about the industry: some engineers like being gatekeepers.
Having to approve code gives them power. They can block changes they don't like, slow down people they disagree with, or simply make themselves seem important by being a bottleneck.
This behavior is almost never premeditated; it's just a nerd-reflex that's hard to spot in ourselves. And who can blame us when the first thing someone asks when a bug gets shipped is, "who reviewed this?".
Ramping up
I hate to admit it, but PRs are useful when someone is new. It can take people a little while to vibe with the coding standards, especially if they come with the Gitflow brainrot from years in a FANG. But this doesn't justify making everyone go through the same process forever.
Once a new team member ships a feature, shouldn't the expectation be the handholding comes to an end?
Why it's all a scam
Every engineer who likes to stay employed will tell you we need pull requests to avoid bugs. Shipping bug-free code just isn't possible without them, so they say.
But this is demonstrably false. There is little to no correlation between the number of PRs, review cycles, or reviewers and the number of bugs that make it to production.
Let that sink in. Code review sucks at catching bugs.
But it's essential to maintain a high quality bar! Again, bunk.
Does the chef taste every single dish that leaves his kitchen? Does the captain of a ship have to OK every order his officers make? Does a quarterback ask the coach before making a throw if it's a good target?
No. It's absurd. Nothing in life that moves fast works this way. PRs for every change make about as much sense as a surgeon asking for approval before each incision. PRs are the antithesis of "bias for action".
So what instead?
Ship to production. Monitor it. Fix it fast. Trust your engineers or don't hire them.
Pair programming catches more bugs than async review ever will. Feature flags let you ship without fear. Good observability tells you when something breaks.
The best teams don't wait for approval. They ship and take responsibility. They move fast because they can.
Pull requests started with good intentions. But they've become a bureaucratic ritual that slows everyone down while providing the illusion of safety.
Pull requests are simply "not it".