CODEOWNERS Alternative: Routing Reviews to the Right Expert

Most teams looking for a CODEOWNERS alternative don't need to delete the file. CODEOWNERS answers "whose approval does this path require?", while the tools that cover its gaps answer a different question: "who should look at this change, or this part of it, right now?" Keep CODEOWNERS for required approvals and add a routing layer on top. Aviator FlexReview picks reviewers by expertise score and review load, Cursor's PR Routing & Approval assigns reviewers from code ownership and commit history, and Warpway sends each open question to the person most likely to know the answer.

What CODEOWNERS does

A CODEOWNERS file maps path patterns to GitHub users or teams. GitHub's documentation describes how it works:

• The file goes in .github/, the repository root or docs/. It must be under 3 MB, or GitHub doesn't load it.
• Patterns use gitignore syntax, except that ! negation and [ ] character ranges don't work. The last matching pattern takes precedence.
• When a pull request changes owned code, GitHub requests review from the owners automatically. Draft pull requests are skipped until they are marked ready.
• A team listed as an owner must be visible and must have write permission.
• The branch protection setting Require review from Code Owners turns those requests into a merge requirement. An approval from any one of the owners satisfies it.

The mechanism works. A 2025 arXiv study by Lulla, Kula and Treude covered more than 844,000 pull requests and over 2 million reviews. It reports that code owners tend to follow the rules in the file, and that adopting CODEOWNERS shifts review work away from core developers. The file ships with GitHub, is versioned with the code, and GitHub enforces it once Require review from Code Owners is turned on.

Where CODEOWNERS falls short

Owners are set by hand

The file records what someone decided the last time they edited it. It doesn't know that the person who rewrote the retry logic last month is the one who understands it now, or that the team listed for /src/api/ has since been reorganized. Keeping it accurate is manual work, and nothing in the file shows that an entry is out of date.

Matching is by path, not by question

CODEOWNERS sees which files changed, not what a reviewer has to decide. Suppose a change to src/api/invoices.ts alters what happens to unused credits when a subscription is cancelled. It goes to the API owners, even though the decision belongs to whoever owns billing behavior, who may never open GitHub. A catch-all * line makes this worse, because every file without a more specific match goes to the same broad team.

Agents' cross-cutting changes fan out

A human author usually keeps a change inside their own area. A coding agent asked to rename a logging helper or bump an internal API edits every file the task touches. Take this file:

# .github/CODEOWNERS
*                  @acme/maintainers
/src/auth/         @acme/identity
/src/billing/      @acme/billing
/src/api/          @acme/platform-api
/web/              @acme/frontend
/db/migrations/    @acme/data

A mechanical rename across the whole repository requests all six teams. With Require review from Code Owners turned on, the pull request then waits for an approval from each of them. The July 2026 essay "CODEOWNERS for the Fleet" describes the same thing at larger scale: GitHub "matches every glob, and fans the review request out to forty teams simultaneously," and "the routing table executes perfectly and produces a result nobody wanted." One of its proposed fixes is to route first to the person who launched the agent. Another is to treat path matching as "one input to routing rather than the entire algorithm."

That second idea runs through all of the alternatives below.

The alternatives compared

This comparison is based on each product's own documentation as of October 2026:

Aviator FlexReview

FlexReview calls itself "a drop-in replacement for GitHub CODEOWNERS." It reads ownership from your existing CODEOWNERS file or from an .aviator/OWNERS file, picks up team memberships, and then chooses individual reviewers:

• Expertise. It scores every user for every file based on the file's modification history. The method is based on the forgetting curve, applied to pull request authoring and review history, so the score reflects both how recent and how extensive a person's work on the file is.
• Load. Each review or comment adds one unit of review load, which decays linearly over seven days. Candidates are split into a high-score group and a low-score group, and the reviewer comes from the high-score group, chosen to balance load.
• Fewer reviewers. It picks the smallest set of reviewers that satisfies ownership. On pull requests that span several teams, it looks for a shared parent owner.
• Replacing GitHub's requests. It replaces the reviewers GitHub requested through CODEOWNERS with its own picks.

For enforcement, FlexReview posts a status check that you can make required. It stores each approval against the reviewer's owned files for that commit. After a push, it dismisses only the approvals for files that changed, and it has a break-glass override for emergencies. Its docs recommend moving CODEOWNERS into an Aviator Owners file "to avoid GitHub overriding the validation settings." Its assignment page lists reviewer availability (timezone, out of office) as "Not implemented yet."

FlexReview suits teams that want to keep path ownership but have a system pick the right person within it, with load balancing and approvals tracked per file.

Cursor PR Routing & Approval

Cursor's PR Routing & Approval "assigns reviewers based on code ownership and commit history." Its routing context lives in the repository. .cursor/approval-policies/ROUTING.md is a YAML list of product entries, and each entry has a product, a boundary (a semantic boundary or a repository-relative path or glob) and the policies that apply. APPROVAL_POLICY.md files in a directory or its parent directories set approval rules. The closest APPROVAL_POLICY.md has the highest priority for files under its directory. When policies conflict the most specific one wins, and if specificity is unclear Cursor follows the stricter instruction and avoids auto-approval.

