Back

Agentic codeowners

/3 minute read

When a PR is opened, it needs to be reviewed by the right person. Most teams solve this with CODEOWNERS, which matches file paths to reviewers. But path based matching doesn’t account for risk. A safe refactor touching 50 files gets the same review requirements as a three line change to a critical path.

This caused two problems:

  • Low risk PRs sat in queues, blocking engineers who needed to ship
  • High risk PRs didn’t get enough review, because reviewers had too many PRs to look at

Agentic codeowners – image 1

What we built

We built an internal system that reads each PR and estimates risk.

  • Very low and low risk PRs get auto approved.
  • Higher risk PRs get routed to the right reviewer.

We can also use Git history to assign PRs to the most relevant reviewer where the person who has recently worked on the area being changed. This increases the chance of catching issues!

It’s built on Cloud Agents, which can be triggered by events like a new PR and act autonomously. Here’s an excerpt from the prompt:

# PR Risk Assessment & Review Assignment Guide

## Objective

Your job is to:

1. **Assess the risk level** of a Pull Request
2. **Determine whether code review is required**
3. **Assign reviewers (max 2) if required**
4. **Approve the PR, ONLY for Very-Low and Low risk categorization and ONLY if it has not already been approved**

If the PR is updated after approval, you must re-evaluate it and revoke approval if the risk increases. If the risk increases, you should unapprove the PR and leave a comment on the PR stating why.

If Codeowners review is required, do not approve the PR yourself.

If 2 or more reviewers are already assigned, don't add more reviewers.

The full version includes detailed examples for each risk level.

Here’s what an approved PR looks like:

Agentic codeowners – image 2

Break glass merges

Sometimes you need to merge outside the default workflow, e.g if the PR is urgent, or the agent’s routing is wrong.

We treat these as explicit exceptions and require a short reason, so we can audit what happened and calibrate the system. Internally, we use a Slack command like this:

@bot force-merge {link}. this is safe because {reason}.

We’re working on making it easy for any team to build workflows like this!

Originally published as an article on Xfavicon for x.com.

Further reading