AI Code Review from 30 to 80 Points: A Complete Guide to AST + RAG Architecture Challenges

Building a basic AI code review system isn't hard—it might solve 30% of problems and boost efficiency by 30%. But pushing that number to 70% or even 80% is where the real challenges begin. This article dives deep into the core difficulties facing AI code review systems, and how to build a more powerful code review agent using AST parsing, RAG retrieval, and vector databases.

Where Basic AI Code Review Systems Fall Short

For developers familiar with LangGraph or LangChain, a simple AI code review system can be built in just two or three hours. LangChain is one of the most popular LLM application development frameworks, offering prompt templates, chain-based invocations, tool integration, memory management, and a series of other abstractions to help developers rapidly build applications powered by large models. LangGraph is an extension library from the LangChain team focused on building stateful, multi-step AI Agent workflows—based on directed graph concepts, it allows developers to define nodes (processing steps) and edges (transition conditions), supporting loops, conditional branches, and parallel execution, making it ideal for orchestrating complex execution flows involving AST parsing, RAG retrieval, multi-model collaboration, and other steps.

However, systems built this quickly have two fundamental problems:

First, insufficient long-context processing capability. When a PR contains thousands of lines of code changes, the large model's context window may not be able to fully digest all the information. While this scenario doesn't often occur in well-structured development workflows, it's still an edge case worth considering.

Second, and more critically—understanding code dependencies. A project can range from tens of thousands to hundreds of thousands, or even millions of lines of code. Reviewing only the code snippets in a PR, the AI simply cannot understand what that code truly means within the entire project. When business logic or complex call chains are involved, review without project context is almost meaningless.

This leads to the core question: How can we enable the AI model to review a PR in the context of the entire project codebase?

AST (Abstract Syntax Tree): The Foundation for Understanding Code Structure

To solve project-level code comprehension, we first need to understand AST (Abstract Syntax Tree). AST is a core concept in compiler theory—virtually all modern programming language compilers or interpreters use AST as an intermediate representation. When source code is parsed, the Lexer first splits the character stream into a sequence of tokens, then the Parser organizes these tokens into a tree structure according to the language's grammar rules. This tree omits semantically irrelevant symbols like parentheses and semicolons, retaining only the program's logical structure. For example, an assignment statement int x = a + b; is parsed into a declaration node whose child nodes contain the type, variable name, and a binary operation expression.

All programming languages are designed to be parsed based on AST—code structure and rules are abstracted into tree structures, with each node representing a grammar rule. In code review scenarios, the value of AST lies in providing a structured code representation independent of specific syntax styles, making cross-file dependency analysis, call chain tracing, and pattern matching possible. Common AST parsing tools include Python's ast module, JavaScript's Babel Parser, Java's Eclipse JDT and JavaParser, among others.

AST has one very important property: information compression. Take SQL as an example—its syntax tree is approximately a thousand lines (standard SQL, excluding dialects); regular programming languages like TypeScript and Java typically have syntax trees of around one to two thousand lines. This scale is well within the comprehension range of AI large models.

However, our purpose in using AST isn't to help AI understand syntax itself—general-purpose large models already have this capability. The real purpose is to use AST to distill and summarize the entire project codebase.

AST-Based Code Summarization Strategy

Suppose the codebase has 100,000 lines of code, 1,000 classes, and 2,000 methods—having AI process this directly is obviously unrealistic. The solution follows these steps:

1. Parse with AST to extract all classes, methods, and their comments
2. Form structured summaries and store them in a vector database
3. When a new PR arrives, parse the PR code with AST again to analyze which external classes, methods, and variables it depends on
4. Retrieve via RAG the summary information of relevant dependencies from the vector database
5. Assemble complete context and send it to the AI large model for review

This is exactly the underlying mechanism of AI coding tools like Cursor and ByteDance's Trae—they need to continuously extract and generate summaries from the entire project to provide suggestions that incorporate multi-file context.

Complete Architecture Design: Two Main Pipelines from Codebase to Intelligent Review

The entire AI code review system can be divided into two main pipelines:

PR Review Main Pipeline

Retrieve code snippets (in PR form) from the Codebase, then process through:

• AST Decomposition: Extract code reference relationships, identifying which classes and libraries are depended upon
• Retriever Search: Fetch summary information about relevant dependencies—parameters, comments, business meaning—from the vector database
• AI Large Model Analysis: Send the PR code + dependency context together to the large model for deep review

The retrieval step here employs the RAG (Retrieval-Augmented Generation) architecture. Proposed by Meta AI in 2020, RAG's core idea is to retrieve the most relevant document fragments from an external knowledge base before generating an answer, then concatenate these fragments as context into the prompt to guide the large model's reasoning based on real data. RAG's typical flow includes three stages: Indexing—slicing documents and converting them to vectors via an Embedding model for storage in a database; Retrieval—vectorizing the user query and performing similarity search; Generation—sending the retrieved context along with the original question to the LLM. In code review scenarios, RAG enables AI to dynamically access documentation and signature information for relevant classes and methods in the project when reviewing a PR, without needing to stuff the entire codebase into the context window.

Knowledge Base Construction Pipeline

This is an independent background process responsible for continuously maintaining the vector database:

1. AST Syntax Parsing: Scan project code to find all methods, classes, and comments
2. AI Agent Processing: Further process the extracted information—supplement poorly documented code with better documentation, automatically generate documentation summaries for undocumented code
3. Scheduled Synchronization: Feed processed data into the vector database via scheduled tasks

