CodeNib: A Multi View Data System for Serving Repository Context to Coding Agents
CodeNib is a multi-view data system that treats repository context as a data-systems problem: build lexical, dense, and structural views once per commit, maintain each through its own path (graph repair, vector reuse), and serve them to coding agents through ranked retrieval, static navigation, and bounded context policies. The paper reports 8.7× speedup on graph updates and 25.4× on vector updates when outputs match rebuilds, static navigation reproducing live-server paths on 63% of requests, and 50–87% fewer tokens in agent trajectories vs. grep/read. The core insight is that repository context shouldn't collapse into one abstraction—heterogeneous views need independent physical layouts, update paths, and delivery contracts, with explicit cost visibility across the agent lifecycle.
Transcript
Justy So I just read this paper on repository context for coding agents, and I'm sitting here thinking: every agent I've seen spends half its time re-discovering the same file paths.
Cody Yeah…
Justy Like, it finds a file, reads it, then three turns later it's grep-ing for the same symbol and doing the whole search again. CodeNib is basically saying: stop doing that. Build the views once, keep them fresh, and reuse them.
Cody Okay, I'm into that premise. But the paper's real move is not just reuse—it's that they're treating repository context as a data-systems problem, not a model problem. Three separate views: lexical, dense, and structural. Each one has a different physical layout, a different update path, and different costs.
Justy Right, right.
Cody So a BM25 index is cheap to maintain and good for exact-term search. An embedding store is expensive to build but fast for semantic retrieval. A graph of symbols and dependencies needs graph-repair logic when code changes. The paper says: don't collapse these into one abstraction. Keep them separate, measure each one independently, and compose them at query time.
Justy That's the thing I really liked. They're not claiming that one view is better. They're saying the three views solve different problems, and you need all three to be honest about the tradeoffs.
Cody Exactly. And here's where the systems work matters: they built a manifest—basically metadata about each view per commit. Which views are available, which are stale, what the update latency was. Then everything gets mapped back to repository-relative source ranges so the views actually align.
Justy So when an agent query comes in, CodeNib knows exactly which views to load and doesn't have to rebuild everything from scratch.
Cody Right. And the measurements are honest about where the wins actually are. Static navigation—using precomputed symbol locations instead of a live language server—reproduces the live server's paths on sixty-three percent of requests. On that subset, it's four-point-seven times faster. But on the other thirty-seven percent it doesn't match, so they don't claim a speedup. That's the integrity of the paper.
Justy That's such a good discipline. Most papers would bury that or claim a blended average.
Cody The incremental maintenance numbers are striking. When they update a graph or embedding index after a code change, they get eight-point-seven times and twenty-five-point-four times speedups compared to rebuilding from scratch. But they only report those speedups when the updated output matches an independent rebuild.
Justy So the adoption story is: teams that want this need to own the manifest maintenance and the update verification. It's not a drop-in library.
Cody Exactly. But that's also why the paper matters. It's not claiming to solve everything. It's saying: here's the data-systems decomposition, here's how to measure it, here's where the wins are real and where the tradeoffs exist. That's infrastructure thinking.
Justy And the agent teams that recognize this problem—that their agents are burning tokens on repeated discovery—they could look at this and build it. Or someone could package it as a service.
Cody That's the question for the next six months. Does someone ship a CodeNib-shaped thing as a hosted service or a library? Because the infrastructure is clearly valuable, but adoption depends on ease of integration.
Justy And whether the gains hold on real, changing codebases at scale.
Cody Right. The paper is honest about the limits, which is why I trust the wins where they claim them.
Justy This is the kind of paper that makes agent infrastructure actually usable instead of just smarter. Which, I mean, that's kind of been the pattern with us the last year or so—the win is not the model, it's the harness.
Cody Yeah.
Justy Okay, so if someone is going to build with this: the paper doesn't link to a CodeNib repository or a hosted version. The measurements are in the paper, but there's no 'go try this' artifact that I can see.
Cody Right. This is a research contribution, not a shipped product. But the design is concrete enough that a team could implement it. Build the view compiler, the manifest system, the incremental maintainers, and the agent runtime. The paper walks you through the architecture.
Justy So it's a blueprint for teams that want to own their repository-context infrastructure.
Cody Exactly. Which is probably the right move for any serious agent deployment anyway—you don't want your agent's context to be a black box.
Justy All right. So the takeaway: agents don't have to rediscover the repository every turn. Build the views once, keep them fresh, serve them through explicit policies, and measure what actually works. And if you're shipping agents, this is the kind of infrastructure that makes them cheaper and faster.
Cody And honest about the tradeoffs. That's the whole thing.