Summary (Overview)

• CodeNib is a multi-view data system that materializes and maintains lexical, dense, and structural views of code repositories per commit, and serves them to coding agents through a unified runtime with explicit cost visibility.
• The system addresses three challenges: heterogeneous views (different layouts for different data types), incremental freshness (view-specific update paths), and agent delivery (bounded context with reusable state).
• Key quantitative results: Graph and vector updates that match independent rebuilds achieve 8.67× and 25.44× median speedups respectively. Static navigation reproduces live LSP normalized path/start-line sets on 63.2% of 1,000 requests with a 4.72× median live/static latency ratio on the matching subset.
• Context delivery policies (eager injection and one-time compaction) preserve localization quality (AnswerRecall@5 within 0.05 margin) while using 50–87% fewer trajectory tokens than paired grep/read across five models.
• The evaluation preserves operation-specific metrics (recall, match rates, update fidelity, latency, token usage) rather than collapsing them into a single score, providing a Pareto frontier analysis across the repository-context lifecycle.

Introduction and Theoretical Foundation

Coding agents repeatedly search, navigate, and retain context from evolving repositories. Existing approaches use disconnected indexes, language servers, and task-local histories, forcing repeated discovery and obscuring lifecycle costs. The paper takes a data-systems view: a commit is immutable base data; chunks, embeddings, postings, and relationships are derived views; agent requests are view-specific queries; and prompt context is a bounded delivery result.

Three coupled challenges are identified:

• C1: Heterogeneous views – Lexical, dense, and structural data need different physical layouts, but their results must map to the same commit and repository-relative source ranges.
• C2: Incremental freshness – An edit changes each view differently, requiring separate update paths and evaluation.
• C3: Agent delivery – Precomputed evidence must reach the model through tools or bounded context while build, runtime loading, query, and history costs remain visible.

The paper builds on foundations from materialized views, code intelligence (LSIF, SCIP, Glean, Sourcegraph, Zoekt), repository retrieval (RepoCoder, CoRet, etc.), and agent interfaces (MCP, ReAct). It distinguishes itself by explicitly maintaining separate validity boundaries for each view and measuring quality–cost tradeoffs at each lifecycle stage.

Methodology

Repository View Compiler (C1): Builds lexical (BM25, Zoekt), dense (FAISS embeddings), and structural (symbol graph with containment/reference edges) views independently per commit. Each view is linked via a Manifest ( M_c = \langle c, V^{lex}_c, V^{dense}_c, G_c, K_c \rangle ) that records profiles, status, and capabilities. All outputs are mapped to repository-relative source ranges:

[ u = \langle p, r_s, r_e, \ell, \tau, x, s \rangle ]

where ( p ) is a path, ([r_s, r_e]) a source range, ( \ell \in {L0, L1, L2} ) granularity, ( \tau ) node type, ( x ) source text, and ( s ) optional resolved symbol.

Incremental Maintenance (C2): Two update paths are evaluated:

• Graph repair: Uses Git diff and LSP calls to classify symbols as deleted, affected, shifted, unchanged, or added. Two strategies: file-level (delete and reconnect entire changed-file subgraph) and symbol-level (preserve stable facts, repair only invalidated state).
• Vector reuse: Uses content-addressed embeddings; only new/changed vectors are embedded, unchanged vectors are reused. FAISS is mutated or rebuilt according to a delta threshold.

The offline output comparison determines whether the incremental update matches an independent rebuild:

[ F(\hat{G}{c'}) = F(G{c'}) \quad \text{(1)} ] [ \forall a \in A_D : R_{\hat{G}{c'}}(a) = R{G_{c'}}(a) \quad \text{(2)} ]

Only transitions that pass these checks contribute to the reported speedup.

Agent Runtime (C3): The runtime loads required views at session startup (never builds online), exposes ranked retrieval and symbol navigation tools, and applies context policies:

• Grep/read: No preloaded candidates.
• Eager: Injects frozen top-10 ( L_2 ) code blocks into initial history.
• Compact: Same as Eager, but after the first successful read, rewrites history once:

[ H_j = [s, q \parallel C^{ctx}{10}, e{1:j}] \longrightarrow \hat{H}_j = [s, q \parallel d_j] \quad \text{(4)} ]

trajectory tokens.

Maintenance Speedup (Eq. 3):

