---
title: "Comment by Shubhojyoti Ganguly on \"Why a Coding Agent Needs Three Different Ways to \"Read\" Code\" | Hashnode"
description: "The entire approach is an older style of navigating codebase. A MCP server like repowise or graphify is replacing the LSP server these days. The MCPs use an ind"
url: "https://hashnode.com/posts/why-a-coding-agent-needs-three-different-ways-to-read-code/6a8444e10f3c9d013e58eb01/comment/6a85a8fc8860085c8225e429"
---

[Discussion](https://hashnode.com/posts/why-a-coding-agent-needs-three-different-ways-to-read-code/6a8444e10f3c9d013e58eb01)

Comment [Why a Coding Agent Needs Three Different Ways to "Read" Code](https://hashnode.com/posts/why-a-coding-agent-needs-three-different-ways-to-read-code/6a8444e10f3c9d013e58eb01)

[Shubhojyoti Ganguly](https://hashnode.com/@sgang007)

[Aug 19](https://hashnode.com/posts/why-a-coding-agent-needs-three-different-ways-to-read-code/6a8444e10f3c9d013e58eb01/comment/6a85a8fc8860085c8225e429)

The entire approach is an older style of navigating codebase. A MCP server like repowise or graphify is replacing the LSP server these days. The MCPs use an indexing algorithm to expose entities to any LLM tool.

The entire process totally depends on the sophistication in the indexing layer.

Also, would love to hear your thoughts on AST vs code-specific embeddings like voyage3 in crawling the codebase?

[Iresh Sharma](https://hashnode.com/@Iresharma)

[Aug 19](https://hashnode.com/posts/why-a-coding-agent-needs-three-different-ways-to-read-code/6a8444e10f3c9d013e58eb01/comment/6a85a8fc8860085c8225e429#reply-6a860399b6905b626e04ded8)

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.