Most teams don’t realize this, but their biggest bottleneck isn’t architecture, tech stack, or even legacy code.
It’s pull requests.
If you read about trunk-based development, you’ll see the same advice repeated everywhere: small changes, frequent merges, fast feedback. Sounds simple. Almost obvious.
And yet — in reality — most teams are nowhere near that.
I’ve personally seen pull requests sitting open for months. Not days. Not weeks. Months.
At one point, we had a pull request in our team that was open for more than six months.
Six.
Months.
At that point, it’s no longer a pull request. It’s a parallel universe.
Below this link you can read first article about Trunk-Based Development
The Hidden Cost of Large Pull Requests
Let’s be precise about what’s happening here.
A large pull request is not just “a bit harder to review”. It fundamentally breaks your delivery system.
Here’s what actually happens:
1. Review becomes a cognitive nightmare
When a PR has:
- 1,000+ lines
- multiple concerns (API, DB, UI, validation)
- partial refactors
No one can realistically review it properly.
So what happens?
- reviewers skim
- they miss edge cases
- they delay the review (“I’ll look at it later”)
And “later” turns into never.
2. Feedback loop collapses
Fast feedback is the core of modern development.
But with large PRs:
- feedback comes late
- feedback is vague
- feedback is expensive to apply
Instead of:
“Fix this small thing”
You get:
“This entire approach might be wrong”
Now the author has to:
- rethink everything
- rework large chunks of code
- re-request review
Cycle time explodes.
3. Merge becomes risky
The bigger the PR, the higher the risk:
- conflicts with main branch
- outdated assumptions
- broken integrations
So teams hesitate.
And hesitation kills flow.
4. Work gets batched (and everything slows down)
This is the core anti-pattern.
Instead of shipping continuously, developers start batching work:
“I’ll just add one more thing before I open the PR”
Then:
“Actually, I’ll include this refactor too”
And suddenly:
- PR grows
- review slows
- merge is delayed
It’s a vicious cycle.
The Real Reason Your PRs Are Too Big
Let’s be honest — this is not a tooling issue.
It’s behavioral.
Here are the real causes:
1. “I want it to be complete”
This is the most common mindset:
“I’ll open the PR when the feature is done.”
Sounds reasonable. It’s also completely wrong.
Because “done” often means:
- multiple layers
- edge cases
- polish
Which leads to massive PRs.
2. Fear of breaking things
Without proper safety mechanisms (tests, feature flags), developers avoid small merges.
So they wait.
And wait.
And accumulate changes.
3. Poor slicing of work
Most developers split work like this:
- backend PR
- frontend PR
- DB migration PR
Instead of:
- vertical slices that deliver value end-to-end
This creates artificial dependencies and forces larger PRs.
4. Review culture is asynchronous and slow
If reviews take:
- hours
- or days
Developers adapt by batching work.
Why open a small PR if it will just sit there?
The 6-Month Pull Request Problem
Let’s go back to that real example.
A PR open for six months.
What does that actually mean?
- The branch is completely outdated
- The context is lost
- The author doesn’t remember all decisions
- The reviewers don’t understand it anymore
At that point, you have only two realistic options:
- Merge it blindly (high risk)
- Close it and start over (lost work)
Both are bad.
But the real failure happened much earlier — when the PR was allowed to grow beyond control.
How to Fix This (Practically)
This is not about theory. These are concrete practices that work.
1. Enforce a hard PR size limit
Set a rule:
Max ~300–400 lines per PR
Not as a suggestion.
As a constraint.
Why?
Because constraints force better behavior:
- better slicing
- fewer concerns per change
- faster reviews
2. Merge incomplete work (safely)
This is the shift most teams struggle with.
You don’t need “finished features” to merge.
You need:
- safe code
- controlled exposure
Use:
- feature flags
- toggles
- hidden UI states
This allows you to:
- merge early
- iterate safely
- Slice vertically, not horizontally
Instead of:
- PR 1: database
- PR 2: API
- PR 3: UI
Do:
- PR 1: minimal end-to-end functionality
- PR 2: extend behavior
- PR 3: polish
Each PR:
- delivers something usable
- is independently testable
- is small
4. Optimize review speed (not just quality)
Set expectations:
- PR should be reviewed within a few hours
- not days
Ways to achieve this:
- smaller PRs (obviously)
- clear ownership
- synchronous reviews when needed (pairing)
5. Accept “ugly but correct” code (temporarily)
This is uncomfortable but critical.
Sometimes the right move is:
“Merge this small, slightly imperfect change now”
Instead of:
“Wait until it’s perfectly clean”
Why?
Because flow matters more than perfection.
You can always:
- refactor later (but don’t forget — it’s important for code cleanup)
- improve incrementally
6. Track your actual behavior
If you want to be serious about this, measure:
- average PR size
- PR lifetime
- number of merges per day
Reality check:
If your PRs:
- live for days
- contain hundreds/thousands of lines
You are not doing trunk-based development.
No matter what your team says.
The Real Mindset Shift
This is the uncomfortable truth:
Small pull requests are not a technical practice.
They are a discipline.
They require you to:
- let go of “completeness”
- embrace incremental delivery
- prioritize flow over polish
And that’s hard.
Because it goes against how most developers naturally think about work.
Final Thought
That 6-month pull request wasn’t an exception.
It was just an extreme version of a very common problem.
Most teams are operating with:
- oversized changes
- slow feedback
- delayed merges
And then they wonder why delivery feels slow.
If you fix just one thing, fix this:
Make your pull requests smaller. Radically smaller.
Everything else — faster reviews, fewer bugs, smoother delivery — follows from that.
Not the other way around.