Find the Idea, Not Just the Keyword: Local Code Search in Dojo

You know what the code does. You just do not know what its author called it.

“Where do we retry failed requests?” “Which part decides whether a setting is available?” “Find the code that restores the last session.”

Those are perfectly sensible questions. They are not always useful keywords. A repository might call the same idea a retry policy, a capability resolver, or session hydration. Searching one guessed word can mean missing the right file entirely.

Dojo’s local semantic search helps bridge that gap. Describe the behavior you need, and it searches your project for relevant code and documents by meaning.

Build the index. Keep using it.

On a supported computer with a usable GPU, Dojo can prepare an on-device search index for the open project. The first pass takes time: there is real material to read and organize.

That work is reusable. Later searches use the existing index, while new or changed files are refreshed rather than treating every question as a brand-new repository scan. Think initial indexing, then incremental upkeep—not “index once and never notice an edit.”

Behind the feature are embeddings: numerical representations that help relate a question to relevant passages. You do not need to manage vectors or learn a search language. Ask a clear question about the behavior you want to understand.

A shortlist you can inspect

The useful result is not a confident paragraph floating above the code. It is a ranked shortlist with file locations, line ranges, and excerpts that the assistant can read in context.

Try a question such as: “Where is cancellation handled during a long-running task?” The answer may lead to several layers: the request handler, the worker, and a cleanup path. That is a better starting point than opening unrelated files until a familiar name appears.

Search is navigation, not proof. The next step is to read the relevant source, follow its dependencies, and verify the behavior before changing it.

Spend less time finding the starting point

A ready local index can make repeated searches fast because the preparation does not have to be repeated from scratch. Actual response time depends on project size, hardware, indexing progress, and whether files need refreshing. A cold first pass and a warm search are different measurements.

We will not turn that into a universal “milliseconds” promise. The practical benefit is simpler: reuse the understanding you have already prepared, and spend more of your session on the problem itself.

If indexing is paused or still in progress, recent material may be missing. An empty shortlist is not evidence that a feature does not exist.

Meaning and exact matching belong together

Semantic search is a strong first move when the location or vocabulary is unfamiliar. Exact search remains the right tool for a known symbol, a literal error message, or every reference to an identifier.

A productive coding loop is straightforward:

1. Describe the behavior and find promising locations.
2. Read the relevant source in context.
3. Use exact search to follow symbols and check references.
4. Make a focused change and verify it.

Neither method needs to defeat the other. Together, they help you move from “somewhere in this repository” to an explanation grounded in actual files.

Local indexing, with clear boundaries

The search model and index run on your computer. A usable supported GPU is required for Dojo’s on-device AI, and initial model downloads need a connection.

Your chat provider remains a separate choice. If you use a cloud assistant, excerpts included in that conversation may be sent to that provider. Local search does not silently turn a cloud conversation into an offline one.

Whether you are learning an unfamiliar codebase, tracing a regression, or returning to a project after a month away, the goal is the same: ask about the idea, find the source, and keep the work grounded.