CodeNib Turns Repository Context into a Reusable Data System

Introduction

Coding agents often spend a large share of their effort not on editing code, but on rediscovering where relevant information lives. They grep files, read snippets, query language servers, and carry task-local histories that are hard to reuse. As repositories evolve, the same discovery process repeats and its cost becomes difficult to see. CodeNib approaches this as a data-systems problem: build repository context once per commit, maintain it along view-specific paths, and expose it to agents as a bounded runtime service.

Core ideas

• Multiple views of the same repository: CodeNib constructs lexical, dense, and structural views for a repository commit. Lexical views support keyword-style lookup, dense views support semantic retrieval, and structural views help with symbol navigation and source relationships.
• Repository-relative source ranges: Instead of leaving every index or tool to define its own location format, CodeNib maps outputs back to repository-relative ranges. This gives agents a more consistent way to connect search hits, symbols, and code snippets.
• Incremental maintenance where appropriate: The system does not treat every repository change as a reason to rebuild everything. Across 100 snapshots, the paper studies quality-cost frontiers for the repository-context lifecycle. When outputs match an independent rebuild, median graph and vector updates are reported as 8.7× and 25.4× faster than rebuilding.
• One runtime for search, navigation, and bounded context: CodeNib serves ranked search, symbol navigation, and constrained context from the same runtime. On the static-navigation subset that matched normalized live-server locations—63% of 1,000 requests—the reported median per-request live/static latency ratio is 4.7×.
• Lower token usage during agent trajectories: Across five models, selected context policies preserve localization quality while using 50–87% fewer trajectory tokens than paired grep/read workflows.

Why it matters

The contribution is less about a single retrieval trick and more about treating code context as infrastructure. For coding agents, this could reduce repeated exploration and allow more of the budget to be spent on reasoning, planning, and making changes. It also gives system builders a clearer way to measure lifecycle costs across indexing, updating, navigation, and context serving.

The paper is careful about boundaries. The update speedups are counted only when incremental outputs match an independent rebuild, and the navigation latency comparison applies to the compatible static-navigation subset. That matters because repository context systems can fail in operation-specific ways: a vector view, graph view, and live server do not necessarily share the same validity assumptions.

If coding agents are to work over large, fast-moving codebases, systems like CodeNib may become part of the standard layer between models and repositories. They organize changing code into searchable, navigable, and budget-aware context rather than leaving every agent run to start from scratch.

Source: Hugging Face Daily Papers