Why your whole codebase never reaches the model

Every few months the context window gets bigger, and the same idea comes back: stop building a retrieval layer, just send the whole repository. It is a fair question to ask, and the answer is not "the window is too small". Even when it fits, it is the wrong thing to do.

Big context is not free context

Start with the arithmetic, because it settles the question before any quality argument is needed. A product spanning five repositories is easily a few million tokens of source. Every feature request, every regeneration, every follow-up question in a chat would re-send all of it. Multiply by a team, then by a month. The cost does not scale with how much has changed — it scales with how often anyone asks anything.

Then there is what actually happens to quality. A model given a whole codebase has to do two jobs at once: find the relevant twenty files, and reason about them. The finding is done implicitly, invisibly, and you get no chance to check it. When the output misses the notification worker, you cannot tell whether the model failed to find it or failed to understand it — and those have completely different fixes.

Selection done outside the model is inspectable. You can look at the retrieved set, see the worker is missing, and fix the retrieval. Selection done inside the model is a black box you can only address by rephrasing the prompt and hoping.

What a repository index actually holds

The alternative is to do the reading once, in stages, and keep the result as structure rather than as text.

Inventory and static extraction give you the things that should never be inferred by a language model in the first place: the file tree, manifests, frameworks, entry points, and then classes, functions, routes, models, events, queues, dependencies and environment variable names. These are facts with exact boundaries. A parser gets them right every time; a model gets them right most of the time, which is worse than it sounds when the output is a list of endpoints someone is going to plan a quarter around.

Semantic summaries and embeddings cover the other half — the half where exactness is impossible. A request says "let users follow a store"; the code says MarketFollow. No symbol index bridges that. Vector search over file and module summaries does.

The graph is where multi-repo stops being multi-single-repo. Nodes for repositories, services, endpoints, entities, events, queues and screens; edges for calls, produces, consumes, reads, writes, imports. Semantic search finds the entry point; the edges pull in what that entry point implies. That is how the notification worker in a repository nobody mentioned still ends up in the retrieved set.

Commit-pinned references make the output checkable. A claim carries a file, a commit and a line range, so it can be verified now and re-verified later. Without the pin, a citation is a guess about a file that has since moved.

Each of those techniques covers a failure mode of the others. Vector search alone returns things that read similarly but do not connect. A symbol index alone cannot match product language to code. A graph alone has no idea which of its thousand nodes matters for this request. Hybrid retrieval is not a hedge; it is the only configuration where the weaknesses cancel.

What retrieval per request looks like

For a given feature request, the pipeline selects the relevant repositories, modules, routes, entities, events and tests, expands along the graph edges, and sends that — a few dozen files with their relationships made explicit — instead of five repositories of raw source.

The model then does the one thing it is genuinely better at than any pipeline: turning a structured, relevant, evidence-carrying context into prose a person can act on.

There is a strategic consequence too. When the intelligence lives in the index, the model becomes a component you can swap. Providers change, prices change, a better one appears in six months. A system built as "one enormous prompt to a specific model" has to be rebuilt each time. A system built as an index with a provider-agnostic layer on top changes one adapter.

The part that keeps being true

Bigger context windows genuinely help — they raise the ceiling on how much relevant material you can send once you have chosen it. What they do not do is remove the choosing. Sending everything is a way of declining to decide what matters, and the output reflects that: technically informed, subtly unspecific, hard to audit.

The durable asset here is not a prompt. It is the graph of what your systems are and how they connect, kept current, with every claim anchored to a commit. WeaveSpec is built on the assumption that this layer — not the model behind it — is what makes a generated cross-repo document worth reading.