Hey, this is my first post on Hashnode. I'm a CS student, and I built a small tool recently to solve a problem I kept hitting in my workflow. It's not the next big thing, but if you're hitting the sam
roypriyanshu02.hashnode.dev6 min readKartik N V J K
AI Developer | Making AI reliable, trustworthy & accessible to everyone | Active community contributor
One thing we've noticed is that as repositories grow, retrieval becomes a much bigger bottleneck than generation. If an agent spends most of its time grepping and re-reading files, you're paying in both latency and tokens before it even starts reasoning.
Using AST-based indexing is a smart approach because it gives the agent structural context instead of raw text. It would also be interesting to see benchmarks on incremental re-indexing for large monorepos and how it performs alongside RAG- or embedding-based code retrieval. Nice first project looking forward to seeing how it evolves.
The Tree-sitter + SQLite combo for AST symbol lookup is the right call, and swapping blind grep/cat for a definition resolver is exactly where most of my agent token spend was hiding too. One thing I'd love to hear you dig into: how you handle stale index invalidation on partial writes, since that's the failure mode that eventually made me distrust the tool and re-grep anyway. The <100ms target is only useful if a returned symbol is guaranteed to reflect the file on disk at call time.