Thanks for reading, and for the thoughtful comment!

I'd push back a little on "replacing" though. I think it's less an upgrade path and more different tools for different jobs. My main hesitation with precomputed index approaches like Graphify is that without an LSP in the loop, the relationships are basically heuristic guesses over the AST, not resolved by an actual compiler. That's literally why Graphify needs those EXTRACTED/INFERRED/AMBIGUOUS confidence tags, it's grading its own guesses. My current setup trades that whole-repo convenience for something narrower but deterministic. When goto_definition or find_references gives me an answer, it's backed by real type and scope resolution, not pattern matching or similarity. For refactors, or anything where I need "every caller, no exceptions," that guarantee matters more to me right now than being able to ask aggregate questions about the whole codebase.

On voyage-code-3, that's a genuinely interesting angle and not something I'd brush off. The real gap in my current setup is that everything needs you to already know a name or a position. There's no way to just ask "find the thing that handles retry logic" without brute force scanning and hoping the LLM stumbles onto it. That's exactly the kind of problem embeddings are good at.

So honestly, I'm already thinking about a next version that isn't either/or. Something like voyage3 for coarse semantic recall to figure out what's roughly relevant, tree-sitter and LSP for precise resolution once things are narrowed down, and some kind of local memory or graph layer (basically a Graphify alternative) so structure persists across sessions instead of getting rebuilt from scratch every time.

Appreciate you pushing on this, it's genuinely helpful for figuring out where to take it next.