alt Hacker NewsI feel a lot of these tools are barking up the wrong tree. Solving problems that are just symptoms of a deeper root cause. Index because my codebase is too big to grep. Index to paraphrase hard_decline via card retries. Reduce tool calling to save my agent YOLO search loops. etc. etc.
It feels like trying to overcome bad codebase hygiene by throwing more tools at it, and wallpapering the mold over. I've found that codebases left entirely to LLMs suffer from this gravely, but with even a bit of effort - you'll get outsized returns. Don't let the agent smosh up everything into a giant ball of code. Separate concerns, build services, do the architecture step of the software design with a bit more care than vibe coding.
A bit of a rant, yeah, but I don't see why tools like this exist (and ask you to curl a script into bash, no less). You're doing stuff a bit wrong if grepping is the bottleneck.
Replies
"Indexing" is a very general term and I don't think it is barking up the wrong tree.
A library card catalog system is an index. It exists to make it easy to find the right book quickly.
Your grocery store aisles are indexes to make it easier for you to find baking supplies from laundry and cleaning.
Well-organized codebases are already indexes by project, by folder structure, by naming convention, etc.
We use indexes everywhere, big or small.
The problem is really that the harnesses/SDKs/APIs themselves appear as if they weren't designed with indexes in mind from the outset.
I mostly feel the same, but it'd be really interesting to measure it, I think. Like, how many tokens did it cost in a codebase of quality Q1 vs one of quality Q2 to `grep` vs some semantic search. And did you find the correct `DuplicateSymbolName` in the correct namespace?
I don't think most people have control of the code base they're required to work in.
I too have converted a code base I made to typescript and peppered it with AI docs to make visibility easier.
I've converted i18n files to a k:v[] arrays per language because the AI is shit at working with objects. The ability now for it to just find/insert additional languages is well improved.
There definitely are shapes in code that the AI will have trouble with.
But again, I don't think most people have control over the code they maintain.
>I feel a lot of these tools are barking up the wrong tree.
Its the right tree, but not the right branch. RAG systems are the next big thing. You can take a small model running locally, feed it a bunch of context and it will be able to generate the correct answer on par with a larger model with no context.
Context doesn't have to be documents/code either, it can be LLM generated context that guides next iterations of inference on how to do things.
You don't index because a code base is too big to grep. Grep can cut through almost any code base. The problem is that grep is lexical. It is dumb.
grep is insufficient or we wouldn't have LSP. At minimum you want some kind of structure aware search (for human ergonomics alone, but robots too).