Retrieval-Augmented Generation has become the default architecture for AI tools that need to reason about large codebases. The pitch is compelling: instead of trying to fit an entire codebase into a context window, you embed the code into a vector database, retrieve relevant chunks at query time, and feed those chunks to an LLM.
For many use cases, RAG works well enough. For microservices code review, it fails in ways that matter.
The Microservices Context Problem
Microservices architectures are built around bounded contexts. Each service owns its domain, exposes a well-defined interface, and communicates with other services through APIs, message queues, or events. This is great for deployment independence. It's terrible for any retrieval system that has to understand the whole picture.
When a developer submits a PR that changes how Service A calls Service B, the relevant context is distributed across at minimum two repositories. The interface contract lives in one place, the implementation in another, the consumer logic in a third, and the integration tests somewhere else entirely.
RAG systems, by design, retrieve from a single embedding space at a time. Even sophisticated multi-repo RAG setups struggle because the relationships between services aren't encoded in the embeddings — only the content of individual files is.
What Embedding-Based Retrieval Actually Captures
When you embed a function or a file, the resulting vector captures semantic similarity to other functions and files. If you query for "authentication logic," you'll retrieve code that looks like authentication logic.
But cross-service dependencies aren't a matter of semantic similarity. Whether OrderService depends on InventoryService through a specific gRPC interface is a structural fact about the system, not a semantic property of either service's code.
The consequence: when an LLM is asked to review a change to OrderService, the RAG system retrieves semantically similar code — probably other order-related functions — but misses the actual dependency on InventoryService unless that dependency happens to be in the retrieved chunks.
The Fragmentation of Cross-Service Context
In a monolith, when you change a function signature, every call site is visible in the same codebase. In a microservices architecture, changing an API endpoint in one service has implications for every consumer of that API. Those consumers live in different repositories, maintained by different teams, with their own embedding indexes.
The RAG system reviewing the producer service has no visibility into the consumers. This fragmentation means that impact analysis — one of the most valuable things a code reviewer can do — is structurally broken in RAG-based tools for microservices.
Schema and Contract Dependencies
The problem is even sharper for data schema changes. If Service A publishes an event with a certain schema and Services B, C, and D all consume it, a breaking schema change is a production incident waiting to happen.
Vector similarity retrieval has no concept of "this schema is consumed by these services." That relationship exists in the actual topology of the system, not in the semantic content of any individual file.
API contracts face the same issue. OpenAPI specs, protobuf definitions, and Avro schemas define contracts between services. RAG can't systematically check these because it doesn't have a model of the contract graph.
Event-Driven Architectures Amplify the Problem
In event-driven systems, the coupling between services is even more implicit. A producer emits an event; consumers react to it. There's no direct call in the code.
RAG retrieval based on text similarity has essentially no path to discovering these relationships. The relationship exists in the system's runtime behavior and in the schema registry, not in any file that would surface through embedding-based retrieval.
What Actually Works
The limitations of RAG for microservices code review point toward what's needed: a system that builds an explicit model of the relationships between services.
Graph-based code analysis can represent service dependencies, API contracts, and event flows as a structured graph. When a change happens, the graph can be traversed to identify all downstream effects — something retrieval-based systems fundamentally cannot do.
The right tool for microservices code review isn't a smarter retrieval system. It's a system that understands the architecture.
About CodeAnt AI
CodeAnt AI is an AI-powered code review platform built for modern software architectures. Instead of relying on RAG-based retrieval, CodeAnt uses deep code graph analysis to understand cross-service dependencies, API contracts, and the full impact of code changes.
Top comments (0)