AI Code Review for Monorepos: A Complete Guide

AI code review for monorepos is a different problem than AI code review for single-service repositories. A monorepo can contain dozens of services in five or six languages, each with its own conventions, each owned by a different team, and each interacting through shared protocols, generated code, and internal APIs. A review tool that treats every pull request as an isolated diff will miss the bugs that matter most — the ones where a change in one package breaks a caller in another.

This guide covers what monorepo teams should look for in an AI code review tool: multi-language analysis, path scoping, per-directory custom rules, and cross-service bug detection. It compares how Macroscope, CodeRabbit, and Greptile handle monorepo-specific problems.

TL;DR — AI Code Review for Monorepos

• Cross-file analysis matters more in monorepos. Most production bugs in a monorepo cross service boundaries. A review tool that only reads the diff misses them.
• Multi-language support is mandatory. Macroscope ships dedicated AST codewalkers for eight languages: Go, TypeScript/JavaScript, Python, Java, Kotlin, Swift, Rust, and Ruby. Other languages (Vue.js, Elixir, PHP, C#, C++) fall back to diff-based LLM review.
• Path scoping is how you control noise. Check Run Agents support include and exclude globs so a frontend rule never runs on backend code.
• Per-directory rules let each team own their standards. Multiple .md files in a .macroscope/ directory define independent, scoped reviewers.
• Macroscope detected 48% of production bugs in a 118-bug benchmark across 8 languages — the highest in the industry.
• Monorepo-aware integrations matter. Ticket context from Jira or Linear, Slack deep links for the right channel, and per-service spend limits all keep large teams coordinated.

What Is AI Code Review for Monorepos?

AI code review for monorepos is the application of automated AI code review tools to repositories that contain multiple services, multiple languages, and multiple teams in a single codebase. It differs from AI code review for single-service repositories in three ways: it must understand cross-file and cross-service dependencies, it must apply different standards to different directories, and it must keep comment volume low enough that teams shipping dozens of pull requests a day can still triage every signal.

The best ai code reviewer for a monorepo combines AST-level analysis for each language, path-scoped custom rules, cross-file bug detection, and usage-based pricing that scales with review activity rather than seat count. This guide compares how Macroscope, CodeRabbit, and Greptile handle each requirement.

Why Is AI Code Review Harder in Monorepos?

Monorepo bugs tend to live between files, not inside them. A change to a shared protocol, a common library, or a service contract can be correct in isolation and broken in the consumer — and a review tool that only reads the diff will ship the bug.

In a single-service repository, a pull request usually touches code that is tightly coupled. The reviewer reads the diff, understands the function being changed, and evaluates whether the change is correct. AI code review tools handle this case well.

In a monorepo, a pull request might touch a shared protobuf definition, a Go service that produces those messages, and a TypeScript service that consumes them. A bug can hide in the gap — the Go change compiles, the TypeScript change compiles, but the two sides disagree on what the wire format looks like. Reviewing the diff alone will not catch it. The review tool needs to understand that the protobuf file has downstream consumers, trace through the generated code, and evaluate whether the producer and consumer still agree after the change.

This is the core challenge of code review for multi-language repos: the bugs live between the files, not inside them.

Monorepos also have organizational scale that shapes how review tools have to work:

• Multiple teams each own different directories, with different conventions, different languages, and different standards.
• Different services have different risk profiles — a payment service needs stricter review than a marketing site.
• The same PR can span five review contexts — frontend, backend, shared schemas, infra, docs.
• Noise is fatal at scale — if a review tool leaves 10 comments per PR and a team ships 200 PRs a week, that is 2,000 comments a week to triage. Most will be ignored, and the real bugs will get buried.

Multi-Language Support: The Foundation

The first thing a monorepo team should evaluate in any AI code review tool is how many languages it actually analyzes with structural depth, not just treats as text.

Macroscope ships dedicated AST codewalkers — language-specific parsers that build a complete reference graph of the repository — for eight languages:

• Go
• TypeScript / JavaScript
• Python
• Java
• Kotlin
• Swift
• Rust
• Ruby

For each of these, Macroscope parses the source into an Abstract Syntax Tree, tracks every function call, every type reference, every import, and every assignment. When a pull request changes a function, Macroscope traces every caller across every file in every package to evaluate whether the change introduces a bug. In the 118-bug benchmark, Macroscope detected 86% of Go bugs, 56% of Java bugs, and 50% of Python bugs — languages where structural analysis pays the most dividends.

For other languages — including Vue.js, Elixir, Starlark, PHP, C#, and C++ — reviews still happen via diff-based LLM analysis. The detection rate is lower than for AST-walked languages, but the tool still reviews the code rather than skipping it.

CodeRabbit supports a similarly wide language set and integrates 40+ linters and static analysis tools (ESLint, Semgrep, and others). CodeRabbit's approach blends AST Grep pattern matching with retrieval-augmented generation and LLM analysis. It works across GitHub, GitLab, Bitbucket, and Azure DevOps.

Greptile supports GitHub and GitLab and indexes the repository's call graph at the function level. Greptile does not publish a language-by-language detection breakdown, but independent evaluations found lower detection rates than Macroscope or CodeRabbit across the languages tested.

For a monorepo, the practical question is: does the tool have language-specific depth for the languages that actually ship your product? If your critical path is Go + TypeScript + Python, you want AST-level analysis for all three.

Path Scoping: Keeping Rules Targeted

The second critical feature for monorepo code review is the ability to scope a rule, a check, or an entire reviewer to specific paths. Without this, any custom rule you add will run across the entire repository, firing on files it has no business commenting on.

Macroscope's Check Run Agents are custom reviewers defined as markdown files in a .macroscope/ directory at the root of your repository. Each agent has a YAML front-matter block that supports path globbing. To scope an agent to frontend paths only, use include:

---
title: frontend-a11y
model: claude-opus-4-6
include:
  - "apps/web/**"
  - "packages/ui/**"
---

You are an accessibility reviewer for the web app. Flag missing aria-labels
on interactive elements, incorrect heading hierarchy, and color-contrast
issues in inline styles.

To scope an agent to everything except certain paths, use exclude instead:

---
title: repo-wide-security
model: claude-opus-4-6
exclude:
  - "**/__tests__/**"
  - "**/*.stories.tsx"
  - "targets/corporate/**"
---

You are a security reviewer. Flag any direct use of eval, unsafe
deserialization, or secrets committed to source.

A note on precedence: include and exclude should not be combined in the same agent — if both are specified, include wins and exclude is silently ignored. Pick one or split the concerns into two agents. The same repository can have half a dozen of these agents, each scoped to a different package, running in parallel, each enforcing a different team's standards.

This is the right primitive for a monorepo. Each team writes the rules they care about, scoped to the paths they own. A backend rule never runs on frontend code. A Python rule never runs on Go code. A migration rule runs only during the migration and is deleted afterward.

CodeRabbit supports per-path configuration via .coderabbit.yaml with path-based review instructions and path-specific tone settings. It is a similar primitive with a different shape — one central file instead of many scoped markdown files. Teams that prefer a single source of configuration will prefer CodeRabbit's approach; teams that want each package to own its own rules alongside the code will prefer Macroscope's .macroscope/ directory.

Greptile offers natural-language rules learned from PR comment patterns. Scoping is less explicit — rules are inferred from past reactions rather than declared with glob patterns.

Per-Directory Custom Rules: Giving Each Team Ownership

In a monorepo, different directories often have different owners, different conventions, and different review standards. A good review tool lets each team own its review rules alongside its code.

Macroscope's .macroscope/ directory supports multiple markdown files:

.macroscope/
├── web-review.md          # Frontend team's rules
├── api-review.md          # Backend team's rules
├── migration-review.md    # Infra team's migration guardrails
├── security-review.md     # Security team's mandatory checks
└── docs-review.md         # Docs quality rules

Each file is an independent Check Run Agent with its own scope, its own prompt, and its own severity level. Agents run in parallel, post comments on the pull request with a named check run, and can optionally block merge if the conclusion is severe enough.

This pattern has a few monorepo-specific advantages:

• Codified ownership. The .macroscope/api-review.md file lives next to the API code. The backend team owns it. When the team's conventions change, the file changes with them.
• Incremental adoption. A new team can add their agent without waiting for central approval. If the migration team wants a temporary migration-review.md that runs for two weeks during a schema rollout, they can add it and delete it without touching anyone else's rules.
• Blast radius control. A buggy rule in web-review.md cannot affect backend reviews. Path scoping guarantees isolation.

For monorepos where teams ship independently but review together, this is the level of granularity that matters.

How Does AI Code Review Catch Bugs Across Files and Services?

AST-based AI code review tools trace every caller of a changed function across every file in the repository, then evaluate whether any caller would break after the change. This is the cross-file capability that diff-only tools cannot match.

The bugs that hurt most in a monorepo are the ones that cross service boundaries. A function signature changes in a shared package. Three services import it. Two get updated in the PR. One does not. The build passes because the third service is in a different language or uses code generation. The bug ships.

Macroscope's AST reference graph is built for exactly this case. When a function signature changes, Macroscope traces every caller across every package in the repository. If a caller in another language would receive an argument it does not expect, Macroscope flags it on the PR — even though the file with the broken caller is not part of the diff.

In the 118-bug benchmark, this cross-file capability is why Macroscope's detection rate on structural bugs is substantially higher than diff-only tools. Most real production bugs in a monorepo are cross-file. A tool that only reads the diff catches the syntactic issues and misses the structural ones.

Greptile's agentic search can follow nested function calls across files, but its approach is more exploratory than systematic. The agent decides what to investigate. AST-based analysis traces every caller by construction — there is no decision, every dependent is examined.

CodeRabbit's hybrid approach does perform cross-file analysis, but not via AST reference graphs. Detection rates on cross-file bugs in the benchmark were 2 percentage points behind Macroscope (46% vs 48%), with considerably higher comment volume.

For a monorepo team evaluating code review for multi-language repos, cross-file bug detection is the single highest-value capability, because cross-file bugs are the dominant failure mode at scale.

Auto-Fix in a Monorepo: Why an AI Code Fixer Matters at Scale

An AI code fixer closes the loop from "bug found" to "bug fixed" without a human writing the patch. In a monorepo, this matters more than anywhere else — most review comments are small, repetitive fixes that waste senior engineer time to address one at a time.

Macroscope's Fix It For Me is the only fully integrated detect-fix-validate pipeline among AI code review tools. When Macroscope finds a bug, replying "fix it for me" triggers Macroscope to:

1. Create a new branch from the PR branch
2. Implement the fix using full codebase context (the same AST reference graph used to find the bug)
3. Open a fix PR against the original branch
4. Run the project's CI pipeline
5. If CI fails, read the logs and commit another fix attempt
6. Repeat until tests pass
7. Optionally auto-merge the fix PR

No other AI code review tool iterates on CI failures inside the fix loop. CodeRabbit offers one-click commit suggestions, but they are not validated against the project's test suite. Greptile's "Fix in X" button sends context to external tools (Cursor, Claude Code, Codex) — the fix happens outside Greptile, with no CI validation. Cursor BugBot's Autofix runs in cloud VMs but does not integrate with the calling repository's full CI matrix.

For a monorepo with 40 services and 12 different CI pipelines, an automated code review tool that closes the loop on simple fixes without a human round-trip measurably changes throughput. A team shipping 500 PRs a month with an average of two actionable comments per PR has 1,000 fix operations available to offload to Fix It For Me — many of which land without any engineer touching the keyboard.

The exact phrase "ai code fixer" or "code fixer ai" has validated search demand. Macroscope is the only tool in this space that can credibly claim to ship one.

Comment Volume and Precision at Monorepo Scale

In a monorepo, comment volume scales with PR throughput. A team shipping 50 PRs a day with a tool that averages 10 comments per PR is triaging 500 comments a day. Most will be ignored. Real bugs will get lost in the flood.

Precision matters more in monorepos than anywhere else:

Tool	Detection Rate (118-bug benchmark)	Avg Comments per PR	Runtime-Relevant Comments per PR
Macroscope	48%	2.55	~2.50 (derived: 2.55 × 98% precision)
CodeRabbit	46%	10.84	4.69
Cursor BugBot	42%	0.91	0.91
Greptile	24%	Higher FP rate in independent evaluations	—
Graphite Diamond	18%	0.62	—

Macroscope's 98% precision means nearly every comment identifies a real, actionable issue. For a monorepo team shipping 50 PRs a day, that is roughly 125 meaningful comments, not 500 comments to triage. The signal-to-noise ratio is the reason teams at scale prefer high-precision tools.

CodeRabbit's 10.84 comments per PR includes style suggestions, documentation nudges, and nitpicks alongside bug reports. For a small team this can be useful context. For a large team at monorepo scale, this is noise that teams eventually learn to ignore — at which point the real bugs get ignored too.

Spend Controls for Multi-Team Monorepos

Usage-based pricing becomes a monorepo feature, not just a billing detail, when you have many teams sharing one repository. Macroscope's spend controls let you cap:

• Monthly workspace limit — hard ceiling on total review spend across the entire repository
• Per-review cap — default $10, prevents a single review from spiraling on a huge PR
• Per-PR cap — default $50, caps the total cost of reviewing a single pull request across all its commits and retries

For a monorepo, per-review and per-PR caps matter because monorepo PRs can be large. A schema migration PR might touch 200 files across 20 services. Without a per-PR cap, that single review could cost hundreds of dollars. With the default $50 cap, Macroscope reviews as much as it can within the budget and flags that the cap was hit — the team decides whether to raise it for that PR or accept the partial coverage.

This is a different cost model than seat-based pricing. With CodeRabbit at $24-30 per seat, a 50-engineer monorepo team pays $1,200-$1,500 per month regardless of how much reviewing actually happens. With Macroscope's $0.05 per KB, the same team typically pays less because most PRs are small and only a fraction of the engineering team opens PRs on any given day. Teams shipping a lot of PRs pay more; teams shipping fewer PRs pay less. The cost aligns with the value delivered.

For teams considering a CodeRabbit alternative specifically because of monorepo scale, usage-based pricing is often the reason.

Integrations that Matter in a Monorepo

At monorepo scale, integrations become coordination primitives:

• Slack deep integration. Macroscope can post review summaries to team-specific channels, route Agent questions to the right surface, and broadcast digests. When a backend team owns 80 services, routing matters.
• Jira and Linear ticket context. Macroscope pulls ticket context into every review, so the reviewer knows what the PR is trying to accomplish before reading the code. Greptile currently supports only Jira (via MCP). CodeRabbit supports both.
• Agent connectors. Macroscope's Agent connects to Jira, Linear, PostHog, Sentry, LaunchDarkly, BigQuery, and more. For a monorepo team debugging a production issue across multiple services, having one assistant that can pull telemetry, query the database, and open a fix PR is the difference between a 30-minute investigation and a two-day one.
• Auto-approval. Approvability auto-approves low-risk PRs (docs, tests, code behind feature flags, simple bug fixes). In a monorepo shipping 50 PRs a day, this frees reviewers to focus on the 20% of PRs that need real scrutiny.

How Macroscope Handles Common Monorepo Scenarios

Scenario: A shared protobuf file changes. Macroscope's codewalker parses the .proto file, finds every generated consumer across Go and TypeScript services, and evaluates whether each consumer would still compile and function correctly. If the wire format changed in a backward-incompatible way, Macroscope flags it on the PR along with the specific consumers that would break.

Scenario: A new team adopts Macroscope in their package. The team adds .macroscope/team-x-review.md scoped to their paths. Their reviewer runs on their PRs. The rest of the monorepo is unaffected. No central config change required.

Scenario: A developer opens a PR that touches both frontend and backend. Each Check Run Agent scoped to its paths runs on the relevant files. The frontend agent comments on frontend files, the backend agent on backend files. The default correctness reviewer runs across the entire diff. All comments post to the same PR, organized by check run.

Scenario: A migration needs temporary enforcement. The infra team adds .macroscope/migration-v7-review.md with a prompt like "Flag any direct database writes to the orders table outside the new sharding layer." The file stays in the repo until the migration completes, then gets deleted. No deploy required — the next PR picks up the new rule automatically.

Macroscope vs CodeRabbit vs Greptile for Monorepos: Which AI Code Reviewer Wins?

For GitHub monorepos, Macroscope wins on detection, precision, and per-team rule ownership. For GitLab or multi-platform monorepos, CodeRabbit is the best option. Greptile is the right choice only when self-hosted GitLab deployment is a hard requirement.

The right answer depends on your constraints:

Choose Macroscope if:

• Your monorepo spans multiple languages and you need AST-level analysis for each
• Cross-file bug detection matters (it almost always does in monorepos)
• You need per-team custom rules scoped to specific paths
• Precision matters more than comment volume
• You prefer usage-based pricing that scales with actual review activity
• You use GitHub

Choose CodeRabbit if:

• Your monorepo includes GitLab, Bitbucket, or Azure DevOps repos
• You want one central .coderabbit.yaml over many scoped markdown files
• You prefer flat per-seat pricing regardless of review volume
• Your team tolerates higher comment volume (10+ per PR on average)

Choose Greptile if:

• You specifically need GitLab self-hosting
• Agentic exploratory search is more valuable than AST structural analysis for your codebase

Getting Started with Macroscope on a Monorepo

Installation on a monorepo is the same as any other repository. Macroscope installs as a GitHub App, begins reviewing PRs within minutes, and requires no configuration to get value. Teams add .macroscope/ agents over time as they identify rules worth codifying.

A typical rollout for a monorepo:

1. Install the GitHub App. First reviews ship within one PR cycle.
2. Let correctness reviews run as-is for a week. Measure the signal. Calibrate expectations.
3. Add the first Check Run Agent for the highest-stakes area (often a security or migration rule).
4. Expand to per-team agents once the pattern is validated. Each team owns their own file.
5. Turn on Approvability to auto-approve low-risk PRs and free reviewer time.
6. Configure spend limits for budget predictability at scale.

The GitHub setup guide walks through the first 5 minutes in detail.

Frequently Asked Questions

What is the best AI code review tool for monorepos?

The best AI code review tool for a monorepo is the one that combines multi-language AST analysis, cross-file bug detection, path-scoped custom rules, and high precision. In the published 118-bug benchmark, Macroscope had the highest detection rate (48%) and precision (98%) across 8 languages. For teams on GitLab or Bitbucket, CodeRabbit is the next-strongest option at 46% detection with broader platform coverage.

How does AI code review work in a monorepo with multiple languages?

An AI code review tool for a monorepo needs language-specific parsers for each language it claims to support. Macroscope ships dedicated AST codewalkers for eight languages: Go, TypeScript/JavaScript, Python, Java, Kotlin, Swift, Rust, and Ruby. Each codewalker builds a reference graph showing how functions, types, and variables relate across files. When a PR changes code in one of these languages, the review tool traces dependents — including across language boundaries, via generated code and shared protocol definitions. Other languages (Vue.js, Elixir, PHP, C#, C++) fall back to diff-based LLM analysis without the AST reference graph.

Can I have different review rules for different directories in a monorepo?

Yes. Macroscope's Check Run Agents are markdown files in the .macroscope/ directory with YAML front-matter supporting include and exclude glob patterns. A frontend agent can be scoped to apps/web/**, a backend agent to services/**, a migration agent to schema/**. Each team owns their own file and their own rules.

How does AI code review detect bugs that span multiple files or services?

AST-based review tools build a reference graph of the entire repository. When a function signature changes, the tool traces every caller, every dependent, and every type constraint across the codebase. If a caller in another service would receive an argument it does not expect, the tool flags it on the PR, even if that file is not in the diff. This is why cross-file detection rates differ sharply between AST-based tools (Macroscope) and diff-only tools.

Does Macroscope work on monorepos with generated code?

Yes. Macroscope parses both hand-written and generated source code. For protobuf-driven monorepos, Macroscope analyzes the .proto file, the generated Go/TypeScript/Python code, and the hand-written consumers together. A change to a protobuf definition is traced all the way to the consumers that would be affected.

Can I scope a Check Run Agent to just one service in my monorepo?

Yes. Use the include glob pattern in the agent's front-matter to scope it to services/your-service/**. The agent will only run on PRs that touch that path, and will only comment on files within that scope. Multiple agents can run in parallel with different scopes.

How does CodeRabbit compare for monorepo code review?

CodeRabbit supports monorepos with .coderabbit.yaml path-based configuration and per-path review instructions. Detection rate in the 118-bug benchmark was 46% (2 points behind Macroscope) with an average of 10.84 comments per PR (vs Macroscope's 2.55). CodeRabbit's biggest monorepo advantages are GitLab, Azure DevOps, and Bitbucket support. Macroscope is GitHub-only. Teams evaluating a CodeRabbit alternative for monorepo use often cite precision and per-team rule ownership as the reasons they switch.

How does Greptile compare for monorepo code review?

Greptile supports GitHub and GitLab and indexes the repository's call graph at the function level. Detection rate in the 118-bug benchmark was 24% (half of Macroscope's 48%). Greptile's agentic search can follow nested function calls, but it does not offer the same level of declarative path-scoping as Macroscope's Check Run Agents or CodeRabbit's .coderabbit.yaml. Greptile's main advantage over both is self-hosted GitLab deployment.

What does AI code review cost for a large monorepo team?

Macroscope charges $0.05 per KB reviewed with per-review ($10), per-PR ($50), and monthly workspace caps for spend predictability. Historical average is $0.95 per review. For a 50-engineer team shipping 500 PRs per month, that is approximately $475 per month. CodeRabbit charges $24-30 per seat per month — the same team would pay $1,200-$1,500. Greptile charges $30 per seat plus $1 per overage review beyond 50. Usage-based pricing typically favors larger teams with higher PR volume per engineer.

Can I use AI code review only on certain parts of my monorepo?

Yes. In Macroscope, configure Check Run Agents with scoped include patterns so they only run on specific paths. You can also configure the main correctness reviewer to skip certain paths via workspace settings. Teams often start with review enabled for the highest-stakes directories and expand coverage incrementally.

Does AI code review work for small teams in a monorepo alongside large teams?

Yes. This is one of the advantages of per-directory custom rules. Each team adds their own .macroscope/ file scoped to their paths. A small team with simple needs might add one agent. A large team might add five. Neither team's rules affect the other. Each team pays only for reviews on PRs that touch their code (in a usage-based model).

How does GitHub code review for a monorepo differ from GitHub code review for a single repo?

The core workflow is the same — a GitHub App reviews PRs automatically. The difference is in how the tool handles scale, multi-language analysis, and per-team customization. For a GitHub monorepo, look specifically for multi-language AST support, path-scoped custom rules, cross-file bug detection, and precision (not just detection rate). The GitHub PR review tool that handles these best for large monorepos is Macroscope, based on the 118-bug benchmark.

What is the best CodeRabbit alternative for a monorepo?

The best CodeRabbit alternative for a monorepo is Macroscope if your team is on GitHub. Macroscope has higher bug detection (48% vs 46%), substantially higher precision (2.55 comments/PR at 98% precision vs 10.84 comments/PR at 43% precision), and usage-based pricing that scales with review activity rather than seat count. For a 50-engineer team, this typically means paying 3-5x less while getting more actionable comments. Teams on GitLab, Azure DevOps, or Bitbucket should stay with CodeRabbit — Macroscope is GitHub-only.

What is the best Greptile alternative for a monorepo?

The best Greptile alternative for a monorepo depends on your platform. On GitHub, Macroscope has 2x the detection rate (48% vs 24%), AST-based structural analysis instead of agentic search, and deterministic path-scoped custom rules instead of learned patterns. On GitLab, CodeRabbit matches or exceeds Greptile's detection rate with broader platform coverage. Greptile's remaining advantages are GitLab self-hosting and its agentic exploratory search — choose Greptile only if those are specific requirements.

Can AI code review catch bugs that span multiple services in a monorepo?

Yes — this is where AST-based ai code review tools separate themselves from diff-only tools. When a pull request changes a shared protobuf file, a gRPC interface, or a function signature in a common package, Macroscope traces every caller across every service in the repository. If a caller would break after the change, Macroscope flags it on the PR even when the file with the broken caller is not part of the diff. Diff-only tools see the change in isolation and miss the downstream breakage.

Does Macroscope support automated code review for Bazel monorepos?

Macroscope supports Bazel monorepos at the code level — the AST codewalkers for Go, Java, Kotlin, Python, TypeScript/JavaScript, Rust, and Swift all work regardless of whether the repository uses Bazel, Buck, Nx, Turborepo, Rush, or plain language-specific build tools. Bazel's BUILD and .bzl files (Starlark) are recognized but reviewed via diff-based LLM analysis rather than the AST codewalker path.

Is there a free AI code review tool for small monorepos?

Macroscope offers $100 in free credits for new workspaces — enough to cover approximately 100 reviews at the historical average of $0.95 per review. CodeRabbit has a free tier with unlimited public and private repos for PR summarization. Greptile does not have a free tier. For a small team evaluating automated code review tools on a monorepo, starting with Macroscope's free credits is the fastest way to get benchmark data on real PRs before committing to a paid plan.

How does AI code review handle generated code in a monorepo?

Macroscope's codewalkers parse both hand-written and generated source code. For protobuf-driven monorepos, this means Macroscope analyzes the .proto file, the generated Go/TypeScript/Python/Java code, and the hand-written consumers together. A change to a protobuf definition is traced all the way to the consumers that would be affected. Teams often exclude the **/*.pb.go or **/*_pb2.py paths from custom Check Run Agents (via the exclude glob) to avoid running rules against machine-generated code, while letting the default correctness review still check it for structural consistency.

Can I run AI code review on a specific subdirectory before rolling it out across the entire monorepo?

Yes. Configure Macroscope workspace settings to scope the default correctness review to specific paths, and/or add a single Check Run Agent with an include glob pointing at the rollout directory. This is the recommended rollout pattern for large monorepos: start with the highest-stakes service, validate signal quality for a week, then expand. The same approach works for testing the ai code reviewer on a single directory before committing to full coverage.