[ \Gamma^{G,a} = \frac{T^G_f}{T^{G,a}_u + T^{G,a}s / n{\text{share}}}, \quad \Gamma^{V} = \frac{T^V_f}{T^V_u} ]

Context Delivery Quality Threshold: Policy preserves quality if:

[ \text{LB}_{95}[\Delta \text{AR@5}(\pi)] \geq -\epsilon, \quad \epsilon = 0.05 ]

Empirical Validation / Results

Q1: Retrieval-plan tradeoffs – Figure 6 shows Pareto frontiers: dense recall ranges from 0.705–0.820 (file) and 0.422–0.638 (symbol) at ( k=10 ). Reranking adds 4.6 points file recall (Jina + 4B reranker) but at 46.6× latency. Graph expansion (Figure 7a) shows no statistically significant gain across five embeddings.

Q2: Index construction and search – Figure 8: median build times range 3.8–285 s (L0/L2). ANN ablation (Figure 7b–c): HNSW (ef=16) achieves 0.977 Neighbor Recall@10, 33.9× FAISS search speedup (0.91 → 0.027 ms); IVF (25% probes) achieves 0.965 at 4.1×. Both preserve patch-target-file recall.

Q3: Static vs. live symbol navigation – Figure 9: 63.2% of normalized path/start-line sets match (87.4% definitions, 39.0% references). On matching requests, median static latency 0.62 ms vs live 2.26 ms (4.72× ratio). Match rates vary by language (e.g., Go definitions 99%, C/C++ references 22%).

Q4: Incremental maintenance – Figure 10a: Graph symbol repair matches on 15/33 transitions (median 8.67× speedup); file replacement matches on 14/33 (median 1.95×). Vector maintenance matches on 28/31 transitions (median 25.44× speedup). Rust and TS/JS graph updates fail offline checks.

Lifecycle costs – Figure 10b: median materialization 116.7 s, load 7.40 s, serve 0.727 s. Projections (Figure 10c): at 20 sessions, process-isolated 13.20 s/session, shared-resident 6.24 s/session.

Q5: Context delivery – Figure 11: Selected policies use 50–87% fewer trajectory tokens than grep/read (e.g., Gemma 12.9%, Qwen-27B 44.8%). All models meet the (\Delta \text{AR@5} \geq -0.05) margin. Compact is not uniformly better than Eager (e.g., Haiku uses 123.3% of Eager tokens).

Theoretical and Practical Implications

• Cost-visible system design: The paper demonstrates that separable views with explicit validity boundaries enable precise measurement of quality–cost tradeoffs. This contrasts with monolithic retrieval or context approaches that conflate different operations.
• Incremental maintenance is viable but not universal: Vector reuse matches independent rebuilds at high rate (90.3%) with large speedups; graph repair is more fragile (45.5%) and language-dependent. This implies that view-specific update strategies are necessary, and offline validation is critical before deploying fast paths.
• Static navigation is a conditional accelerator: Static index can serve most definition requests (87.4%) with 4.7× lower latency, but reference accuracy is low (39.0%). The system should retain live LSP as a fallback rather than replacing it entirely.
• Context delivery policies can dramatically reduce tokens: Preloading a small set of ranked candidates plus one-time compaction cuts token usage by 50–87% without sacrificing localization quality. This is achieved without learned compression or summarization.
• Lifecycle costs matter: Build time dominates (116.7 s), but amortized over many sessions, per-session cost drops to 1.27 s (shared resident at 100 sessions). This supports prebuilt, reusable views over per-task index construction.

Conclusion

CodeNib introduces a multi-view data system for serving repository context to coding agents. The repository view compiler (C1) independently materializes lexical, dense, and structural views per commit, mapping all outputs to repository-relative source ranges. View-specific incremental maintenance (C2) achieves 8.67× (graph) and 25.44× (vector) median speedups on transitions that match independent rebuilds, with offline validation ensuring fidelity. The cost-visible agent runtime (C3) serves ranked plans, static/live navigation, and bounded context policies: compatible static requests have 4.72× lower median latency than live LSP, and selected context policies preserve localization quality with 50–87% fewer trajectory tokens.

The evaluation across five questions (retrieval, index construction, navigation, maintenance, context delivery) keeps quality, compatibility, update fidelity, latency, and token usage distinct. Together, these results frame repository context as a measurable serving problem, with explicit, operation-specific validity boundaries. Future directions include concurrent heterogeneous repositories, post-training from traces, and resource-efficient scheduling across CPU/GPU workloads.