CODEOWNERS was designed for ownership, not for routing. It answers "who owns this file?" not "who should review this specific change, right now, given what else is on their plate?" Those are different questions, and treating them as the same one is why reviewer assignment is still a manual chore at most engineering orgs.
The problem with static ownership files
A CODEOWNERS entry is a snapshot in time. It reflects who worked on something when the file was last updated, which might be six months ago, before two engineers left the team, before a reorganization, before the codebase shifted architecturally.
In practice, teams end up in one of two failure modes. Either the same two or three senior engineers get assigned to every review (because they're listed for everything), or nobody gets assigned because the file is out of date and no one has cleaned it up. GitHub's own research from 2023 found that 47% of CODEOWNERS entries point to engineers who are no longer the most active contributors to that code.
The deeper problem is that "ownership" and "expertise" aren't the same thing. Someone can own a module they haven't actively worked in for eight months. Someone else might have touched it 12 times in the last six weeks on a cross-cutting refactor. For a specific PR, the second person is probably a better reviewer, but CODEOWNERS will route to the first.
What good routing actually needs to know
Routing a PR review well requires answering four questions:
Who understands the specific lines being changed? Not who owns the file, who actually wrote or recently modified the exact lines in the diff. Git blame is the right signal here, not file-level ownership.
Who has been active in these files recently? Recent commit history in the changed files tells you who has a live mental model of the code. An engineer who committed to a file 3 times in the last 2 weeks will review it more effectively than someone who wrote the original version 18 months ago.
Who has reviewed PRs in this area before? Review history is underused as a signal. An engineer who has reviewed 8 PRs touching the auth module has built context that doesn't show up in commit history.
Who has capacity right now? Expertise is irrelevant if the person has 6 open review requests sitting in their queue. Routing everything to the most expert person just creates a bottleneck.
How Codzee calculates routing scores
Codzee blends four signals into a per-engineer expertise score for each PR. The weights are based on what we found to be most predictive of useful reviews in our beta:
All signals decay exponentially with a 90-day half-life. A commit from 3 months ago contributes roughly half the score of an equivalent commit from today. This means the routing adapts as teams shift focus, the engineer who's been deep in the payments module this quarter naturally surfaces for payment-related PRs, even if they weren't involved 6 months ago.
Recency decay: why it matters more than you'd think
The 90-day half-life was not our first choice. We initially tried a 180-day window, and found that routing still skewed heavily toward engineers who had done large foundational work on a module even when other engineers were now actively maintaining it. Cutting to 90 days made routing noticeably more responsive to recent activity patterns without making it too reactive to short sprints.
This is the kind of calibration that static ownership files can't do. A CODEOWNERS entry is either there or it isn't. A signal-based scoring system can weight recent work more heavily than old work, and the routing naturally follows the team's current reality rather than its historical one.
The load balancer problem
Getting the expertise score right is only half the problem. The other half is making sure you're not routing everything to the same two people.
In our beta, we found that without a load penalty, the top-scoring reviewer for any given PR received the assignment 68% of the time. On a team of 10, that means 2 engineers are doing most of the review work. The rest are underutilized, which means they're also not building the contextual knowledge that comes from doing reviews.
The load penalty reduces an engineer's score based on how many open review requests they currently have. The penalty is not linear, it's designed to kick in sharply once someone crosses 3 open reviews, which is roughly when review quality starts dropping in our data.
What actually changes for your team
The immediate difference is that PRs stop sitting unreviewed because no one knows who should look at them. The less obvious difference is what happens over time: review coverage spreads more evenly across the team, junior engineers build context by getting routed to areas they've been contributing to, and senior engineers spend less time on PRs where someone else would do an equally good job.
None of that requires changing your CODEOWNERS file. It just requires the routing to ask a slightly different question.
See who Codzee would route your next PR to.
Free during beta. Installs on GitHub in 2 clicks.