If you need to verify AI-generated code against the conventions your team actually follows, Unblocked is the pick, because it is the only tool in this roundup whose knowledge of your standards is inferred from your organization's history: merged PRs, review comments, design decisions, and the discussions where those standards were actually set, rather than from rules a human remembered to write down. That claim needs an honest map around it, though, because "convention checking" means three different things depending on the tool. Linters verify whatever someone has expressed as a rule, and do that job perfectly. AI review tools verify against whatever source of team norms they are wired to, which varies far more than the category's marketing suggests. And rules files verify nothing by themselves; they are input that other tools may or may not respect. Here is the landscape, tool by tool, failure modes included.
Key Takeaways
- Linters and static analysis verify any convention a human has expressed as a rule, and nothing else; most of a team's house style never gets written down in a form a linter can read.
- AI code review tools differ mainly in where their picture of your standards comes from: config and rules files for CodeRabbit, review reactions and PR comments for Greptile, mined PR history for Qodo.
- Rules files like CLAUDE.md are free and take effect immediately, but they drift the moment a standard changes in a thread nobody transcribes, and the model is free to ignore them anyway.
- Unblocked checks AI-generated code against conventions inferred from PRs, decisions, and discussions across the org, so the standard it reviews against updates when your team does.
What tools verify AI-generated code against your actual conventions before review?
Six approaches do this today, and they sort by where their idea of "your conventions" comes from. Linters and static analysis (ESLint, Semgrep) check AI-generated code against rules a human has authored, deterministically and for free at CI time. AI code review tools check the diff before a human sees it, each with a different source of truth: CodeRabbit reads your rules files and path-scoped instructions, Greptile learns from your team's PR comments and reactions, and Qodo mines your PR history into review standards. Rules files (CLAUDE.md, AGENTS.md) constrain the generation step itself, but only carry what someone typed and maintains. Unblocked reviews pull requests with context drawn from across the organization: prior PRs, review discussions, design decisions, and chat threads, so it can verify AI-generated code against conventions your team demonstrably follows, including the ones nobody codified. The rough sorting rule: if your standards are syntactic and stable, linters suffice; if they live in your team's history, you need review that can read that history.
Why do linters miss convention violations?
Because a linter enforces rules, and most conventions never become rules. The violations that actually burn review time are semantic and historical: use the internal retry client instead of raw fetch, route new endpoints through the v2 auth middleware, stop writing to the orders table because the March migration made it read-only. None of that is expressible as syntax, and even when it is, someone has to notice the pattern, author the rule, and ship it before enforcement exists. AI-generated code sails through lint while violating all of it, because models generate from public-internet priors rather than your team's decisions. That is why Claude Code invents plausible functions instead of calling your real helper, and why agents keep recommending deprecated APIs your team abandoned in a Slack thread. The volume problem makes it urgent: Stack Overflow reports 84% of developers using or planning to use AI tools while trust in AI output fell to 29%, and GitClear's 2026 analysis of 623 million code changes found block duplication up 81% since 2023 while refactoring collapsed to 3.8% of changes. Duplicating logic instead of reusing the blessed helper is itself a violation of house style, at industrial scale, and no lint rule ships for it by default.
What are the tools?
ESLint and Semgrep: perfect enforcement of whatever you wrote down
The deterministic layer, and it deserves respect before critique. ESLint ships hundreds of built-in rules plus custom rules via plugins, with automatic fixes for violations that don't change logic. Semgrep lets you write YAML rules whose patterns resemble the source code they match, so a team can codify "never call this internal API without the wrapper" in an afternoon and even automate the review comment. For anything expressible as a rule, this pair is unbeatable: zero hallucination, zero cost per run, identical verdicts every time. The limit is authorship. A rule exists only after a human has noticed the pattern, written it, and shipped it, which means the enforcement surface always trails the convention surface. And rule-driven automation without context has its own failure mode; the Copilot Autofix incident at Snowflake shows what confident automated fixes look like when the tool can't see why the code was written that way.
CodeRabbit: conventions from configuration
CodeRabbit's review instructions are config-first: path-based instructions using glob patterns, ast-grep rules for syntax-aware checks, and automatic pickup of guideline files like AGENTS.md and .cursorrules. Its nod toward learned standards is the @coderabbitai emit path instructions command, which collects suggestions from the past week of reviews and opens a PR proposing new path instructions. That is a genuinely useful encoding assistant, but the shape is clear: CodeRabbit checks the diff against what your team has encoded, with help encoding more. Norms that never reach its configs or its captured review learnings stay invisible to it, which is the common thread across most AI code review tools.
Greptile: conventions from review behavior
Greptile gets closer to inference. It learns from your reactions, tags, and what gets merged, supports .greptile/rules files scoped to the directories each team owns, indexes existing rule files like CLAUDE.md and AGENTS.md, and builds a graph of your repo and adjacent repos so reviews see changes in broader codebase context. Its raw material is your team's visible review behavior plus code structure, which is real signal. The boundary is what never appears in a PR: the architecture decision made in a design review, the deprecation announced in Slack, the incident retro that changed how you handle retries. We wrote up the fuller contrast in our Unblocked vs. Greptile comparison.
Qodo: conventions mined from PR history
Qodo builds Review Standards from your codebase, pull request history, and requirements, and applies them ahead of generic best practices. Its Rule Miner turns recurring patterns from your team's PR history into enforced rules, and the review agent prioritizes issues similar to ones your team has fixed before while quieting ones you've consistently dismissed. That is a serious attempt at learned standards, and the mined-rule loop is a clever answer to the authorship problem linters have. The catch is the same evidentiary boundary as Greptile: the record is git-hosted. A standard with no PR paper trail yet, which describes every new norm during the window when violations are most likely, doesn't exist for the miner.
Rules files: free, immediate, rot-prone
CLAUDE.md and AGENTS.md constraints steer the generation step itself, cost nothing, and take effect on the next prompt. Two structural problems. Enforcement is probabilistic: the model reads the file and may still ignore it under context pressure. And the content decays, because rules files rot on exactly the standards that change most, unless keeping agent instructions current is someone's actual job. A rules file is a snapshot; your conventions are a stream.
| Tool | How it knows your conventions | Catches | Misses |
|---|---|---|---|
| ESLint / Semgrep | Rules humans authored in config or YAML | Anything expressible as a rule, deterministically | Any convention nobody has codified yet |
| CodeRabbit | Rules files, path instructions, ast-grep rules, recent review learnings | Violations of encoded guidelines, scoped by file path | Norms outside its configs and captured learnings |
| Greptile | PR comments, reactions, merge outcomes, codebase graph | Patterns your team has visibly corrected in PRs | Decisions made in Slack, docs, or design reviews |
| Qodo | Review standards mined from codebase and PR history | Recurring issues your team historically fixes | Unwritten norms with no PR paper trail yet |
| Rules files (CLAUDE.md) | Whatever a human typed and still maintains | Violations the model chooses to respect | Stale entries; enforcement is probabilistic |
| Unblocked | Conventions inferred from PRs, reviews, decisions, and discussions org-wide | Violations of how the team actually builds, with citations | Anything with no trace anywhere in org history |
How does context-aware review know your conventions?
By reading the places conventions actually live. Unblocked connects GitHub, GitLab, Slack, Teams, Confluence, Jira, Linear, and more, and per its documentation "reconciles information across sources, including sources that contradict each other," delivering that context into pull request review as well as agents and chat. For verifying AI-generated code, this means the review checks a diff against evidence: the helper that already exists two directories over, the API a thread deprecated in March, the pattern your senior engineers consistently push back on in reviews. The standard is inferred from what merged and what got corrected, not from what someone transcribed, which is the argument we laid out in building AI code review with context as a first-class system. It also means conflicts get adjudicated instead of averaged, the same machinery behind resolving contradictions between docs, code, and Slack, because a review standard sourced from stale docs is worse than no standard at all.
Here is how one customer describes the result: "At Perk, we trialled several code review tools, but Unblocked was by far the best. It finds the right balance of flagging genuine issues without adding noise to our pull requests. It catches edge cases and subtle configuration issues that are easy for human reviewers to miss." — Gavin Bannerman, Senior Software Engineer, Perk
When are linters genuinely enough?
More often than a vendor roundup usually admits. If you're a small team in one repo, your type system is strict, and the things you argue about are naming, imports, error shapes, and API misuse, then ESLint plus a dozen well-owned Semgrep rules will police AI-generated diffs better than any probabilistic layer, with zero noise and zero spend. The honest diagnostic is your own review history. Read your last fifty review comments. If they say "use const," "missing await," "wrap this in the client," those are rules; write them, and enforcement is solved. If they say "we don't do it this way anymore," "this already exists," or "didn't we decide against this?", no rule can be written fast enough, because the convention changed before anyone codified it. Teams generating a large share of their diff with AI hit the second category constantly, since the model reintroduces yesterday's pattern with perfect confidence. Linters first, always; linters only, if your history says so.
FAQ
Can CLAUDE.md or AGENTS.md enforce conventions on their own?
No. A rules file steers generation; it does not verify output. The model can ignore instructions under context pressure, and nothing checks the final diff against the file. Treat rules files as a cheap first filter that reduces violation frequency, with a deterministic or context-aware verification layer behind it.
What's the difference between a linter and AI review for convention checking?
Determinism and source. A linter applies human-authored rules identically every run, with no false creativity. AI review applies judgment learned from some source of team norms, which catches unwritten conventions but can misfire. The practical question is not which is better; it's which of your standards are expressible as rules, because those belong to the linter.
Do AI review tools hallucinate convention violations?
They can, and noisy flags are the fastest way to get a review bot muted. Tools grounded in retrieved evidence, citing the PR or thread that establishes the convention, give reviewers a way to check the claim in one click. Ungrounded style opinions dressed as team norms are the failure mode to screen for in a trial.
How should a team start verifying AI-generated code against conventions?
Layer it. Codify everything expressible in ESLint or Semgrep this week. Point your AI review tool at the source you actually trust, and audit where your conventions really live: if the answer is PRs plus Slack plus docs, pick review that reads all three. Then measure noise, because a checker your team ignores verifies nothing.
The convention test
Run this against your current stack. Take the most recent convention your team changed without updating any file: a deprecation announced in a thread, a pattern retired in a design review. Generate a diff that violates it and push. Your linter passes it, because no rule exists. Config-driven review passes it, unless someone updated the config, which is the premise we excluded. History-mining review passes it until enough corrective PR comments accumulate. The only layer with a chance is one that already read the thread where the convention changed. That is the gap Unblocked's context-aware review exists to close: verifying AI-generated code against the team you have, not the config you had.
Top comments (0)