Put a named human on the dangerous paths
Require a named owner's review on the paths that handle money, auth and migrations.
Not all code is equally dangerous, and treating it as if it were produces review fatigue that makes the dangerous parts LESS examined, not more. Naming an owner on a narrow set of paths is the cheapest way to guarantee that the changes which can lose money or leak data get a specific person's attention rather than the team's diffuse attention.
What goes wrong: A payment or permission change merged by whoever was online, with nobody who understood the invariant it broke.
You are violating it when
- No CODEOWNERS file, or one that maps everything to one team.
- Auth and billing changes are reviewed by whoever is free.
- Your riskiest directory has no named owner.
The usual objection: That CODEOWNERS is about blame. It is about routing: getting a diff in front of the one person who already holds the context.
Some files deserve a specific reviewer, not just any reviewer. Payment flows, authorization logic, and database migrations carry invariants that are easy to break and expensive to discover late. A path owner turns those areas into an explicit routing table: when a diff touches them, the review request goes to the person or group expected to understand that part of the system.
The mechanism matters because review attention is finite. If every change receives the same undifferentiated review rule, routine edits compete with changes that can lose money, leak data, or corrupt state. Combining path ownership with an enforced merge rule changes ownership from documentation into a gate: the risky diff cannot land until the named owner has approved it.
The misconception is that CODEOWNERS is about blame. That framing makes ownership feel punitive and encourages broad, vague ownership. The useful framing is routing. The owner is the person already holding the context, tradeoffs, and historical scars for that path, so the review starts with the right human instead of whoever happened to be online.
When an agent writes the code, this becomes more important rather than less. Agents can produce plausible edits across unfamiliar boundaries, including money, auth, and schema code. A named human on those paths creates a deliberate handoff from generated change to accountable domain review before merge.
Install it
npx klay practices add codeowners-on-what-matters.github/CODEOWNERScreate# CODEOWNERS — route the dangerous diffs to the person who holds the context. # # This file only ROUTES review; it does not enforce it. To make it binding, # turn on "Require review from Code Owners" in your branch protection rules # (Settings → Branches → your default branch). Without that, this is a # suggestion. # # Deliberately NOT a catch-all. A CODEOWNERS that matches every path produces # review fatigue, and review fatigue is how the paths that actually matter stop # getting read. Match narrowly; leave the rest to normal review. # # Replace the placeholders with real GitHub usernames or @org/team handles. # A team must have write access to the repo or the rule is silently ignored.
The previews are the first lines of each file; the command writes them in full. Existing files are never overwritten.
How you know it stuck
npx klay practices audit reports this check for this practice:
codeowners-present
Where this comes from
- About code owners - GitHub DocsDefines ownership as automatic review routing when a diff touches paths with assigned maintainers.
- Available rules for rulesets - GitHub DocsShows the current GitHub control for making owner approval a merge requirement.
- What to look for in a code reviewAdds the judgment principle: route risky changes to reviewers qualified for that domain.
- ossf/scorecardContributes an external, machine-checkable signal that review-before-merge is configured.
Questions
- Does this not create a bottleneck?
- Only on the paths you deliberately chose to slow down. If it feels like a bottleneck everywhere, the file is matching too much.