Stop Ignoring Stale PRs. The Hidden Cost of Unfinished Code.
By **Andrew** — Founder of Signal Reads. Builder, reader, occasional contrarian.
> **Bottom line:** Initiatives like DigitalOcean's Hacktoberfest—offering rewards for accepted pull requests—routinely expose a massive, hidden tax in our industry: we are addicted to starting new work and fundamentally incapable of finishing what matters.
When external bounties trigger a flood of new, trivial PRs while complex 60-day-old PRs continue to languish, it proves our priorities are backward.
If your engineering culture rewards opening new branches over finishing stale ones, it isn't agile. It's broken.
Stop closing your stale pull requests. I'm serious.
After auditing my own company's repositories and realizing I had wasted significant investor money on unmerged code, I discovered that 'stale PRs' aren't a sign of lazy developers—they are the most expensive management failure in the tech industry.
For years, I was the kind of engineering founder who obsessed over velocity metrics.
I pushed my team to open more branches, tackle more tickets, and "move fast and break things." I equated raw keyboard activity with business value.
But when I actually analyzed what we were shipping, I realized "moving fast" was just a comforting lie we told ourselves to avoid the grueling work of finishing things.
The entire industry practice of setting up an automated GitHub Action to kill inactive pull requests after 30 days is a cowardly way out of a broken system.
Every week, I see engineering leaders brag on LinkedIn about their deployment frequency and successful agile transformations.
Meanwhile, their repositories are littered with 90-day-old feature branches that represent hundreds of hours of wasted human effort.
It's the equivalent of sweeping garbage under the rug and claiming you cleaned the house. And it is quietly bleeding your engineering budget dry.
The "Clean Desk" Fallacy
I get it. Every agile coach, every productivity guru, and every tech influencer tells you the exact same thing. Keep the board clean. Focus strictly on the active sprint.
If a PR hasn't been merged in two weeks, it's blocking the pipeline. It's creating mental clutter.
The conventional wisdom dictates that you either force-merge the code immediately or close it with a polite, automated message.
*"This PR has been inactive for 30 days. Closing to keep the repository tidy."*
We've collectively convinced ourselves that a pristine, empty PR queue equals a healthy, highly-functioning codebase.
We've built entire sub-industries of bots, Slack integrations, and dashboard widgets designed specifically to nag developers into abandoning their old work.
We measure success by how quickly we can sweep our unfinished business out of sight.
We’ve gamified the wrong metrics. Jira burndown charts look beautiful when you simply close the tickets you don't want to do, or when you automatically archive branches that have sat too long.
But a closed ticket without merged code is just a lie on a dashboard. It creates the illusion of progress while the actual product stagnates.
And five years ago, back in 2021, maybe they were right.
When codebases were smaller and microservices hadn't fractured our cognitive load into a million tiny pieces, a stale PR usually meant the developer simply forgot about it.
But the landscape has fundamentally shifted. The code we write today in 2026 is inherently more complex, requiring deeper architectural reviews and cross-team coordination.
Yet, we are still using superficial management tactics from half a decade ago to deal with the brutal realities of shipping modern software.
The Incentive Reality Check
Look at what happens during initiatives like DigitalOcean's Hacktoberfest.
Each year, developers are offered a reward—like a digital badge or having a tree planted in their name—to contribute to open-source repositories.
It sounds like a fun, lighthearted community engagement tactic. Do you know what actually happens?
The response is often so massive, so completely overwhelming, that maintainers have historically had to beg people to slow down.
Think about the implications of that for a second.
They are overwhelmed by low-effort spam. When you dangle a reward for simply opening or completing PRs, developers flood repositories with trivial changes instead of finishing complex, neglected work.
Maintainers find themselves literally crushed under the weight of this noise, while high-quality, nearly-complete code continues to sit there rotting.
**When observing the fallout from these incentive programs across major open-source repositories,** a pattern emerges that should terrify any engineering leader who thinks their agile process is actually working.
What the Patterns Actually Show
While trivial typo fixes and README updates flood the review queues, the PRs that actually matter remain months old and completely ignored.
A large portion of these forgotten PRs are substantial feature additions, critical memory leak patches, or major dependency upgrades that have simply stalled out in the final mile.
These are difficult, necessary changes that open-source maintainers and corporate engineers alike have poured days of their lives into.
Why do they stall? Not because the code is fundamentally flawed.
**Often, these stale PRs have already passed all automated CI checks.** They didn't fail the unit tests. They didn't fail the integration tests. They failed the attention economy.
They stall because they need a thorough review from a senior engineer who is simply too busy chasing the next shiny feature to look backward.
The original author did their job, pushed the code, and then waited in silence while the organization ignored them.
Open source maintainers are drowning in this exact dynamic. They are largely volunteers working nights and weekends to maintain the critical infrastructure that trillion-dollar tech companies run on.
When a contributor submits a complex PR, the maintainer has to find the mental energy to context-switch, review, test, and merge.
Instead of helping clear these crushing backlogs, incentive programs often bury these vital PRs under an avalanche of new, superficial pull requests.
The Feature Factory Epidemic
The real problem isn't lazy developers. It's that we've turned every engineering organization into a feature factory, and we are continually surprised when the assembly line backs up.
We heavily incentivize starting new things.
We eagerly promote engineers who "spearhead new greenfield initiatives" and "architect novel solutions from scratch." We reward the people who create the mess.
Think about your own company's all-hands meetings. When a new product is announced, there is applause, celebration, and back-patting for the team that "launched" the beta.
But when a team spends a month quietly paying down technical debt and merging three-month-old bug fixes, nobody claps.
We have built an incentive structure that actively punishes the exact behavior required to maintain scalable software.
When was the last time you saw a Senior Engineer get promoted to Staff purely because they were exceptional at reviewing other people's code and pushing stale work over the finish line?
Never. It simply doesn't happen in modern tech companies.
We treat code review as a secondary duty, an annoying distraction from the "real work" of writing net-new lines of code. So the PRs sit there. They gather dust.
The original author gets frustrated and inevitably moves on to the next Jira ticket, because that's what their performance review is based on.
Then, 60 days later, the stale-bot comes along and unceremoniously executes the PR. **We bury the sunk cost forever and pretend it never happened.**
The Silent Killer of Junior Talent
This dynamic doesn't just waste money; it actively destroys junior engineering talent.
Imagine being a junior developer who spends five days carefully crafting a feature. You push the code. You ask for a review.
And then... nothing. Crickets. The senior engineers are too busy firefighting to look at your work.
After three weeks, your code has merge conflicts. After four weeks, the underlying architecture changes. By week five, a bot closes your PR.
**We are teaching an entire generation of developers that their work doesn't matter unless it's immediately urgent.**
We are training them to value the appearance of motion over the reality of shipping.
The Devastating Cost of Context Switching
What leadership utterly fails to understand is the massive cognitive tax of leaving work unfinished.
When a PR goes stale, returning to it 40 days later means the developer has to re-load the entire mental model of that specific problem. The codebase has moved on without them.
Merge conflicts have multiplied like rabbits.
What would have taken 20 minutes to review and merge on day three now takes three hours of agonizing re-work on day forty.
You aren't saving time by delaying PR reviews; you are paying a massive, compounding interest rate on technical debt.
Organizations shouldn't have to rely on external incentives to finish their work.
The fact that these programs are so wildly successful is a glaring indictment of our entire industry's inability to prioritize completion over initiation.
How to Actually Fix Your PR Culture
Instead of spending thousands of dollars on agile consultants or writing more aggressive stale-bots to hide your dysfunction, here are four things that actually work in 2026.
1. Ban the Stale-Bot Immediately
If a PR is going to be closed, a human being needs to look the author in the virtual eye and explain exactly why their work is no longer valuable to the company.
**You must make the cost of abandoning work visible and painful.** When a bot closes a PR, it absolves leadership of guilt.
When an engineering manager has to manually close a 500-line PR that represents a week of an engineer's life, they feel the sting of wasted resources. Embrace that pain.
It is the only catalyst for real organizational change.
2. Cap WIP at the Review Stage
Most teams arbitrarily limit how many tickets an engineer can have in progress. That's the wrong bottleneck.
You need to limit how many pull requests can exist in the "needs review" state across the entire team.
If the review queue hits the limit, **nobody is allowed to write new code.** The entire team drops what they are doing and swarms the queue until it is clear.
Code that is written but not merged provides absolute zero value to the customer—it is pure liability. Treat it as such.
3. Mandate Synchronous Reviews for Stale Code
Stop relying on asynchronous comments for complex PRs. If a pull request has been open for more than 48 hours, mandate a synchronous review.
Get the author and the reviewer on a 15-minute call. Screen share. Talk through the logic.
**We lose so much time going back and forth in GitHub comments trying to sound smart, when a quick conversation could resolve the issue instantly.**
4. Tie Compensation to Completion
You have to put your money where your mouth is. If you want a culture of completion, you must reward it financially during performance cycles.
When you conduct performance reviews, explicitly measure how many PRs an engineer helped merge, not just how many they authored. The best engineers in your organization are force multipliers.
They don't just write code; they ensure code gets shipped safely.
**If your Staff Engineers are routinely ignoring PRs to write more of their own code, they aren't Staff Engineers. They are just highly-paid individual contributors actively blocking your pipeline.**
The Uncomfortable Truth
We are collectively addicted to the dopamine hit of a new `git checkout -b`.
Starting is easy, fun, and completely free of legacy constraints. It feels like real progress. You get to define the architecture, name the variables, and imagine a perfect, unbroken system.
Finishing is incredibly hard. Finishing requires compromise, tedious edge-case testing, and the grueling interpersonal work of achieving consensus with your peers.
It forces us to confront the reality that our code isn't perfect, and that our elegant solutions often collide messily with messy business logic.
But shipping is the only thing that actually matters in this business. Every line of unmerged code is just an expensive hallucination.
How many hours have you spent this year writing code that will never see a production server because it got stuck in review limbo?
When was the last time you asked yourself if you're actually building software, or if you're just generating inventory for a stale-bot to delete?
Have you noticed your team’s review culture slipping as your codebase grows, or is it just me? Let's talk in the comments.
---
