---
id: "lib-2026-09-00-building-a-rag-pipeline-for-semantic-code-search"
type: "library"
title: "Building a RAG Pipeline for Semantic Code Search: A Developer Diary and Field Notes"
lang: "EN"
org: "JetBrains"
source_type: "Practitioner post"
date: "2026-09-01"
week: "2026-W41"
url: "https://nosov.ai/library/lib-2026-09-00-building-a-rag-pipeline-for-semantic-code-search/"
original_url: "https://blog.jetbrains.com/ai/2026/09/building-a-rag-pipeline-for-semantic-code-search-a-developer-diary-and-field-notes/"
tier: "B"
tier_name: "Useful, limited"
tier_reason: "Engineering field notes from a JetBrains product team with concrete design choices and repository statistics, but no published retrieval benchmarks and written to promote its own product."
summary_basis: "full-text"
original_minutes: "18"
tags: ["ai technology", "rag", "embeddings", "enablement"]
---

# Building a RAG Pipeline for Semantic Code Search: A Developer Diary and Field Notes

Tier B (Useful, limited): Engineering field notes from a JetBrains product team with concrete design choices and repository statistics, but no published retrieval benchmarks and written to promote its own product.

Summary based on the full text.

## In short

Adam Malek and Ashot Kazaryan of JetBrains describe the first stages of the retrieval pipeline behind Air Context, the company's semantic code search for coding agents. Part 1 covers how source files are split into chunks and turned into vectors. The core choices: chunk along the syntax tree rather than by line count, keep every embedding dimension but compress each to one bit, and never store customer code on the server.

## Key numbers

- 32x: storage reduction from one-bit binary vectors versus 32-bit floats
- 4,096 x 1 bit vs 128 x 32 bit: two ways to spend a 512-byte budget per vector; the first retrieves considerably better
- 1,000,000+: files in the IntelliJ IDEA monorepo, median path 91 characters, nine directories deep
- 9: languages with structure-aware chunking in Air Context

## What it reports

- Structure-aware chunking is supported for nine languages (Kotlin, Java, Python, JavaScript, TypeScript, C#, PHP, Go, Rust); everything else falls back to line-based splitting.
- The chunker resembles cAST (Zhang et al., 2025) but adds language rules: Python decorators stay with definitions, KDocs with Kotlin declarations, noise annotations such as `@NotNull` and `@Override` are removed.
- A vector of a few thousand 32-bit dimensions weighs about 16 KB; a few million chunks reach tens of gigabytes of index.
- At 512 bytes per vector, 4,096 dimensions at one bit retrieved "considerably better" in their tests than 128 dimensions at 32 bits.
- Binary quantization makes vectors 32 times smaller; comparison uses Hamming distance (XOR plus popcount over 64 words of 64 bits), roughly a hundred instructions versus thousands of multiplications for cosine.
- Cost: a few points of recall, and a compressed score range (unrelated pairs agree on about half the bits, strongly related on about two-thirds), so thresholds stop working. Where an absolute relevance cutoff is needed they keep 16-bit floats.
- The IntelliJ IDEA monorepo has over a million files; close to 10,000 paths exceed 150 characters, the longest 218. Paths are abbreviated in the middle before embedding.
- The GPU saturates at about 32 chunks per batch during indexing.
- The server stores only coordinates (path, byte offsets, vector reference), no code; embeddings run on an open-weight model on JetBrains-operated GPUs, which beat hosted embedding APIs on their internal benchmarks.

## How they got it

A practitioner write-up from building and shipping the system. Chunk quality is checked with an LLM-as-a-judge that flags detached documentation, orphaned closing syntax or cut constructs, and pipeline changes go through an end-to-end retrieval evaluation that the authors promise to describe in a later part.

## Limits

- No retrieval numbers are published: the "considerably better" and "came out on top" claims have no metric, dataset or baseline attached.
- The authors build and sell the product; the post ends with a product pitch.
- Part 1 of a series; storage, latency, evaluation and agent integration are not yet covered.

## Why it matters for companies

Any company building internal search over documents or code faces the same choices: how to split content into units, what to keep in an index, and what to pay per stored item. The post shows that a retrieval system feeding an agent can accept a weaker ranking than one shown to people, because the agent reads several candidates anyway. It also gives a workable privacy pattern for sensitive material: keep only pointers on the server and assemble content on the client. Treat the quality claims as unverified until the evaluation part is published.

Original: https://blog.jetbrains.com/ai/2026/09/building-a-rag-pipeline-for-semantic-code-search-a-developer-diary-and-field-notes/