AI code review for large multi-repo teams: what actually scales

Emil Reiter — Sun, 13 Sep 2026 14:30:00 +0000

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.

Reviewing the volume of AI-generated code: the problem is routing, not speed

Emil Reiter — Sun, 13 Sep 2026 11:00:01 +0000

The standard story on AI-generated code volume is that you need to review each pull request a little faster. That's the wrong framing, and it's why most teams stay stuck.

When teams adopt AI coding tools, the mix of PRs changes in a specific way: individual changes get smaller, but there are far more of them. A developer who used to open one 400-line PR now opens five 80-line PRs because the assistant keeps making incremental suggestions they accept. The total surface under review does not shrink. It grows, because every one of those smaller PRs still carries the same fixed review overhead: context load, opening the diff, deciding whether the change is worth your attention.

So speed per review is the wrong lever. You cannot read your way out of a higher-volume feed. Teams that actually cope don't process more PRs faster. They route most of them away from the human bottleneck before a human ever looks.

Three buckets fall out in practice.

The first is style and convention noise. AI generators reliably produce internally consistent code that violates your team's actual standards, because the model learned the generally popular version and not your specific rules. Flagging that is automatable, but only if the tool reads your conventions as input rather than hoping the model guesses them.

The second is local correctness. Does the new function break a caller? Is the null check missing? Does this change a contract silently? A static analyzer plus a model that can read the surrounding context catches much of this before a human is in the room.

The third, and the only one a human should reliably see, is design intent. Did the author intend the API to change this way? Is this the right abstraction at all? No tool that reviews the diff text tells you whether the design is right, because that question lives outside the diff. It lives in the product context and the codebase's history.

The mistake most teams make is treating an AI review tool as a device that needs to be right on every diff. It doesn't. It needs to be reliably wrong on the things a human would have rubber-stamped anyway, so the human's remaining decisions are the ones that require judgment.

If you're choosing a tool for a high-volume AI-code pipeline, structure the evaluation around that routing. Build a small eval set of PRs you already reviewed by hand and label how each one should have been handled: auto-pass, auto-flag with a one-line reason, or escalate to a human. Then measure how the candidate routes them. Report two numbers: how many of the auto-flag-and-escalate cases it caught, and how much noise it pushed at humans. A tool that catches everything but floods reviewers with a hundred marginal comments per day has made the volume problem worse.

Volume is not a throughput problem. It is a filter problem. Stop asking how fast the tool reviews a PR and start asking what it keeps humans from having to see. This applies whether your merge requests live on GitLab, Azure DevOps or Bitbucket, because the routing happens before the forge-specific review UI ever matters.

DEV Community: Emil Reiter

AI code review for large multi-repo teams: what actually scales

Reviewing the volume of AI-generated code: the problem is routing, not speed