Merge Requests Are a Cargo Cult
It’s Time to Stop Pretending They Improve Quality
I specialize in developing object-oriented java applications that aligns with business objectives, using Domain-Driven Design principles to ensure technical decisions drive tangible value. By focussing on a deep understanding of the business domain, I craft solutions that solve real problems while maximizing ROI. My approach evaluates the cost/profit ratio of every decision—only implementing technologies when the benefits outweigh the costs. I’ve been called in to revive stalled projects and address challenges where others have struggled. My focus is on creating software that not only meets but exceeds business expectations. Whether working with legacy systems or modern frameworks, I select the right technologies to maximize value—not just follow trends. I believe software should be a strategic asset, and this mindset guides every decision I make in development.
Open any job ad, any process document, any “engineering ladder” today and you will find the same holy words:
“Strong code-review culture”
“PRs must have at least two approvals”
“100% reviewed code before merge”
We have normalised Merge Requests (PRs/MRs) so completely that most teams literally cannot imagine shipping production code without them.
They are treated as the ultimate quality gate, the place where knowledge spreads, where bad code dies, where junior devs level up, and where risk is contained.
They are none of those things.
In almost every normal product team they are an expensive, velocity-killing, quality-reducing anti-pattern — and the evidence is hiding in plain sight in every stand-up you have ever attended.
Here is the unvarnished truth.
1. The merge itself creates new, never-before-executed software
Your branch passed all tests.
Main passed all tests.
The result after git merge is a third program that has literally never run on any computer anywhere.
That is when the surprise outage is born — Friday 17:42, two hours after the “clean” merge, when the new code path meets the old path for the first time in production.
No amount of “LGTM” changes physics.
2. MR workflows are the opposite of Continuous Integration
Continuous Integration (the real 1999 XP definition) = integrate and fully verify the whole system many times per day so the delta is trivial.
Typical MR workflow:
branch lives 4 hours to 4 days
sits in review queue for another 4–48 hours
gets merged in a 600-line batch on Friday afternoon
That is batch-and-queue deferred integration — the very thing CI was invented to kill.
3. MR reviews are not design reviews (and never will be)
A real design review needs:
shared context
hours of immersion
whiteboarding alternatives
psychological safety to say “this whole approach is wrong”
An MR gives the reviewer:
a wall of diff
7–40 minutes
none of the context the author built up over two days
Therefore the only feedback possible is shallow: formatting, null checks, naming, tiny refactor suggestions.
Everything important (aggregate boundaries, invariant placement, future evolution, performance characteristics) stays unreviewed — not because it’s good, but because nobody has the context to challenge it.
4. MRs turn developers into isolated islands
Good design is a contact sport.
It happens live: pairing, mobbing, overhearing half a conversation and jumping in, pulling the product owner into a discussion.
MR culture enforces the opposite:
Disappear for two days
Come back with a “finished” artefact
Hope someone is willing to tell you it sucks
By the time the MR is opened, the design is socially frozen. Collaboration is dead.
Result: ten slightly different ways of doing the same thing, micro-architectures everywhere, drift nobody sees until the rewrite.
5. The illusion of safety is the worst part
Once someone clicks Approve, responsibility magically evaporates.
The author feels safer
The reviewer feels they “did due diligence”
Management gets a nice “98% reviewed” metric
We built a theatre of safety, not actual safety.
6. What a healthy flow actually looks like — a normal Thursday on a team that dropped mandatory MRs two years ago
09:15 – Stand-up (still exists, still 12 minutes).
Anna: “Today I’m tackling the overdue-fine change for customers that bill daily instead of weekly.”
09:20 – She pings the two people who know the billing corner best: “Got 10 minutes to think with me?”
They screenshare, inspect the Fine calculation code, and agree the cleanest place for the new rule is inside the Fine constructor itself.
09:35 – Anna pulls latest main, writes ~60 lines, runs the full app locally, clicks through every overdue scenario she can think of.
Everything feels right.
09:52 – She commits straight to main. No branch, no MR.
CI runs on the actual merged code, finishes green at 10:06.
12:47 – Dogfooding on staging.
Anna notices daily-billing customers show the old amount after a manual waiver — a cache invalidation gap.
13:30 – She pairs briefly, adds a single line to invalidate the right key, commits another 11-line change to main.
Tomorrow morning’s staging deploy will pick it up; if nobody screams, it goes to production.
No ticket
No review queue
No “please review my PR is blocking me”
No surprise outage because two branches met for the first time in prod
Just eight people working on the same code, talking early, verifying real behaviour, deploying daily.
That team shipped 19 production changes that week.
Exactly zero required a hotfix.
Field Guide: Symptoms You Are Living in the Cargo Cult Right Now
Tick the ones you saw last week:
A 1,200-line “refactor” PR open for five days with 47 comments about brace placement
Reviewer writes “LGTM” after eight minutes on a 600-line diff
Friday 16:55 merge → Monday morning hotfix
Architect is the bottleneck because every PR needs their sign-off
Someone posts “Can I get a quick review? I’m blocked” at least twice a day
Half the comments are “nit: move this to a new line” or “rename this variable”
Incident post-mortem ends with “it worked on my branch”
Team proudly reports “99.3% of code reviewed” while cycle time is 3.8 days
If you ticked three or more: full-blown cargo cult.
If You Can’t Burn It All Down Tomorrow — Three Levers You Can Pull Monday Morning
Most teams can’t flip to pure trunk-based overnight. Fine. Start moving the needle.
1. Ruthlessly enforce tiny changes
Rule: any change > 200 LOC is closed and must be split.
Effect: reviewers (if you keep them) can actually understand the diff; integration risk drops; queue moves faster.
2. Run your pipeline on the merge result, not the branch
GitHub merge queue, GitLab merged-results pipeline, Bitbucket merge checks — enable them.
Now the tests run on the actual code that will ship, not a hypothetical branch state.
3. Require upfront design alignment for anything >1 day
A 15-minute live design sync or tiny written mini-RFC before coding starts.
Effect: the important discussion happens early, when it’s cheap.
Pull these three and, even with MRs, you’ve killed 80% of the harm.
Most teams that do this quietly drop mandatory reviews within six months.
Conclusion
Merge Requests became the default because most teams lack the prerequisites for real trust:
a coherent domain model
real-time collaboration
tiny integration steps
strong verification of merged code
The MR ritual feels like it solves those problems.
It actually prevents them from being solved.
Stop treating symptoms.
Fix the disease.
Appendix: The Five Standard Objections and Why They Collapse Under Pure Logic
Objection 1 — “We’re remote. We can’t pair or mob all the time.”
MRs do not create shared understanding — they hide the lack of it.
If synchrony is hard, invest in deliberate synchrony, not async shallow review.
Objection 2 — “Large codebase, lots of coupling. We need cross-team sign-off.”
A 20-minute glance at a large diff cannot detect subtle coupling breaks.
Only tiny changes or upfront collaboration can.
Objection 3 — “Reviews are how juniors learn the codebase.”
Diff archaeology is the slowest onboarding method ever invented.
A clean domain model teaches a newcomer the system in under an hour.
Sprawling procedural code takes weeks.
Objection 4 — “We need an audit trail of who approved what.”
Git already records who wrote and merged.
Most PRs are deleted after merge anyway.
If compliance truly needs sign-off, build a tiny tool — don’t make 200 engineers pay with their velocity.
Objection 5 — “Without reviews we’d ship tons of stupid bugs.”
Shallow bugs are cheap to fix in a real environment with real observability.
The expensive bugs are deep design flaws — and MRs consistently miss those.
None of the defences survive five minutes of honest reasoning.
The cargo cult is strong because it feels safe and looks professional.
But it is still a cult.
Time to walk off the island.
