Paper Walkthrough: CodeNib — A Multi-View Data System That Serves Repository Context to Coding Agents

Coding agents grep their way through the same repository over and over. CodeNib (UC San Diego et al.) reframes this as a database problem — lexical, dense, and structural views over an immutable commit — and measures the whole lifecycle, caveats included.

CodeNib: A Multi-View Data System for Serving Repository Context to Coding Agents

Coding agents show up to their first day of work — every day

Imagine a brilliant new hire who loses their memory every night. Their skills are intact, but each morning they redraw the office map before getting anything done.

That is the daily life of a coding agent — an LLM that operates on a repository through tools like grep and file reads. Every task starts with "where is that function again?", and everything the agent learns while exploring is thrown away when the task ends. The paper describes the status quo bluntly: disconnected indexes, language servers, and task-local histories "force repeated discovery and obscure lifecycle costs" (Abstract).

CodeNib, published on 2026-07-28 by a team centered at UC San Diego, attacks this not as a machine-learning problem but as a database problem.

The reframe: a repository is a database

The paper's core move is a mapping (§1): a commit is immutable base data; chunks, postings, embeddings, symbol occurrences, and relationships are derived views; agent requests are view-specific queries; and the context that lands in a prompt is a bounded delivery result.

Databases have a classic tool for exactly this shape: the materialized view — precompute a result, pay upfront, answer queries fast, and refresh when the base data changes. A code-search index is a materialized view over a commit. From that intuition, the paper derives three coupled challenges (§1). C1: lexical, dense, and structural views need different physical layouts, yet their results must map back to the same commit and source ranges. C2: a single edit breaks each view differently, so each needs its own update path. C3: precomputed evidence must reach the model while build, load, query, and history costs stay visible.

Three views and one shared "address"

CodeNib slices source code into a hierarchy (§4.1): files are $L_0$, type-like scopes such as classes are $L_1$, and callable definitions — functions and methods — are $L_2$. Every unit carries a repository-relative path plus line range, and three views are built on top (§5):

• Lexical view: BM25 postings, optionally a Zoekt trigram index — lookup by keywords and identifiers
• Dense view: embeddings of $L_0$ or $L_2$ units stored in FAISS — lookup by semantic similarity
• Structural view: a graph of files, scopes, and definitions connected by typed edges like "contains" and "references" — go-to-definition and find-references

Dense search embeds the query into the same vector space and returns units with the largest inner product — a measure of how closely two vectors point in the same direction (for how code and prose become vectors in the first place, Embeddings from Scratch is the groundwork). You can get a feel for it here:

The views are built independently, but every result is normalized to the same address format: repository-relative path plus line range. A manifest $M_c$ acts as the catalog, recording each view's location, status, and capabilities per commit (§5.4). If the vector build fails, BM25 stays usable — per-view independence plus catalog-based discovery is the heart of the design.

The agent-facing side compresses to a few lines (condensing the paper's Listing 1):

M = compile(checkout, ["bm25", "vector", "graph"])  # build offline, record in manifest
views = load_views(M, needed)   # at runtime: open existing views, never build
runner = AgentRunner(views, M)  # exposed as search / definition / reference tools