RAG Indexing vs Dynamic Discovery: Two Ways AI Understands Your Code
A recent Anthropic developer session featured an interesting question: how does CodeRabbit's "planning first" approach differ from tools that use RAG-based codebase indexing for reviews? The answer reveals a fundamental architectural split in AI code review, and understanding it matters more than picking a side.
The Context Problem Every AI Reviewer Faces
Here is the core challenge. Your codebase has thousands of files, years of decisions baked into its structure, and conventions that exist nowhere in writing. When a developer opens a pull request that touches the payment module, the reviewer needs to know how that module connects to the order service, why the team chose that particular validation pattern, and what broke last time someone changed the same file.
Most AI code review tools skip all of that. They look at the diff, nothing else. The result is predictable: generic suggestions, false positives about code that follows internal conventions, and comments that miss the actual risk buried three files away.
Industry data backs this up. Teams using AI coding tools completed 21% more tasks and merged 98% more pull requests in 2025, but PR review time increased 91%. The bottleneck did not disappear. It moved from writing code to reviewing it. Early AI review tools had a ratio problem: for every real bug caught, nine false positives followed. Developers started ignoring the bot entirely.
Two architectural approaches emerged to solve this: RAG-based codebase indexing and dynamic sandbox discovery.
Dynamic Discovery: CodeRabbit's Sandbox Approach
CodeRabbit's approach, discussed in a recent Anthropic session, gives the AI access to a sandboxed environment where it can write shell scripts, explore the codebase in real time, and pull in exactly what it needs for each review. Think of it as letting the reviewer walk through the codebase themselves rather than searching a pre-built index.
The advantage is freshness. There is no sync lag between the codebase and an index. The system dynamically discovers what is relevant per PR, pruning data so context windows are not filled with information that appears related but is not. As CodeRabbit's team described it, the discovery mechanism is dynamic and leads to more targeted information specific to the thing being reviewed.
The trade-off is compute cost and latency. Running shell scripts and traversing a codebase in real time for every PR takes time and resources. The approach also depends heavily on how well the system prunes irrelevant data before feeding context to the LLM.
RAG Indexing: The Persistent Context Approach
RAG (Retrieval-Augmented Generation) takes the opposite path. Instead of discovering context on the fly, you index the entire codebase upfront using vector embeddings. When a PR comes in, the system searches this pre-built index for semantically similar code, related files, and historical patterns, then feeds that context into the review.
This is the approach Octopus Review uses. When you run octopus repo index, the CLI indexes your repository using Qdrant vector search. Every file, every function, every pattern gets embedded and stored. When a PR arrives, Octopus does not start from scratch. It already knows your codebase structure, your naming conventions, and the relationships between modules.
# Index your repository once
octopus repo index
# Every subsequent review has full codebase context
octopus review 42
The strength here is speed and depth. Reviews happen fast because the heavy lifting (indexing) happened ahead of time. The system can draw connections across the entire codebase without spending compute on real-time exploration. And because Octopus processes code in-memory only (with only embeddings persisted, never source code), the privacy trade-off is minimal.
The challenge CodeRabbit raised is valid: RAG systems can have re-ranking issues. An embedding that looks similar might not actually be relevant. Stale indexes can miss recent changes. These are real problems, but they are engineering problems with known solutions. Hybrid retrieval (combining dense vector search with keyword matching), incremental re-indexing, and learned re-rankers have pushed RAG accuracy significantly forward in 2026.
Why RAG Wins for Code Review Specifically
Both approaches work. CodeRabbit's team said it themselves: "I'm not gonna say whether one is better or worse. It depends on your particular problem." Fair enough. But code review has specific characteristics that favor persistent indexing.
First, codebases do not change that dramatically between PRs. A well-maintained index that updates incrementally is rarely out of sync in ways that matter. The "freshness" advantage of dynamic discovery is smaller than it sounds in practice.
Second, review quality depends on breadth of context, not just targeted retrieval. When Octopus reviews a PR touching your authentication module, it does not just find similar code. It pulls in your Knowledge Base documents, your team's architectural guidelines, and patterns from across the repository. You can feed it your own standards:
# Your org standards become part of every review
octopus knowledge add ./docs/auth-patterns.md --title "Authentication Standards"
That accumulated knowledge is something a dynamic discovery system rebuilds from scratch every time.
Third, RAG enables capabilities beyond review. The same index that powers PR reviews also powers RAG Chat, where you ask questions about your codebase in natural language:
# Ask anything about your codebase
octopus repo chat
> "How does the payment retry logic work across services?"
The index is not a one-trick tool. It is foundational infrastructure that gets more valuable over time.
The Real Differentiator Is Not the Architecture
Here is what matters more than RAG vs sandbox: does the tool understand your codebase or just your diff?
Most AI reviewers still operate at the diff level. They see 50 lines of changed code and make suggestions based on that alone. Whether a tool uses RAG, dynamic discovery, or any other mechanism, the critical question is whether it brings full codebase context to every review.
Octopus Review is open source, self-hostable, and indexes your entire codebase so every review carries the weight of your full project context. No vendor lock-in, no source code leaving your infrastructure if you self-host, and a Knowledge Base that lets you encode your team's standards directly into the review process.
The architectural debate between RAG and dynamic discovery will keep evolving. What will not change is the need for context-aware review in a world where AI-generated code is growing faster than human review capacity can keep up.
Try Octopus Review at octopus-review.ai or star the repo on GitHub. Join the community on Discord to share how your team handles the context problem.