It can also approve low-risk pull requests that meet your criteria. Approval is limited by a risk score and a maximum risk threshold, and it won't approve if Bugbot or Security Agents report findings that need a person. If a pull request edits a policy or routing file, it uses the version on the base branch. Cursor states that the feature "does not replace a full code review." Its page doesn't say whether it reads CODEOWNERS or whether it explains why a reviewer was chosen.

It suits teams that already review in Cursor and want routing and low-risk approval rules defined in files next to the code.

How Warpway routes reviews

Warpway routes a smaller unit of work. AI investigates each eligible pull request through lenses such as Correctness, Security and Product Semantics, and clears what it can with evidence. When a lens can't resolve something material on its own, it becomes a human task: one question, with why it matters, the evidence gathered, the relevant lines and the kind of answer expected. Routing then picks a person for each question rather than a reviewer for the whole diff.

Who gets asked. Candidates come from these sources, in priority order:

1. The owner named on the rule that raised the question.
2. The lens owner.
3. CODEOWNERS entries for the relevant files.
4. Configured Slack contacts.
5. Configured GitHub teams and users.
6. People who reviewed this code before.
7. People who recently changed it (commits and blame).
8. The assignee or author of a linked issue.
9. Topic expertise, such as having answered similar questions.
10. A reviewer already on the pull request.
11. The organization's fallback owner.

A correction by an Admin outranks all of these. A catch-all * entry ranks just after the configured contacts. For non-engineering questions, CODEOWNERS and code history rank below configured contacts, linked issues and topic expertise. Expertise inferred from history counts half as much after 90 days, while explicit and CODEOWNERS ownership doesn't fade. Candidates found through history must already be people in your organization, and Warpway never asks bots or inactive people.

Why you. Every routing decision includes a reason in plain language, shown in the Slack message, in the check details and in the dashboard:

Routed to the @acme/security team on GitHub: CODEOWNERS owner of src/auth/**. Team membership is not synced, so the whole team was asked.

Rerouting. Anyone who is asked can press I'm not the right person in Slack, or comment /warpway wrong-person <code> on GitHub. Warpway takes them off the task, sends it to the next candidate, notes who was skipped, and lowers their expertise on that topic for future questions. By default, an unanswered task gets a reminder after 24 hours and moves to the next candidate after 72. If no candidates are left, the task stays visible as unassigned rather than disappearing.

Fan-out. Warpway requests a GitHub reviewer only when a task is best answered by a GitHub user or team, and its own reviewer requests are capped at two per pull request by default. On the agent rename above, Warpway asks people only about what the lenses couldn't settle, and each question goes to its own routed candidate. GitHub's automatic CODEOWNERS requests are separate: they still go to every owning team listed in the file, so narrow the file as described below.

Routing is configured in .warpway.yml on the base branch, on the Team plan:

version: 1
routing:
  security:
    github_team: "@acme/security"
  product_semantics:
    slack_user_group: "@product-leads"
    prefer_slack: true
  default:
    github_team: "@acme/maintainers"
rules:
  - id: credits-on-cancellation
    lens: product_semantics
    applies_to:
      paths:
        - billing/**
    instructions: Ask before changing what happens to unused credits when a subscription ends.
    owner: priya@acme.example
reviewer_requests:
  max_per_pr: 2

What it doesn't do. Warpway works with GitHub only. It doesn't replace CODEOWNERS or change branch protection. It reads CODEOWNERS as one routing source, and a passing Warpway / Review check isn't a GitHub approval. Routing starts at the Assist trust level; at Observe, Warpway asks nobody. Slack routing needs the Team plan, and on the Free plan tasks are routed through GitHub. The routing docs don't describe review-load balancing or out-of-office detection.

Keep CODEOWNERS for required approvals

Every option here can work alongside the file. One way to layer them:

1. Separate the two jobs. Keep CODEOWNERS entries only where an owner's approval is a real requirement, such as auth, migrations and billing, and turn on Require review from Code Owners for those. Remove entries that exist only to notify people, and put those routing targets in your routing tool's configuration.
2. Check the basics. Confirm that each owner team is visible and has write access, that the file is under 3 MB, and that no pattern relies on ! or [ ].
3. Add routing that doesn't block yet. In Warpway, start at Assist: questions are routed, each with the reason the person was chosen, but the check concludes neutral and never blocks a merge. Observe shows the questions on the pull request without routing them to anyone.
4. Feed corrections back. "Wrong person" answers and Admin reassignments both adjust future routing.
5. Gate when the results match your judgment. Make Warpway / Review a required check through merge gating, alongside code-owner review rather than replacing it.

If you adopt FlexReview's validation instead, its docs recommend moving CODEOWNERS into an Aviator Owners file to avoid GitHub overriding its validation settings.

For more on reviewing agent output, see how to review AI-generated pull requests.