How to find code when you don't know what to grep for

Grep is perfect when you know the word. It is useless when you don't. You join a project and want to know where users get locked out after too many wrong passwords, so you search for "lock out" and get nothing. The code is there, but its author called it a cooldown, a throttle, isCoolingDown. Grep matches letters, and your question and the code don't share any. Searching by meaning fixes that. Every piece of the codebase is turned into a vector, a list of numbers that describes what the piece is about, and your question is turned into one too. Pieces that mean something close to your question come out on top, whatever words they use. The osFoundry desktop app can build that index on your own computer, with a free local model, and its agent can search it when you ask in plain English. 1. Add the project folder and look at the scan Open Indexes, stay on the Sources tab and click Add folder. Pick the project's root folder. Before anything is embedded, the app scans the folde

How to find code when you don't know what to grep for

Grep is perfect when you know the word. It is useless when you don't. You join a project and want to know where users get locked out after too many wrong passwords, so you search for "lock out" and get nothing. The code is there, but its author called it a cooldown, a throttle, isCoolingDown. Grep matches letters, and your question and the code don't share any.

Searching by meaning fixes that. Every piece of the codebase is turned into a vector, a list of numbers that describes what the piece is about, and your question is turned into one too. Pieces that mean something close to your question come out on top, whatever words they use. The osFoundry desktop app can build that index on your own computer, with a free local model, and its agent can search it when you ask in plain English.

1. Add the project folder and look at the scan

Open Indexes, stay on the Sources tab and click Add folder. Pick the project's root folder.

Before anything is embedded, the app scans the folder. The scan is free, and it shows what indexing would cover: how many files, how many megabytes, roughly how many chunks, and why the rest is skipped.

The free scan of a project folder: files, size, estimated chunks and what is skipped (example project)

The skipped list is not an error. Folders like node_modules, dist, build, .git and .venv are always left out, on top of your .gitignore, and so are lockfiles such as package-lock.json and pnpm-lock.yaml. Files over 1 MB and binary files are skipped too. None of that is code anyone searches by meaning.

Everything that remains is cut into chunks of about 700 tokens, with an 80-token overlap so a function that sits on a boundary still lands whole in one of them. Each chunk keeps its first and last line number, which is what lets a search result point at file.ts:1-46 instead of just a file.

The cloud price on the right is for the other button. The token count behind it is deliberately estimated high (one token per three bytes), so the real figure is never above it.

2. Index it locally

Click "Index locally · bge-m3 · free". bge-m3 is an open embedding model that runs on your machine. It reads each chunk and writes down its vector. Nothing is uploaded and nothing is charged.

Indexing on the device with bge-m3, chunk by chunk (example project)

The first run takes a while on a laptop, because every chunk goes through the model once. After that, the work is incremental. A chunk whose text has not changed keeps its vector, so editing one function re-embeds a handful of chunks, not the whole repository. If you switch on "Re-index automatically when files change", the app does that on its own as you work.

When the badge says Ready, the folder shows "on-device · bge-m3" and the number of chunks indexed.

3. Ask in plain words

Open a Maestro chat for the project and ask the way you would ask a colleague: "Where do we lock someone out after too many wrong passwords?"

The agent's grep for

The agent tried grep first and found zero matches, because the code never says "lock out". Then it called folder_search, the tool that searches an indexed folder. That tool runs two searches side by side: a keyword search, which is still the best way to find an exact name or error string, and a vector search over the chunks, which finds code that is about your question without using your words. The two rankings are merged with Reciprocal Rank Fusion, which only looks at positions in each list, so a chunk that both searches rank well ends up first.

The answer with the file and the exact line range (example)

The answer comes back with the file and the line range of the chunk, here src/auth/throttle.ts, lines 1 to 46, and the agent reads that file before answering, so you can jump straight to the code.

When grep is still the better tool

If you already know the identifier, the error message or the file name, grep or the keyword side of the search will find it faster and more exactly. A vector blurs useWorkspaceStore into a neighbourhood of similar-looking names. Search by meaning earns its place when you can describe the behaviour but can't name it, which is most of the first week in an unfamiliar codebase.

The semantic search glossary entry explains the idea in more depth, and the app is free from the osFoundry download page for macOS, Windows and Linux.

Share