The reasoning behind the code, kept next to the code
Every codebase has a second half that lives in people's heads: why this retry count, why this fallback, why the obvious approach was rejected. It leaves when they do.
Twenty languages, indexed as code
Symbols and the calls between them go into the same graph as your notes, not a separate search box. A decision note and the function it produced end up as neighbours, because that is what they are.
The git history is indexed beside the notes
What changed, when, and what was written about it at the time, all reachable in one question. The commit tells you what happened; the note tells you why; neither is much use alone.
Impact radius, before you touch anything
Ask what depends on a symbol and get the answer from the graph rather than from a text search that finds every comment mentioning the name. Useful precisely when the code is unfamiliar, which is when you need it.
You inherit a service and find a magic number
Seven retries. No comment. Blame points at a commit that says "fix flakiness".
You ask why the retry count is seven. The answer cites a decision note from eighteen months ago — the store's own timeout was measured at six seconds under load, seven retries covered the worst observed case with margin, and dropping to three reintroduced the failure — and beside it, the function that implements it and the test that pins it.
You now know whether you can change it. The alternative was to change it, ship it, and find out.
Can I use this with my data?
Retrieval is local. Generation goes where you point it.
Finding the right passages happens on your machine, always. What happens next is your choice: connect a cloud model and the retrieved passages travel to that provider, exactly as they would if you pasted them; point it at a model running locally and nothing leaves the machine at all. That second option is available today, and it is what turns "where is our data processed?" into "on your device".