💬 NLP

Retrieval-Augmented Code Generation: A Survey with Focus on Repository-Level Approaches

This survey provides a comprehensive review of Retrieval-Augmented Code Generation (RACG) with a specific focus on repository-level approaches, offering a unified analytical framework to examine retrieval strategies, autonomous agents, and key challenges in enabling large language models to generate coherent code across entire software repositories.

Original authors: Yicheng Tao, Yuante Li, Yao Qin, Yepang Liu

Published 2026-05-21

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Yicheng Tao, Yuante Li, Yao Qin, Yepang Liu

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

The Big Picture: From Writing a Sentence to Building a City

Imagine you are a master architect.

Old Code Generation (Function Level): This is like being asked to write a single, perfect sentence for a novel. You just need to know the grammar and the immediate story.
Repository-Level Code Generation (RLCG): This is like being asked to redesign an entire city. You can't just look at one street; you have to understand how the subway connects to the power grid, how the new park affects traffic in a different district, and how the water pipes run under the old library.

The paper argues that while AI is great at writing single sentences (code functions), it struggles with the "city" (the whole software project) because real software is messy, huge, and full of hidden connections between different files.

The Solution: The "Super Librarian" (RACG)

To help the AI architect build the city, the paper introduces a concept called Retrieval-Augmented Code Generation (RACG).

Think of the AI not as a genius who memorized every book in the world, but as a brilliant student who needs to use a library.

The Problem: If you ask the student to fix a leak in the plumbing, they might guess wrong because they don't know where the pipes are.
The Solution (RAG): Before the student writes the fix, they go to the library, find the blueprints for this specific building, and read the relevant pages. Then, they use that fresh information to write the code.

The paper says this isn't just a one-time trip to the library. It's a dynamic process where the student keeps checking the blueprints, asking new questions, and adjusting their plan as they work.

The Two Main Ways to Organize the Library

The survey categorizes how these "Super Librarians" find information into two main styles:

1. The "Flat Pile" Approach (Non-Graph-Based)

Imagine the library has a giant pile of books. To find what you need, you search for keywords (like "pipe" or "leak").

How it works: The AI looks for words that match the problem.
The Catch: It might find a book about "pipes" in a plumbing manual, but miss the fact that in this specific building, the pipes are made of a weird material mentioned in a different file. It's good for simple searches but can miss deep connections.

2. The "Map" Approach (Graph-Based)

Imagine the library has a giant, 3D map of the city. The books aren't just piled up; they are connected by strings.

How it works: The AI sees that "File A" is connected to "File B" because one calls the other. It follows the strings (like a subway map) to find exactly where the problem is.
The Catch: Building this map takes a lot of time and effort. If the city changes (new code is added), the map has to be redrawn. Also, different cities (programming languages) need different map styles.

The Evolution: From Robot to Detective

The paper tracks how these systems have gotten smarter, moving through three "Levels of Autonomy":

Level 0: The Static Robot. The robot gets a question, looks up one answer, and writes code. It never changes its mind, even if it makes a mistake.
Level 1: The Self-Correcting Student. The student writes a draft, checks it, realizes it's wrong, looks up more info, and tries again. It's a loop of "Try -> Check -> Fix."
Level 2: The Detective Agent. This is the full detective. The agent doesn't just wait for a question. It walks around the city (the code repository), opens doors, checks the basement, talks to the "tools" (like a terminal or a compiler), and decides for itself what to look at next. It plans its own investigation.

The Toolkit: What Do They Use?

The paper also looks at the tools these systems use:

The Databases: They don't just use the code files. They also use bug reports, user comments, and even how developers have fixed similar problems in the past.
The Brains (Models): They use different "minds" for the job. Some are small and fast (good for simple tasks), while others are massive and expensive (good for complex reasoning). Interestingly, the paper notes that many researchers still use smaller, open-source models because they are cheaper to run, even though the big "proprietary" models (like the ones from OpenAI or Google) are very powerful.

The Big Questions and Challenges

The paper ends by asking some tough questions:

Is the Librarian Necessary? If the AI student has a memory big enough to hold the entire city in their head (a "Long-Context" model), do they still need the librarian? The paper says: Yes, but it depends. For a small house, you might not need a librarian. But for a massive metropolis, the librarian is still faster and more efficient than trying to memorize everything.
Safety: If the library is poisoned with fake blueprints, the AI might build a dangerous building. The paper warns that hackers could trick the system into retrieving bad code.
The "Real World" Gap: Most tests are done on small, perfect examples. The paper argues we need to test these systems on messy, real-world projects that change every day, just like real software does.

Summary

In short, this paper is a map of how AI is learning to build software not just by guessing, but by reading the whole project, understanding the connections, and acting like a detective to solve problems. It moves us from "AI that writes a line of code" to "AI that can navigate and fix a whole software company's codebase."

Technical Summary: Retrieval-Augmented Code Generation: A Survey with Focus on Repository-Level Approaches

1. Problem Statement

The paper addresses the limitations of current Large Language Model (LLM) based code generation when applied to real-world software engineering. While existing approaches perform well at the function or file level, they struggle with Repository-Level Code Generation (RLCG). RLCG requires models to reason over entire codebases, handling:

Long-range dependencies: Critical information distributed across files and documents.
Cross-file consistency: Ensuring changes in one file do not break distant modules.
Evolving environments: Adapting to dynamic execution states and global semantic consistency.

