Every engineering team has standards that live outside any document: patterns that senior engineers flag consistently, conventions enforced through repeated review comments, and practices that exist only in reviewer memory. Most of these never make it into formal rules.Rule Miner analyzes your organization’s pull request history to surface these patterns automatically and generate rules from them, turning tribal knowledge and informal, repeated feedback into enforceable standards without requiring manual rule creation.
Qodo scans pull request discussions across your connected repositories and identifies recurring review patterns: comments that were accepted by developers and led to code changes, recurring behaviors that reviewers consistently flag, and the accept/reject patterns that follow.From these patterns, Qodo generates rules and either activates them directly or adds them to the Suggestions tab for approval before activation, depending on your configuration.After the initial analysis, Qodo continues to scan new pull requests at regular intervals, adding new rules as patterns emerge.
Only comments that were accepted by developers and led to code changes are considered. Among those, the following factors determine which patterns become rules:
Signal
How it works
Reviewer code ownership
Qodo estimates each reviewer’s ownership of the changed code and weights their comments accordingly, so rules reflect the standards of those most familiar with it.
Recurring comments
Feedback that appears repeatedly across pull requests rises into a rule candidate. A single comment can also qualify when it comes from a reviewer with strong ownership of the affected code.
Pattern clustering
Qodo maps where feedback concentrates to produce area-specific rules, scoped to the paths they govern.
Rejected suggestions
Once a rule is active, dismissed suggestions it generates reduce its signal over time, so noise fades on its own.
To configure Rule Miner, go to the portal configuration page, open the General review tab, and find the Review Standards section. Use the repository selector to apply settings to all repositories or a specific one.
Rule Miner is enabled by default. The rules it generates first appear as suggestions in Rules > Suggestions for your review before they are enforced. You can change this behavior using the settings below.
The following settings are available:
Setting
Description
Mine rules from code review history
Turn Rule Miner on or off for the organization or a specific repository.
Generated rules are activated automatically. They are visible in the Rules tab on the Review Standards page and are enforced on the next pull request review.
You trust the quality of generated rules and want enforcement without manual review steps.
Auto-approve off (default)
Generated rules appear in Rules > Suggestions for review before activation. No rules are enforced until an admin explicitly accepts them.
You want to review generated rules before they affect pull request reviews.
If auto-approve is off, review and activate generated rules from Rules > Suggestions. See Suggested rules for the full flow.
Rule Miner is a learning system. The rules it generates reflect your team’s actual review behavior, and the output grows more precise as more pull request activity accumulates over time.On first run:The first run is triggered when the first pull request is opened on a repository after it connects to Qodo, not automatically at connection time. Once triggered, Rule Miner analyzes your organization’s recent pull request history and generates an initial batch of up to 10 rules per repository, depending on the volume and consistency of your review history. Rules appear in the Rules tab on the Review Standards page within a few hours of the first run, with a source type of Mined Pattern.Rule Miner draws on an indexed window of up to approximately 1,000 of your repository’s most recently merged pull requests, which can include activity from before your repository was connected. This is not your repository’s full history, so the size of the first batch depends on how much reviewed, merged activity falls within that indexed window.
On subsequent runs:Rule Miner continues learning every two weeks, generating up to 5 new rules per repository per run as new patterns emerge from recently merged pull requests. Rules appear in the Rules tab or Suggestions tab, depending on your activation mode.If your repositories have substantial review history, Rule Miner works through it progressively: established patterns surface first, with rules derived from more recent pull request activity following in later rounds. This means the first few runs may reflect older patterns before newer findings appear, not because recent activity is ignored, but because Rule Miner builds a strong signal base before moving forward. As your team continues reviewing and merging pull requests, the rule set keeps evolving to reflect current standards.Rules that are too similar to existing ones (whether manually created or previously mined) are skipped automatically.
Rule Miner surfaces standards your team has already enforced in code reviews. The number of rules it generates reflects your review activity, not a fixed target. A repository can be perfectly healthy and still produce only a few rules, or none at all. That’s normal, and depends on the content and review activity in the repository, not an error.
Rule Miner looks for a narrow, high-confidence signal, and each stage filters the available review activity:
The comment must call out a specific code issue or standard. General praise, questions, and minor nitpicks don’t count.
The author must have applied the suggested fix for a comment to count as a candidate signal. A comment whose fix was dismissed or ignored doesn’t contribute to a new rule, though rejected suggestions from an already-active rule instead reduce that rule’s signal over time.
The pattern typically needs to recur, unless it comes from a reviewer with strong ownership of the affected code. See What signals shape the rules.
Because each stage narrows the pool, a rule represents a small, high-confidence subset of your team’s overall review activity. Repositories with lighter review activity, or where suggestions are rarely applied, may produce few rules or none.
The first Rule Miner run does not start until the first pull request is opened on the repository after connecting. Once triggered, indexing and analysis take some time to complete, so rules may not appear right away, even if the repository has prior review history.
A repository has had regular merges for a while and still has no rules
The review history likely doesn’t contain enough accepted fix suggestions yet. This is common and is not an error.
Some repositories have rules and others don’t
Normal. Repositories with active, constructive reviews produce rules. Lower-activity or newer repositories may not.
Rules appear gradually over time
Rules reflect your team’s review activity as it happens, so they accumulate as your team continues reviewing and merging pull requests.
