BetaMulti-tenantSingle-tenant
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.
How Qodo learns from your pull request history
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.
What signals shape the rules
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 PRs rises into a rule candidate. One-offs don’t. |
| Pattern clustering | Qodo maps where feedback concentrates to produce area-specific rules, scoped to the paths they govern. |
| Rejected suggestions | Dismissed findings reduce a rule’s signal over time, so noise fades on its own. |
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.
| Setting | Description |
|---|
| Mine rules from code review history | Turn Rule Miner on or off for the organization or a specific repository. |
| Auto-approve rule miner suggestions | Controls what happens to generated rules. See How rules are activated after generation below. |
How rules are activated after generation
| Setting | What happens | When to use |
|---|
| Auto-approve on | 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. |
How Rule Miner generates rules over time
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:
On first run, 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, with a source type of Mined Pattern.
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.
View the source pull request for each rule
Each rule includes a link to the pull request it was generated from. The link appears in the Source field in the rules table and in the rule sidebar.
Source links let you:
- Verify that a generated rule reflects a real, recurring standard.
- Share context with teammates when reviewing or editing a rule.
- Understand why a rule was generated before deciding to activate or dismiss it.
What’s next
