Code Indexing in Practice in the Age of AI Coding
Have you ever been in this situation: you painstakingly track down a bug, only to find the project has tens of thousands of lines of code and you have no idea where to start?
A simple “search” turns out to be more agonizing than fixing the bug itself.
It’s not your fault. The scale of modern software engineering long ago outgrew the era of “look it up by keyword.” Relying on Ctrl+F or grep alone is like hunting for items in a supermarket by reading labels only — you’re bound to miss what you really want.
Don’t worry: this article walks you through the four leaps of code-search technology in plain language. These leaps have not only changed how engineers work, but also helped everyday developers locate problems and reuse code faster.
As an engineer who has long slogged through large codebases, I’ve personally lived through the evolution of code search — from text matching to semantic understanding, structural navigation, and finally agent-assisted search. This article tries to lay out that transformation in plain English and share some experience introducing vectorized indexing and private RAG in enterprise practice, in a way that even a newcomer can follow.
01 The Evolution of Code Search
In the past, code-search technology evolved continuously from “text matching” to “semantic retrieval,” then to “graph indexing” and “agentic search.” Its trajectory can be summarized as follows.
1. The Era of Traditional Text Matching
In the traditional era, our code search relied mainly on text matching: developers typically used Ctrl+F to look for keywords in the source and find the corresponding content. The results were entirely beholden to literal matching — lacking any insight into semantics and ignoring the structural information inside the code (such as function calls and class inheritance), so relationships were lost. For instance, querying for “create user” would fail to match the keyword “create,” would not find addUser(), and — when the code lacked corresponding comments — would return almost nothing useful, an obvious limitation.
2. The Era of Semantic Retrieval: Letting Search Understand Code
The rise of large language models opened the era of semantic retrieval, in which code is turned into high-dimensional vectors (embeddings) and stored in a vector database. Through similarity search with a vector model, users can recall code snippets that are functionally or intentionally similar even when they describe their needs in natural language. For example, querying for “create user,” the LLM can understand that “create” = “add,” breaking past the keyword barrier to truly grasp the code’s semantic intent.
3. The Graph Indexing Revolution: Navigating the Code’s Web of Relationships
Recent research further introduced graph indexing, abstracting the graph relationships contained in a code repository — function-call dependencies, class inheritance, and so on — into a graph: nodes represent entities like functions, classes, and files, while edges represent relationships like calls, inheritance, and dependencies. Graph-based retrieval can answer not only “which functions call the current function” but also support structured queries across files and modules, filling the gap left by vector retrieval in understanding code topology.
4. The Era of Agentic Search: Making “Search” Itself a Form of Reasoning
There is also an IDE-embedded agent, represented by OpenAI’s Code Interpreter or ByteDance’s CodeFuse-Tree, that understands developer intent in real time through a conversational interface and proactively searches, aggregates relevant snippets across the full codebase, and even generates runnable examples. This mode fuses semantic, graph-structural, and context-aware capabilities, marking code search’s shift from “retrieval” toward “generative-assisted development.”
The Core Leap: From Text to Vectors
The evolution from text retrieval to vector retrieval rests on one core idea: embed code and natural-language queries into the same high-dimensional vector space using a deep-learning model (such as CodeBERT). Search is no longer about matching strings, but about computing the cosine similarity between the query vector and the code-snippet vector. From then on, search gains the ability to “understand,” finding things by intent rather than by the literal text — transforming the traditional way of searching.
The specific flow is as follows.
Offline index building: Use a pretrained model to encode the entire codebase, snippet by snippet, into high-dimensional vectors, building a global vector index.
Online query: After the user poses a question in natural language, the system first vectorizes the query, then computes the cosine similarity between the query vector and all code vectors in the index, recalling the few highest-similarity snippets to achieve precise matching at the semantic level.
But Challenges Follow
The effectiveness of vector retrieval is not a given. The vectorization models commonly used at first provided mostly text-to-text similarity matching, with little text-to-code similarity matching; the model’s “understanding” depends entirely on the quality of the training data.
Recent papers such as CORNSTACK and SWERANK offer some solutions — the following strategies can improve a model’s ability to capture code semantics.
Consistency filtering: Select high-quality positive samples to improve the match between a text query and its corresponding code snippet, strengthening the text–code mapping.
Hard negative mining: Find “look-alike” wrong answers and use them as negatives during training, sharpening the model’s discrimination.
Constrained by the scale and quality of training data, this direction is still in the exploratory stage, and overall results are still being iterated on.
From “Searching” to “Navigating”
On graph-index-based code retrieval, there has also been recent progress. In the old view, an LLM could only “observe” a repository coarsely through its folder structure, struggling to capture dependencies among functions, classes, and modules; inferring semantic associations from filenames alone is both inefficient and inaccurate. Recently, researchers have found you can model the entire codebase as a directed heterogeneous graph and persist it to a graph database. The core idea: a codebase is not a heap of independent text but an interconnected network, with related graph relationships such as inheritance, interface implementation, and function calls — all of which we can store in our graph database.
Representative frameworks include LocAgent and OrcaLoca.
- LocAgent: multi-hop reasoning
Provides a graph-traversal tool, TraverseGraph, that lets the LLM perform multi-hop reasoning over the code-relationship graph, exploring complex call chains in one go. - OrcaLoca: intelligent filtering
Uses the distance between nodes in the graph to dynamically prune and rank search results, keeping the LLM’s attention firmly on the most relevant code regions.
A Paradigm Shift in Search
The most striking change in code retrieval today is a paradigm shift in search: search is no longer a single, static action but a dynamic, multi-step investigation led by an LLM agent.
Old mode: the user asks a question ➡️ the system returns a list of results.
New mode (Agentic Search): the agent receives a task ➡️ plans autonomously ➡️ iteratively searches and analyzes ➡️ locates the solution.
Three Strategies for Agentic Search
Three strategies are common in agentic search today.
1. Plan-driven search (PlanSearch, CODEPLAN)
Generate a high-level plan before acting, making the search more purposeful.
2. Interactive search loops (SWE-Agent)
Run a closed loop of “search — analyze — search again,” investigating continuously.
3. Strategic search (OrcaLoca)
Use a priority queue to manage search intents, and decompose complex queries.
Code Agent Search
Taking SWE-Agent as an example, here’s how a few of its commands are used.
- The find_file command
The find_file command is dedicated to searching for a specific filename in the repository, returning at most 50 results per query to help the agent locate the needed file quickly. - The search_file and search_dir commands
The search_file and search_dir commands look for a string in file(s) within a subdirectory, likewise returning at most 50 results per query, enabling efficient text search across large numbers of files. - Summary output of search results
When searching filenames or strings, these commands output a summary of the results, giving the agent a quick overview that speeds up information retrieval and decision-making.
Summary: The Four Leaps of Code Search
Overall, the evolution of code search comprises four leaps: from the original text matching, to semantic retrieval, to graph indexing, and finally to agentic search.
① Text matching ➡️ keyword lookup
② Semantic retrieval ➡️ intent understanding
③ Graph indexing ➡️ relationship navigation
④ Agentic search ➡️ autonomous investigation and reasoning
02 LLMs and Private Codebases
An LLM possesses vast general programming knowledge — it can write poems and write code — yet it has “zero awareness” of an enterprise’s private codebase and is prone to “hallucination.” How to let a powerful LLM understand and apply a private codebase safely and accurately is the central challenge in our current use of LLMs.
Steps to semanticize a code repository
Although LLM context lengths have grown, they still can’t process an entire codebase in one pass. We can therefore adopt the following parsing flow: first, slice the code at function granularity and process each function independently; second, generate a functional description text for each function; finally, convert these explanations into vector representations and store them in the OceanBase database, laying the foundation for precise matching and retrieval downstream.
This approach achieves semantic-level understanding and rapid location of private code while keeping data secure. The demo video below shows the full interaction.
The AI-driven development-plan generation process
The overall flow of AI-driven development planning is shown in the diagram below. We first use AI to generate targeted questions based on the user’s modification needs, and let the AI autonomously search the code repository for relevant content to find answers. The AI then assesses whether the information is sufficient — if not, it continues this questioning loop; if so, it generates a detailed development plan. The user can refine the plan through dialogue.
03 The CodeRepoIndex Project
CodeRepoIndex is a project we’re experimenting with: a code-indexing conversion tool — an open-source tool that turns a code repository into a vectorized index. Its core capabilities include code parsing and indexing and providing a semantic-search interface. For users, you only need to provide the repository address and the semantic-search interface, sparing you the tedious chain of code slicing, storage, vectorization, and so on — it’s lightweight and easy to use. There are three main application scenarios today.
Application Scenarios
Searching Code in Natural Language
Enter a natural-language description and get back the most relevant code snippets.
Intelligent Q&A System
Built on RAG, it understands project details and provides accurate answers.
Code Generation and Refactoring Suggestions
Generate customized code, and analyze and suggest refactoring patterns.
04 Looking Ahead: Multimodal Indexing and a Dedicated Assistant
Future code search won’t just retrieve code; it will need to combine multimodal information — design docs, unit tests, commit records, and more — to give the LLM richer context. Improving the understanding of data flow and dependencies is also a research focus for the next generation of tools.
1. Multimodal indexing
For data sources, indexing is a crucial aspect. Going forward, we’ll look at indexing code, documents, comments, commit messages, and the like as index information, providing more comprehensive context.
2. Deep code understanding
For those working on code indexing, understanding user intent is critical, which means understanding data flow and dependencies to improve the accuracy of code search and generation.
3. A dedicated AI programming assistant
Improve usability so that everyone can have an AI programming assistant that understands their project, boosting development efficiency.
The ultimate goal is to give every developer an AI programming assistant familiar with the project’s context. It can not only answer “where is this function,” but also automatically generate patches following the team’s coding standards, offer refactoring suggestions, and even flag potential errors in real time as you code.
05 Final Thoughts
Looking back, we’ve passed through four stages: from keyword-dependent text matching, to semantic retrieval that lets the model “understand” natural language, to using graph indexing to grasp the relationships between code, and finally to agentic search that can investigate autonomously. Each step made search smarter and made it easier for everyday developers to find answers in a massive repository.
Finally, I’d like to recommend the WeChat official account “Lao Ji’s Tech Talk” run by Lao Ji, the head of OceanBase Open Source. It continuously publishes all kinds of technical content related to #Databases, #AI, and #Tech Architecture. If you’re interested, feel free to follow!
“Lao Ji’s Tech Talk” hopes not only to keep bringing you valuable technical content, but also to contribute to the open source community together with everyone. If you appreciate the OceanBase open source community, light up a little star ✨! Every Star you give is fuel for our efforts.