Skip to content

Build1 publisher2 min readPublished

AI code reviewers mean three different things when they promise to follow your standards

AI code reviewers lose hosted rule ingestion first on self-managed GitLab, Azure DevOps Server and Bitbucket Data Center, a dev.to comparison says. Of the three mechanisms it compares, only a pass/fail rule can block a merge, and vendors tend to put that one on paid tiers.

The Engineer · Build desk

Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction

Illustration accompanying AI code reviewers mean three different things when they promise to follow your standards
Generated illustration

What happened

  • CodeRabbit detects guideline files such as AGENTS.md, CLAUDE.md, .cursorrules and .github/copilot-instructions.md on its own and applies them as review criteria without configuration.
  • CodeRabbit pulls guidelines from another repository only within a shared GitHub organization, GitLab top-level group or Bitbucket Cloud workspace, and its docs mark the Bitbucket option Cloud Only.
  • Listing CLAUDE.md under CodeRabbit's path_instructions makes the reviewer review that file as changed code; the filePatterns setting is what applies it as a guideline.
  • Qodo manages review standards as governance objects in its portal, giving an organization one rule set across every repository without each repo carrying the right file.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • constraint On Bitbucket Data Center, CodeRabbit users cannot point reviews at a central standards repository, so each repository has to carry and maintain its own copy of the guideline file.
  • exposure A convention kept only in a rule file is reinterpreted on every run, so a rule the team treats as mandatory can be flagged on one pull request and missed on the next.
  • decision Choosing between CodeRabbit and Qodo also decides where standards live: in files that travel with each repo, or in a vendor portal that governs all of them centrally.

The post starts from the complaint behind the phrase. Teams use "Follows our coding standards" when they mean "does not post the same generic nit for the fourth time" [2]. It then splits that request into three approaches that fail in different ways [1].

A rule file such as CLAUDE.md or AGENTS.md is read and interpreted as review criteria, and the post says that interpretation is inconsistent across runs [4]. A per-path instruction maps a glob to free text. A note about auth, input validation and ORM bypasses then applies only under src/controllers/** [5]. In a monorepo, the post argues, that scoping separates useful comments from noise [5]. An enforcement rule has a severity and a path scope, and it either fires or it does not [6].

Only the enforcement rule gives a hard stop [7]. According to the post, severity levels and the ability to gate a merge are where vendors draw plan lines [6]. On self-hosted installs the same feature can require a licensed deployment [7].

The edition warning is the post's broadest claim. It says hosted rule ingestion is the first thing to disappear on GitLab Self-Managed, Azure DevOps Server and Bitbucket Data Center [3]. Of those three, the post backs the rule with a documented product limit for one: Bitbucket Data Center, through CodeRabbit's Cloud Only cross-repo entry [1]. I'd treat the warning as established for that edition and as a claim still to be tested on the other two [1].

Inside a single repository, CodeRabbit's file handling is careful engineering. Matching is case-sensitive, so a file named claude.md is not picked up [9]. Scope follows the directory. A root CLAUDE.md applies to everything, and src/backend/.cursorrules applies only under src/backend/ [10]. When placement does not match the files a guideline should govern, the object form of filePatterns takes an explicit applyTo glob [10]. A monorepo gets per-path precision from the same documents that people and coding agents already read [4].

Qodo handles rules in its governance area. Its docs describe Review Standards as turning "your organization's engineering conventions into something that can actually be enforced," with rule enforcement as the explicit, checkable form [13]. It also reads a REVIEW.md instructions file and can generate rules by indexing PR history [14]. A team's old review arguments become candidate policy.

For a team that mainly wants fewer repeated nits, I think in-repo files with directory scoping are the right place to start. The post calls the rule file the lowest-effort option, and the applyTo override covers the monorepo case [4][10].

What to watch

  • Whether CodeRabbit extends cross-repo guideline sources to Bitbucket Data Center, or documents comparable limits for GitLab Self-Managed and Azure DevOps Server.
  • Which plans and self-hosted licences carry severity levels and merge gating for each vendor, since the post places the plan lines there.
  • Whether Qodo's portal-managed standards run on the self-managed editions the post names.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories