Discussion on "Why a Coding Agent Needs Three Different Ways to "Read" Code"

Iresh Sharma · 2026-08-18T11:41:21.829Z

If you're building something like Devin, an agent that goes end-to-end from a task description to a working code change. The very first problem you hit isn't code generation. It's comprehension. Befor

The “cheapest tool that answers the question” idea is the part I’d keep. Agents waste a lot of context when they treat every code lookup like a file read. Tree-sitter for local stuff and LSP for relationships feels like the right split.

The “cheapest tool that answers the question” principle is probably the most practical takeaway here. An agent doesn't need deeper semantic understanding for every lookup, and using an expensive project-wide tool for simple symbol discovery can waste both latency and context. Treating code navigation as an escalation path, from local structure to project relationships, feels like a much better fit for agent workflows.

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?

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.

Really interesting perspective on how coding agents understand and work with code. The idea that different levels of code reading are needed for better reasoning, navigation, and problem-solving highlights the complexity behind building truly useful AI developer tools. I enjoyed how you broke down the importance of context and depth when analyzing code. Great insights for anyone interested in the future of AI-assisted programming!

interesting perspective , most of the similar things i have read in one more course called RAMP, where A stands for agentic or agents,

The detail I want to underline is find_symbol returning a 1-based position "specifically so that position can be fed straight into goto_definition". Models really are bad at deriving line/column from a text dump, and making the cheap tool emit coordinates for the expensive one is the cleanest fix I have seen written down. One more property of tree-sitter worth naming for this use case: its error recovery. Mid-edit files parse to a tree with error nodes instead of failing, so find_symbol keeps working while the agent is halfway through a refactor, exactly when the language server starts complaining. On your open question about invalidation: pyright republishes diagnostics on didChange without a didOpen round trip, so a thin didChange with a debounce may get you fresh diagnostics cheaper than reopening files. Did you consider caching find_references results, or is the staleness risk after edits too high to bother?

This is what I want to do next, some sort of local memory plus from Shubhojyoti Ganguly comment I what to also try adding voyage3 for answering questions like "where is the retry logic"

The idea that a coding agent needs several different ways to read code matches what I see: keyword search, structural parsing, and semantic retrieval each catch what the others miss. I lean on the structural view most when the agent needs to reason about what calls what, and on retrieval when it needs intent. Nice articulation of why one representation is never enough.

Search Hashnode

Why a Coding Agent Needs Three Different Ways to "Read" Code

Responses(9)