Custom rules for code review

Custom rules in code review

Custom rules in code review are team-specific standards a review tool checks pull requests against. They go beyond generic checks for bugs, syntax, and style.

A custom rule captures something particular to your team. A required pattern for external API calls, a banned library, a naming convention, a mandatory step for any PR touching payments.

Most AI review tools let you write these rules somehow, whether in a YAML config, a markdown file like AGENTS.md, or plain-language instructions in a portal. What varies more is what happens after a rule is written: does it stay a static file, or does someone track whether it still works.

How Are Custom Code Review Rules Written?

Most tools support one of two approaches, and many support both:

Config or instruction files committed to the repo. CodeRabbit uses a .coderabbit.yaml file. AI coding agents increasingly read AGENTS.md or similar files for the same purpose. These live in version control and travel with the code.
Natural-language instructions. Instead of a fixed syntax, you describe the rule in plain English: "flag any function that logs a raw user object." The tool interprets the instruction rather than matching a pattern.

Rules also need a scope. Global rules apply everywhere. Project-specific rules apply only to a given repository. A rule that makes sense for a payments service rarely makes sense for a marketing site in the same org.

What Makes a Custom Rule Actually Work?

Writing a rule is the easy part. A few things separate rules that hold up from ones that quietly stop mattering:

Practice	Why it matters
One topic per rule	Hard to test or measure a rule doing three things at once
Concrete over vague	"Use the shared logger wrapper" beats "log responsibly"
Version-controlled	Committed rules get reviewed like code; rules in someone’s head don’t
Tested against real examples	Should fire on the pattern it targets, stay quiet elsewhere
Reviewed periodically	A rule written two years ago may not fit the current architecture

The common failure isn’t writing a bad rule. It’s writing a reasonable one, adding it to a config file, and never checking whether it’s still accurate or duplicated by three others written since.

How Does Qodo Support Custom Rules in Code Review?

Most code review tools treat a custom rule as a file: something a developer writes once, commits, and hopes the team remembers to update. Qodo treats it as a governed system instead, with a lifecycle that discovers rules from real review behavior, measures whether they’re actually working, and retires or fixes them when they stop being true. The result is a ruleset that reflects how the team reviews code right now, not how it reviewed code the day someone wrote the config file.

How a rule enters the system

Written manually in the Rules portal
Imported from existing tools like ESLint or SonarQube
Generated automatically by Rule Miner, which scans pull request history for review comments that were accepted and led to code changes, weights them by the reviewer’s ownership of that code, and turns recurring patterns into rule candidates

What happens once a rule exists

Enforced automatically during both PR and IDE review
Scoped across repos, groups, and orgs with approval workflows
Checked for duplicates, contradictions, and staleness
Tracked for adoption and violation trends over time

That last point is the real contrast with config-file tools. CodeRabbit reads a .coderabbit.yaml file you write and maintain yourself; it surfaces a rule violation as feedback for the reviewer to act on. Qodo ties the same kind of finding to a defined rule and can block the merge until it’s resolved.

Qodo’s Take on Custom Rules in Code Review

A rule nobody maintains isn’t a standard. It’s a liability waiting to misfire or go silent.

The real work isn’t writing the first version of a rule. It’s keeping a growing set of them accurate as the codebase and the team change underneath them. Rules need the same lifecycle discipline as code: created from evidence, measured for impact, retired when they stop being true.

Example: Turning a Recurring PR Comment Into an Enforced Rule

A platform team keeps seeing the same reviewer comment across a dozen PRs: new external API calls need a timeout and retry policy, but it’s easy to forget.

Before the rule exists, a coding agent writes this without either:

def get_user_profile(user_id):
    response = requests.get(f"{API_BASE}/users/{user_id}")
    return response.json()

Rule Miner picks up the recurring pattern from PR history and proposes it as a rule, flagged for human review before it goes live. Once approved:

An agent opens a PR adding a new external call with no timeout
Qodo flags it automatically before a human reviewer opens the PR
The finding names the missing pattern and what to add
The agent updates the code:

def get_user_profile(user_id):
    response = requests.get(
        f"{API_BASE}/users/{user_id}",
        timeout=5
    )
    response.raise_for_status()
    return response.json()

The rule applies the same way across every repo making external calls, regardless of which engineer or coding agent wrote the change. Over the following months, the violation count drops, itself a signal the rule is working, which a static config file has no way to surface.

Best Suited For

Qodo is the best AI code review, code quality, and governance platform for engineering teams whose coding standards outgrow a single config file. When rules need to survive team turnover, apply consistently across dozens of repos, and stay maintained without someone remembering to revisit a YAML file, that’s what Qodo’s rule lifecycle is built for.

Further reading: AI code review tools comparison and benchmarks, CodeRabbit alternatives, and Qodo vs CodeRabbit.