Actually yes, code has structural intelligence and grepping on it like we are finding 32nd floor by scanning every floor in building while i know 32nd comes after 31.
Grep is like read all the shit present there no cap! and on compact compress the shit to avoid context! then shit become actual shit, Grep has to again find that context!
That's where structural understanding of your codebase comes into the picture. AST/LSP are actually better tool to understand your codebase structurally, but very hard and complex to manage.
What i did to solve this exploration cost, Build an Local MCP server with multiple tools. A structural codebase knowledge graph for tools to access it.
I know these things are actually everyone is doing, but creating graph is not only efficient, claude has to access it properly and graph should be data rich otherwise it will double down your token cost and it happens with many tools. It can give good results in testing because there you forced to use those tools.
But where claude is trained on grep, rg etc on billions of example, why would it rely on external tool. That too with less info. Enriched data is the key factor here, That's where we create metadata of node with keywords and edge calls. Finding files should be free of tokens and that's our goal and we do it.
During testing, not in any environment but in real workflows, it finds relevant file 90% of time and in those 10% we call directional grep in our graph not in the codebase and that changes everything!
Tries are great when your dictionary is fixed, but for dynamic datasets or finding similar pairs, BK-trees are often faster since they use the triangle inequality to skip most comparisons.