Most teams think about technical debt in terms of code: the abstraction that was a shortcut, the test suite that was never written, the refactor that kept getting deferred. Review debt is less discussed but accumulates with similar mechanics and compounds in a similar way. A skipped review is small. A pattern of skipped reviews over 18 months is a codebase where significant portions have never been examined by anyone other than the person who wrote them.
We spent time analyzing the review history of a growing development team over roughly 18 months. The patterns were consistent enough to be worth writing down.
How review debt starts
Review debt almost never starts with a policy decision. Teams do not decide "we will stop reviewing PRs carefully." It starts with a sprint. There is a deadline, a competing priority, a team member who is sick. A few PRs get rubber-stamped: approved without meaningful scrutiny, or approved by the author's immediate peer who is also swamped and trusts the author. No incident follows. The deadline was met. The PRs that got rubber-stamped were probably fine.
The problem is the information asymmetry that persists after the sprint. The changes that went in without review are in the codebase, referenced by other code, built on top of. No one except the original author has any understanding of them. When the next developer needs to change something in that area, they are working from first principles because there is no institutional review of that code's design.
This is how review debt starts: not as a bug, but as a gap in the team's shared understanding of the codebase.
The compounding mechanism
Review debt compounds because un-reviewed code tends to attract more un-reviewed code. There are two mechanisms for this.
First, a module that was merged without review becomes locally authoritative. When the next developer works in that area, they pattern-match on the existing code. If the existing code has patterns that were never reviewed, those patterns propagate. The first PR missed a null check. The next three PRs in the same module follow the same pattern because that is how the existing code does it. The reviewer on those later PRs either does not notice the pattern or assumes it was deliberate. The pattern is now four PRs deep.
Second, un-reviewed code is harder to review later. Code that was reviewed incrementally, as it was written, benefits from reviewers who had context about the intent at the time of writing. Code that was written without review and is reviewed six months later is more opaque: the original author may not remember the reasoning, the context has shifted, and the reviewer is seeing a finished product rather than a design-in-progress. The review that would have taken twenty minutes at PR time takes two hours at refactor time, and is still less complete.
In the dataset we looked at, there was a consistent pattern: the modules with the highest ratio of low-scrutiny PRs (short review time, no substantive comments) had the highest subsequent bug report rate in that same module. This is not a controlled experiment and the correlation has confounders: high-churn modules are both more likely to receive rushed reviews and more likely to have bugs. But the directionality was consistent across modules and teams, which is the part worth paying attention to.
The "good enough" threshold problem
One mechanism that sustains review debt is the "good enough" threshold: a mental standard that a PR just needs to not look obviously wrong to merit approval. This threshold gets calibrated by how often approval turns out to have been wrong. If a rubber-stamp approval leads to a production incident, the reviewer recalibrates upward. If rubber-stamp approvals consistently result in no obvious incident, the threshold stays low.
The problem is that the feedback loop is extremely noisy. Most bugs do not cause immediate production incidents. They cause subtle behavioral changes that surface weeks later, or intermittent failures in edge cases, or performance degradations that only appear at load. The causal connection between a specific skipped review and a bug three months later is rarely made explicit.
This means the "good enough" threshold does not self-correct the way other engineering thresholds do. You get an alert when your latency spikes; you do not get an alert when you approved a PR without actually reading the business logic section. The feedback absence makes it structurally hard to maintain high review standards through discipline alone.
Where automated checks change the economics
Automated PR checks at open time change the economics of review in a specific way: they remove the category of mechanical issues from the reviewer's attention budget. This matters for review debt because a significant fraction of low-quality reviews are low-quality not because the reviewer does not care, but because the reviewer is spending their available time on mechanical checking and has less capacity left for substantive review.
If a reviewer spends ten minutes checking a PR for obvious style violations and simple linting issues, and they have fifteen minutes total to spend on the review, they have five minutes left for actual design and logic review. If those mechanical checks are handled before the reviewer opens the diff, the full fifteen minutes is available for substantive review. The same time produces a more thorough review.
We built PRCheck with this specific pattern in mind. The goal was not to replace the review; it was to make the time the reviewer does spend go toward the issues that matter. A consistent automated pass before human review opens shifts what reviewers are spending their time on.
Detecting review debt before it becomes structural
The signal that review debt is accumulating is visible in the review history if you know what to look for. PRs approved under two minutes consistently are a flag. Not because short reviews are always bad (a two-line change can take thirty seconds), but because a module where every PR over the past quarter has been approved in under two minutes has not been genuinely reviewed.
Review debt is also visible in review disparity: some PRs in the same codebase receive extensive scrutiny while others receive none. If the disparity maps to who submitted the PR (senior engineers get rubber-stamped, junior engineers get thorough reviews), that is a different problem. If it maps to the time of week (Friday afternoon PRs get less scrutiny), that is a scheduling problem. If it maps to the module (the payment processing module gets thorough reviews, the notification service gets rubber-stamped), that is a systematic gap.
Identifying the disparity early makes it manageable. A specific module that has been under-reviewed for two months can be addressed with a targeted review session or a refactor. A module that has been under-reviewed for two years while accumulating 60 PRs is a much harder cleanup.
A note on what this does not mean
We are not arguing that every PR needs the same level of scrutiny. A one-line configuration change and a new authentication flow are different risk profiles and should be treated differently. Calibrated review depth, where review investment scales with the risk and complexity of the change, is the right model. The problem is not variance in review depth. The problem is systematic under-review of specific modules or PR categories because the process has no mechanism to ensure coverage.
Review debt, like technical debt, is most manageable when it is tracked and deliberate. A team that consciously decides "we are going to defer thorough review on this minor utility module until next sprint" is in a different position than a team that drifts into low-quality reviews without noticing. The former can pay the debt back. The latter often cannot, because the debt is not visible until it has already compounded into something much harder to address.