How to Get Qodo's Mined Review Rules Into the Agent Writing Your Code (Step-by-Step, 2026)

Code review is where standards get enforced on most teams, and it works by rework. Somebody writes it one way, a reviewer who has seen this go wrong before flags it, and it gets rewritten. The knowledge transfer is real, and it happens after the work.

With a human author that loop is tolerable — reviewers correct once and the author usually remembers. With an agent writing the code, the loop does not close. The agent that wrote it the wrong way will write it the wrong way next week, because nothing about the review became part of what it knows. You pay the rework cost repeatedly instead of once.

Rule Miner makes this both better and more visible. Better, because the standards become explicit artifacts instead of living in one senior engineer's head. More visible, because you can now see the list of things your reviews keep catching. Qodo is precise about what qualifies: "Only comments that were accepted by developers and led to code changes are considered." Each mined rule represents a correction that actually landed, repeatedly.

The signal weighting tells you what these rules are. 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 feedback "rises into a rule candidate," and "a single comment can also qualify when it comes from a reviewer with strong ownership of the affected code." Clustering produces "area-specific rules, scoped to the paths they govern." And the system self-corrects: "once a rule is active, dismissed suggestions it generates reduce its signal over time, so noise fades on its own."

That is a well-designed learning loop aimed entirely at the reviewer. The author — increasingly an agent — is not in it.

Hand-writing an AGENTS.md from review feedback. Someone reads three months of pull requests and distills conventions into an instruction file. It works and then it stops, because nobody repeats the exercise. Six months later the file describes last spring's standards, and the failure is invisible: an out-of-date instruction file looks exactly like a current one. That is the drift problem in why agents ignore your instruction files.

Copying Qodo's mined rules into an instruction file by hand. Better, since the source is maintained. Worse in maintenance, because Rule Miner keeps going — it "continues learning every two weeks, generating up to 5 new rules per repository per run" — and your copy does not. Two sources of truth with a manual sync step is one source of truth and a bug.

Letting review catch it. The honest default most teams are on. Fine for humans, expensive for agents.

Assuming the agent will infer conventions from the codebase. Agents are decent at matching visible local patterns and bad at inferring prohibitions. Nothing in your code says "we stopped doing it that way after the incident"; the absence of a pattern is not readable as a rule.

Step 1: Find out what has actually been mined, and on what window

Before wiring anything up, look at what exists. Mined rules appear in the Rules tab on the Review Standards page "with a source type of Mined Pattern," which distinguishes them from rules a human wrote. If your repository shows none, check the trigger condition before assuming something is broken: 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," and rules appear "within a few hours of the first run."

Two boundaries matter more than the count.

The first is the window. Qodo states that "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," and then says the important part outright: "This is not your repository's full history." For a busy repository, a thousand merged pull requests can be a few months. Standards your team established and then successfully stopped violating — which is what success looks like — may sit entirely outside that window, precisely because nobody has needed to flag them recently. Qodo is direct that low output is not a malfunction: "A repository can be perfectly healthy and still produce only a few rules, or none at all."

The second is activation, and it depends on a date. Qodo's documentation states that Rule Miner is enabled by default, and that "for organizations that started using Qodo since September 1, 2026, generated rules activate automatically," while "for organizations onboarded before that date, generated rules first appear as suggestions in Rules > Suggestions for review before they are enforced." Both settings are changeable — "Mine rules from code review history" and "Auto-approve rule miner suggestions" live in the portal configuration under the Context tab, in the Review standards section — but which default you are on determines whether mined rules are already shaping reviews or waiting in a queue. Check before you assume.

Step 2: Install the Agentic Toolbox and confirm Get Rules is reachable

The Agentic Toolbox is Qodo's mechanism for putting these capabilities inside the agent you already use. Its own framing: it "brings Qodo's code understanding, coding standards, and review capabilities into your existing coding agent" and "does not replace your coding agent or require you to interact with Qodo directly."

Installation is a one-line script from Qodo's install endpoint — their docs give the macOS, Linux, and Windows PowerShell forms — and it requires Node.js 20 or later. Read the script before you run it, the same as any install-by-pipe. Two things to know about what happens next: "the installer installs the toolbox and configures the available Qodo tools for supported agent environments," and "you can install the Agentic Toolbox without a Qodo account, but you'll need to sign up or log in to Qodo before your agent can actually run any of the tools." Both the toolbox and Get Rules are documented as Beta.

Get Rules is exposed through several interfaces: a Claude Code plugin, a Codex plugin, a Kiro plugin, a CLI, agent skills, and an MCP Server for "any MCP-compatible client or agent." The MCP path is the one to prefer if your team is not all on the same client, since it does not tie the setup to one editor's plugin system.

Confirm it works by asking your agent, in a repository connected to Qodo, what rules apply to the task you are about to start. What comes back should combine scopes — Qodo's docs say Get Rules "combines global rules, repository-specific rules, and contextual guidance," and its FAQ is explicit that it "includes applicable global rules in addition to repository-specific rules." If you only see repository rules, the organization-level scope is probably not connected yet.

