Explainers · updated July 2026
Embeddings turn code into coordinates so an AI can search by meaning.
You've heard the words: embeddings, vector search, RAG. Underneath the jargon is one idea: turn a piece of code into a list of numbers that pins its meaning to a point in space, so similar ideas land near each other. It is how a Pinecone-style vector database and Cursor find the right function when you don't know its name. It genuinely helps. And it is approximate, it drifts as you edit, and keeping it current is a job. Here's the plain-English version, and where an exact index fits alongside it.
What an embedding actually is
A list of numbers that means something.
An embedding is what you get when a model reads a chunk of code and hands back a list of numbers (a few hundred of them) that describe its meaning. Those numbers are coordinates. Code that means similar things ends up at nearby coordinates, so “find code like this” becomes “find the nearest points.” Ask in plain English, turn your question into the same kind of coordinates, and the closest chunks come back, even if they share not one word with what you typed. That last part is the whole trick. The picture below is the fastest way to see it, next to the other way to find code: an exact index that maps a literal token straight to the files that contain it.
Left is a vector database (Pinecone, and what Cursor builds for the repo you open). Right is an exact index (what Interlinked keeps for the whole machine). They answer different questions, which is exactly why they belong in the same stack, not in a fight.
Do they help with code search?
Yes, when you don't know the words.
This is not a takedown. For one class of question, embeddings are exactly the right tool, and the products built on them are good. A vector database like Pinecone is the storage layer behind most RAG setups; Cursor embeds the repo you open so you can ask “where do we handle refunds?” and get the right file without knowing its name. Three things they genuinely nail:
Ask in plain English and get the right function even when you don't know what it's called. “Give money back” finds issueCredit() with no shared words, the whole point of embeddings.
“Explain the auth flow,” “what touches billing?” Questions with no single literal answer. Nearest-neighbour recall is built for exactly this.
Similar ideas cluster even across languages and folders, so related code surfaces together without a shared keyword to grep for.
Keep them. Nothing below asks you to give up your vector database or Cursor's index. The point is only that “search by meaning” solves the fuzzy question, and a different, very common question needs the opposite guarantee.
The honest catch
Approximate by design. Stale by default.
Nearest-neighbour is a ranking, not a guarantee. Ask “where is this exact call site?” and embeddings hand back the closest guesses: great for recall, shaky for “did I catch every one?” There is no promise the thing you meant is even in the top results.
Vectors are a snapshot of meaning. Rename a function, refactor a module, add a file, and the vectors keep pointing at the old code until you re-embed. The index quietly describes a codebase that no longer exists.
Staying fresh means recomputing embeddings: compute, latency, and cost. For cloud RAG and Cursor, that also means your code leaves the machine to be turned into vectors. It's a pipeline you run and pay for, not a free property.
None of this makes embeddings bad. It makes them a fuzzy-recall tool with a maintenance cost. The trouble starts when an agent needs the opposite: the exact string, the current bytes, the symbol that changed thirty seconds ago, everywhere on the machine. That is not a meaning question. It is a lookup.
The exact lane · Ryzen 9 9950X3D · 4.47M files
When you know the words, you want them exact.
A name, a symbol, a string, an error message. The moment the token is known, ranking-by-similarity is the wrong shape. You want every literal match, deterministically, fresh to the last save, across the whole machine. That is a purpose-built indexed engine, and there is no model in it to drift. Measured on the machine below:
Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. Filename figures are medians: 139 μs across 20 queries, 85 μs single-file; the same lookup is 412,000× a VS Code search and ~480,000× Windows Search. Content queries run ~7 to 9 ms typical (rare symbols ~7 ms, common words ~9 ms; exact phrases ~16 ms). At rest the engine sits near 44 MB in Task Manager, and the on-disk index stays under 1% of the drive (~24 GB on a 4 TB machine).
The thesis
Keep the embeddings. Add the exact lane under them.
Embeddings and a live index aren't rivals: they answer different questions, so they run in parallel. Point vectors at meaning, where fuzzy recall is the feature. Point the index at the exact file, symbol, string, or error message, whole-machine, across every repo and the files git ignores, fresh to the last save. No model in the loop: every hit is a literal match you can verify, not a ranked guess, and nothing to re-embed. Interlinked is the exact-retrieval lane. It replaces neither your model nor your vector database; it is the deterministic floor they stand on.
PARALLEL TO RAG · EXACT, FAST, FRESH · NO MODEL IN THE LOOP.
Give every agent the exact lane
Keep search-by-meaning. Add search-by-fact.
One signed installer indexes every file on your machine (names and contents) and wires up the AI clients you already use, with no JSON to edit, no cloud account, and no keys. Keep your vector database and Cursor's index for the fuzzy questions; every agent also gets a fast, literal, whole-machine lookup for the exact ones. It stays fresh on its own: a save is searchable in about a millisecond, with nothing to re-embed.
Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows.
Related: RAG, a live index, or grep? · How Cursor indexes your codebase