When an engineering team gets big enough to own a dozen repositories, the "AI code review tool" question stops being about which bot leaves the best comments. It becomes three separate questions that most tool roundups never separate:
Can the tool actually pull context from across all the repos your change touches? Can its review be verified, or is it an uncheckable opinion? Where does its permission boundary stop?
Most vendor listicles answer none of these. They rank on marketing features: "400,000+ files indexed!", "works with GitHub, GitLab, Bitbucket!". Indexing more files is not the same as retrieving the right ones across a cross-repo change.
The first eval axis for a multi-repo team is the context-fetching harness, not the model. Pin it the way you pin model parameters. Does the tool know a symbol is defined in services/api, referenced in web/client, and changed in this PR across both? Or does each repo get reviewed as an island? A change that spans two repos is exactly what a human reviewer struggles with and what a single-PR bot will get wrong silently.
The second axis is verification. An AI review is a claim that a problem exists. On a large team, a false positive costs an engineer an interruption, and a false negative is a bug shipped. The tools that hold up are the ones where the reviewer's finding can be reproduced: a failing test, a linter hit, a specified permission check read from the codebase's own rules. If the review is an unverifiable prose opinion from a hosted model, then the quality of the review is the quality of whatever model the vendor happened to route to that day, and you cannot reproduce any of it.
The third axis is the permission boundary, and it matters more the larger the team. An agent with read access to every one of your repos can already see most of your plan. An agent holding keys routed through a tool is a credential surface you have not really enumerated. On a multi-repo team the blast radius is the whole platform, so the question is not "can it review my code" but "what can it read, write, and act on along the way."
The honest measure for a multi-repo team is to run one yourself: take a real cross-repo change, point each candidate at it, and check three things. Did it find the symbol defined in the other repo? Was the finding reproducible? Did it stay inside its boundaries? Those three answers decide whether the tool scales with your platform or just scales its own marketing.