Worth noting what it does not do: "Does Get Rules modify code? No. Get Rules provides the agent with applicable guidance." It is a read.

Step 3: Tell your instruction file when to ask

A tool the agent never calls is a tool you did not install. This is the step people skip and then conclude the feature does not work.

Qodo's docs are direct about it: "Coding agents can use the Agentic Toolbox more effectively when its instructions are included in their agent instruction file. Add the Qodo Agentic Toolbox instructions … to your agent instruction file, such as AGENTS.md or CLAUDE.md, to help the agent use the Toolbox effectively throughout its workflow." They publish a default template for this.

The line that matters is the trigger: rules should be loaded before implementation begins, not after the first failure. Qodo's FAQ states the intent — "rules are loaded before implementation begins, allowing the agent to use them while generating code rather than discovering issues during review" — and the point of the instruction file entry is to make that the agent's habit rather than your reminder. Write it as a precondition on writing code, not as an available capability.

One operational detail: the toolbox updates itself. "During interactive use, the Agentic Toolbox periodically checks for updates and installs a newer version in the background," and by default it "adds newly released recommended skills to coding agent environments where you already installed Qodo skills." It "does not overwrite skills that you own or have customized," which is the right behavior, but the tool surface can grow without you doing anything.

Get Rules closes the loop on standards that went through code review. There is a second category it does not reach, and it is the one that costs teams the most.

Qodo's own framing draws the boundary for you. Rule Miner works on "comments that were accepted by developers and led to code changes," within an indexed window of roughly a thousand merged pull requests. Everything your team decided that never took the form of a review comment is outside that: the architecture call made in a meeting, the conclusion from an incident postmortem, the vendor constraint a customer imposed, the approach you tried twice and abandoned for reasons no diff records. None of it is enforceable as a review rule, and none of it is in the window.

MemoryLake holds that half — a store outside any repository or review platform, readable over MCP or an API by whichever agent is working, and built to be corrected rather than to go quietly stale.

Step 1: Create an API key

Generate a key and make your first request in about thirty seconds. One key covers every agent surface your team uses, which is what keeps the knowledge from being a property of one platform.

Step 2: Upload your first memories

Drop in the documents, images, and files that already hold decisions review never saw — postmortems, architecture decision records, the design review everybody refers to and nobody rereads.

Step 3: Connect your AI & agents

Give Claude, Codex, OpenClaw, and other agents access over MCP or the API. Combined with Get Rules, the agent starts a task with both halves: the standards your reviews enforce, and the decisions your reviews never discussed.

Review findings drop for a boring reason: the agent stops making the mistakes your reviewers were catching, because it was told about them before it wrote anything. Qodo names this as the goal — rules "as guardrails from the first line of code."

The two-week mining cadence starts compounding instead of accumulating. New rules reach the author automatically rather than waiting for someone to update an instruction file, so the gap between "we learned this" and "the agent knows this" is one mining cycle rather than one volunteer.

Onboarding changes shape. A new engineer's agent gets the same mined standards as everyone else's on day one, plus the decisions that predate the mining window. That is close to the whole reason "tribal knowledge" is a phrase, and it is the same problem as keeping AI context when someone leaves.

And the mining window stops being a hidden liability. Once older decisions live somewhere that is not a pull request index, it does not matter that they fell out of the last thousand merges.

Check which activation default you are on. Auto-approve on means mined rules are already enforced; auto-approve off means they are queued in Suggestions. The behavior depends on when your organization onboarded.

Read the Suggestions queue before approving in bulk. Mined rules reflect review behavior, which includes reviewer preferences you may not want as standards.

Prefer MCP over a single client plugin. Get Rules ships as Claude Code, Codex, and Kiro plugins plus an MCP server. MCP survives a change of editor.

Make the tool call a precondition. Put it in AGENTS.md as something the agent does before writing code, not as a capability it may use.

Do not hand-copy mined rules into instruction files. Rule Miner keeps generating; your copy will not. Retrieve instead of duplicating.

Rule Miner is built on a correct observation — that most engineering standards "exist only in reviewer memory" — and it does something useful with it, converting accepted, repeated review feedback into explicit rules with sensible weighting and a self-correcting signal. The gap is placement. Review standards run at review time, which is the wrong end of the loop when the author is an agent that will not remember being corrected.

Get Rules is the piece that fixes it, and the setup is three real steps: see what has been mined and on what window, install the toolbox and confirm Get Rules is reachable over an interface you will still be using next quarter, and make the call a precondition in your instruction file rather than an option.

Then be honest about the window. A thousand merged pull requests is a lot of review history and a small share of what a team knows. The decisions that never became review comments — the meeting, the incident, the customer constraint, the two failed attempts — are exactly the ones people re-explain most often. Those need a store of their own, and once they have one, the standards your reviews enforce and the decisions your reviews never saw arrive at the same time: before the first line of code.