Pull Requests Are Corporate Theater — Here's Why

Pull requests were supposed to save software engineering. Instead, they became corporate theater.

You spend 45 minutes writing code. Then you spend 3 days waiting for someone to approve it. The reviewer glances at 500 lines, writes "looks good to me," and merges. Nobody learned anything. Nothing improved. But hey, process followed.

The Numbers Don't Lie

Studies show that 70% of code reviews take less than 5 minutes. For a 500-line PR, that's roughly 0.6 seconds per line. You can't read a line of code in 0.6 seconds. You can't even see a line of code in 0.6 seconds.

What reviewers actually do:

• Skim the file names
• Check if CI passes
• Look for their friends' comments
• Approve

That's not review. That's a rubber stamp with extra steps.

The Real Purpose of PRs

PRs aren't about quality. They never were. They're about:

1. Accountability theater — "We reviewed it" means "someone else approved it" means "it's not my fault"
2. Knowledge silos — The person who wrote the code knows it best. The reviewer knows nothing. Why would the person who knows less approve the work of the person who knows more?
3. Meeting quotas — Engineers need "collaboration metrics." PRs are the easiest way to generate them.

What Actually Works

If you want better code, try these instead:

• Pair programming — Two people, one screen, real-time feedback. No waiting.
• Mob programming — Whole team, one codebase, shared ownership.
• Automated review — Linters, formatters, type checkers. Machines are better at style than humans.
• Ship and monitor — Deploy fast, monitor closely, fix quickly. The best review is production monitoring.

The Uncomfortable Truth

If your team can't ship code without a human approving it first, you have a trust problem, not a process problem.

The best engineers I know don't need someone to tell them their code is good. They know it's good because they wrote it well, tested it thoroughly, and deployed it carefully.

PRs are security blankets for managers who don't understand what their engineers do.

---

This article is based on a video from ERR.SYS — daily tech rage for developers who know something is wrong.

Do not subscribe. I don't need your metrics to know your stack is sinking.