The authors argue that simple "retrieve-then-generate" pipelines are insufficient for these complex scenarios. Instead, they posit that Retrieval-Augmented Code Generation (RACG) in repository-level settings must be viewed as a coupled, evolving process involving context construction, retrieval optimization, generation, and environment interaction.

2. Methodology

The authors conducted a systematic literature review following established software engineering guidelines.

Data Collection: They searched leading AI and software engineering venues (ICLR, NeurIPS, ICSE, FSE, etc.) and arXiv from January 2023 to March 2026.
Selection Criteria: Papers were included if they involved retrieval-augmented, cross-file, or repository-level code generation with methodological contributions. Purely static analysis or non-generative retrieval tasks were excluded.
Corpus: After rigorous screening and snowballing, a final corpus of 152 papers was retained.
Analytical Framework: The survey organizes these works through three coupled dimensions:
1. Retrieval Substrate: How context is represented and retrieved (e.g., flat text vs. graphs).
2. Control Regime: When and how often retrieval is invoked (e.g., static pipelines vs. autonomous agents).
3. Evaluation Setting: The tasks and benchmarks used to reflect real-world demands.

3. Key Contributions and Findings

A. Unified Problem Formulation

The paper explicitly defines RLCG as a task requiring the generation of modifications ( $\Delta R$ ) to a repository ( $R$ ) that satisfy both local correctness and global consistency. It distinguishes this from isolated code completion.

B. Taxonomy of RACG Strategies

The survey categorizes methods into two primary paradigms:

1. Non-Graph-based RACG:

Treats repositories as flat text collections.
Content Construction: Focuses on query reformulation (multi-perspective views), context structuring (hierarchical chunking, AST-based partitioning), and knowledge base expansion (API integration).
Strategy Optimization: Includes foundational hybrid retrieval (BM25 + dense embeddings), adaptive retrieval (policy learning, iterative refinement), and scalable context selection (pruning, Shapley values).
Emerging Trends: Integration of static analysis (types, dependencies) and command-driven retrieval (agents using terminal commands like grep).

2. Graph-based RACG:

Represents code as graphs ( $G=(V, E)$ ) where nodes are entities (files, classes, functions) and edges represent relationships (imports, calls, data flow).
Construction: Uses parsers (e.g., Tree-sitter) to build Abstract Syntax Trees (ASTs) and call graphs.
Retrieval: Involves expansion strategies (k-NN, BFS/DFS, Monte Carlo Tree Search) and traversal over the graph structure.
Design Patterns: Includes foundational graph structures (Module-Class-Function), program dependence modeling (control/data flow), and multi-level graph integration (combining coarse and fine-grained views).

C. System Enhancements and Workflows

Training-Driven Optimizations: The paper highlights that training is crucial for aligning retrievers and generators. Techniques include contrastive learning for retrieval, supervised fine-tuning (SFT) with augmented inputs, and Reinforcement Learning (RL) to bridge retrieval and generation objectives.
Autonomous Agent Architectures: The authors propose a three-tier classification:
- Level 0 (Non-agent): Static, one-shot pipelines (e.g., Agentless).
- Level 1 (Partial Agent): Systems with iterative feedback loops (e.g., self-guided iteration, environment-driven feedback) but no full autonomous planning.
- Level 2 (Fully Autonomous): Goal-directed agents with planning, tool usage, and multi-step reasoning (e.g., SWE-agent, OpenHands).

D. Benchmarks and Configurations

Benchmarks: The survey reviews downstream tasks like cross-file code completion and GitHub issue resolution. It distinguishes between RLCG-direct benchmarks (e.g., SWE-bench, RepoBench, CrossCodeEval) designed for repository-level tasks and General-purpose benchmarks (e.g., HumanEval, MBPP) which serve as auxiliary evidence.
Configurations: The paper notes a strong bias toward Python in current research. It summarizes backbone models, noting a trade-off where small open-source models and proprietary models are frequently used, while large open-source models (>10B) are less common due to resource constraints.

4. Discussion and Future Directions

The paper identifies critical gaps and boundaries:

Security and Reliability: RACG introduces new attack surfaces, including knowledge base poisoning and LLM-Denial-of-Service via verbose code generation.
Necessity Boundary (RAG vs. Long-Context LLMs): The authors argue that RAG is not universally superior. Long-context models may suffice for small, well-structured repositories, while RAG becomes essential for large, complex, or evolving codebases. The optimal approach likely involves a combination of retrieval, model capacity, and fine-tuning.
Limitations: Current systems face challenges in scalability, the high cost of graph construction, and a lack of realistic evaluation settings that account for repository evolution and collaborative workflows.

5. Significance

The paper claims to be the first survey to systematically examine Retrieval-Augmented Code Generation specifically through the lens of repository-level approaches. Its significance lies in:

Reframing RAG: Moving the paradigm from a static pipeline to a dynamic, coupled process involving agents and iterative refinement.
Structured Understanding: Providing a unified analytical framework (substrate, control, evaluation) to organize a rapidly evolving field.
Identifying Future Directions: Highlighting the shift toward agentic software engineering, the need for cross-language support, and the critical importance of defining the boundary between retrieval and long-context modeling for practical deployment.

The authors aim to provide a structured foundation for future research to bridge the gap between academic code generation advances and practical, AI-powered software engineering systems.