The vector database is the core storage component of the entire system. Vector databases are database systems specifically designed for storing, indexing, and approximate nearest neighbor (ANN) search of high-dimensional vectors. Unlike traditional relational databases based on exact matching, vector databases perform semantic-level fuzzy retrieval through metrics like cosine similarity and Euclidean distance. When text or code snippets are converted into high-dimensional floating-point vectors through Embedding models (such as OpenAI's text-embedding-ada-002, BGE, etc.), semantically similar content clusters together in vector space. Major vector databases include Pinecone, Weaviate, Milvus, Qdrant, and Chroma, which typically employ indexing algorithms like HNSW (Hierarchical Navigable Small World) and IVF (Inverted File Index) to accelerate retrieval, finding the most relevant dependency information for the current PR from tens of thousands of code snippets in millisecond-level time.

This mechanism can elevate the system from solving 30% of problems to solving 50%-60%.

Security Vulnerability Detection: A Clear Weakness of General-Purpose Models

In security detection, general-purpose large models can only analyze surface-level issues. For deep vulnerabilities or newly disclosed security risks, large models are virtually powerless.

Code security vulnerability detection has a long history in software engineering. Traditional tools fall into two major categories: SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing). SAST tools like SonarQube, Checkmarx, and Fortify analyze source code or bytecode without running the code to discover potential vulnerabilities, with core technologies including data flow analysis, Taint Analysis, and pattern matching. OWASP (Open Web Application Security Project) maintains a Top 10 security risk list covering common threats such as injection attacks, broken authentication, and sensitive data exposure. The CVE (Common Vulnerabilities and Exposures) database is the world's most authoritative vulnerability numbering system, with new vulnerabilities being disclosed and cataloged every day.

Traditional Approach: Risk Database + Pattern Matching

Professional security companies maintain an extensive risk database containing various hidden vulnerabilities and problematic code patterns. When new code is submitted, AST parsing performs pattern matching, comparing code structures against the risk database and flagging matches as risks.

AI-Era Approach: Proprietary Risk Models

Some companies have begun training specialized risk analysis models, feeding them large volumes of vulnerability data for more intelligent vulnerability detection. However, since new vulnerabilities are disclosed daily (platforms like Alibaba Cloud and Tencent Cloud continuously update), no model can achieve real-time coverage. In recent years, tools like GitHub's Dependabot and Snyk have also started leveraging AI for dependency vulnerability scanning and automated fix suggestions, but for zero-day vulnerabilities and complex business logic vulnerabilities, professional security teams and proprietary tools are still necessary.

Best practice is a dual approach: a continuously updated risk database + a powerful risk analysis model, working in tandem. This part typically requires commercial proprietary tools and shouldn't be included in the responsibilities of general-purpose large models.

Knowledge Updates: The Challenge of Continuous System Evolution

Knowledge updating is another thorny issue facing AI code review systems:

• New framework versions: When a project upgrades to the latest version of a framework, the AI model may be completely unaware of new features
• New language features: When programming languages release new syntax, the system can't properly identify them without knowledge base updates
• New programming paradigms: Industry best practices are constantly evolving

Strategies for Knowledge Updates

Option 1: Build an updatable knowledge graph or vector database, periodically synchronizing programming language features and framework updates. However, maintenance costs are high, and when RAG recalls too much context, it can actually become counterproductive.

Option 2: Fine-tune key knowledge into the base model. Model fine-tuning refers to further training a pre-trained large model using domain-specific datasets to give the model specialized capabilities in that domain. Common fine-tuning methods include Full Fine-tuning, LoRA (Low-Rank Adaptation), and QLoRA. LoRA injects low-rank decomposition matrices into the model's weight matrices, training only a minimal number of parameters (typically less than 1% of the original model), dramatically reducing the computational cost and memory requirements of fine-tuning. In code review scenarios, fine-tuning can encode specific framework API specifications, team coding standards, and historical review feedback directly into model parameters, allowing the model to access this knowledge during inference without additional retrieval. However, fine-tuning's limitation is inflexible knowledge updates—every time new frameworks or knowledge emerge, retraining is required, with the risk of catastrophic forgetting. Therefore, the industry typically combines RAG (for dynamic knowledge) with fine-tuning (for stable domain knowledge), and costs remain significant.

Pragmatic advice: Choose relatively stable tech stack versions for your project, avoiding the knowledge synchronization pressure that comes with frequent upgrades. Large enterprises typically don't change software versions lightly unless absolutely necessary. For edge cases that are genuinely difficult to solve, it's acceptable to ignore them and focus energy on high-frequency, high-value review scenarios.

Summary: Breaking Through AI Code Review Bottlenecks in Three Dimensions

Building an AI code review system that evolves from 30 to 80 points hinges on breakthroughs in three dimensions:

1. Project-level context understanding: Through AST + RAG + vector databases, enable AI to review code in the context of the entire codebase
2. Security vulnerability detection: Combine traditional risk databases with proprietary risk models to compensate for general-purpose models' shortcomings in security
3. Continuous knowledge updates: Establish knowledge maintenance mechanisms to keep the system aware of new technologies and frameworks

A simple version can be done in two or three hours, but truly solving the core problems requires sustained investment in RAG architecture design, AST parsing optimization, and vector database indexing strategies. Major companies like ByteDance are already using self-developed AI code review systems internally, and the value of this approach has been thoroughly validated.