Live data from Hacker News

Why Cline doesn't index your codebase

cline.bot

81–90 of 131 posts

Re: Why Cline doesn't index your codebase

#81

After trying cline,aider,codex, and what not, I feel claude code is just so so better than all of them. e.g It takes much much fewer prompts to be able to do the same thing compared to cline. tbh I am not sure how cline will compete against something like Claude code due to the resource/capability imbalance. Does anyone else have a different experience?

I really felt like Claude Code would benefit greatly from a similar structural map. The little map it made in the Claude.md is insufficient. When the code base grows or you add a more componentized approach, Claude Code started favoring a locality bias which increases the architectural entropy a LOT.

Re: Why Cline doesn't index your codebase

#82
post #15

"We Don't Dynamically Index Your Codebase So We Recan It with Every Query". Wasting time and tokens like this is not something to brag about. If indexing is so hard maybe someone should start a company just to do that, like https://news.ycombinator.com/item?id=44097699

They are saving time and tokens. They are rescanning the files locally using parsing and AST without sending tokens to the model which

Re: Why Cline doesn't index your codebase

#83
post #65

Earlier quoted context omitted.

Why would an AST greatly reduce LLM token consumption?

More focus on what to use rather when the whole file where the code snippet sits

I see, it could in principle more easily prune subtree that aren’t relevant. Initially I was assuming that the LLM would still ingest the whole AST in some form, since OP wrote “scanning the AST”. Does that mean the LLM would be invoking some sort of tool to perform a query on the AST?

Re: Why Cline doesn't index your codebase

#84

Earlier quoted context omitted.

Cline is, hands down, the most effective agentic coding tool out there. I've extensively daily driven any one of them you can name, and there's nothing even close. The reality is that no one knows how any of this stuff should work, and RAG is just a term that was made up a few years ago; it has no strict formal definition. There's a long way to go before anyone knows what the correct way to do things should be, but t…

What are the options? Cursor, Zed, Cline (VSCode), and anything else? I have not tried either. I wanted to try Cursor but it has a bug that is a blocker. My workflow involves manual copying and pasting from the browser into my own text editor.

Amazon Q CLI, Claude Code CLI, Goose with any model, OpenAPI released Codex CLI recently, and Google released Jules.

You can also just use Claude Desktop and hook it up to MCP servers.

Re: Why Cline doesn't index your codebase

#85

This is still retrieval and RAG, just not vector search and indexing. it’s incredibly important to be clear about terms - and this article does not meet the mark.

> it’s incredibly important to be clear about terms

Is it? None of these terms even existed a couple of years ago, and their meaning is changing day by day.

Re: Why Cline doesn't index your codebase

#86
post #84

Earlier quoted context omitted.

What are the options? Cursor, Zed, Cline (VSCode), and anything else? I have not tried either. I wanted to try Cursor but it has a bug that is a blocker. My workflow involves manual copying and pasting from the browser into my own text editor.

Amazon Q CLI, Claude Code CLI, Goose with any model, OpenAPI released Codex CLI recently, and Google released Jules. You can also just use Claude Desktop and hook it up to MCP servers.

I still need to catch up on MCPs, it is still new to me and truth be told, I am clueless about it.

Re: Why Cline doesn't index your codebase

#87
What about doing something just-in-time? I'm just speculating, but what if cline leverages the LSP (for instance, rust-analyzer) to track the function chain and build a tree-like context of the codebase—not the entire codebase, but just specific blobs of code?

Would that work?

Re: Why Cline doesn't index your codebase

#89
post #58

Earlier quoted context omitted.

Fair point Jeff -- you're right that we're still doing retrieval. The key distinction is how we retrieve. Traditional RAG for code uses vector embeddings and similarity search. We use filesystem traversal and AST parsing - following imports, tracing dependencies, reading files in logical order. It's retrieval guided by code structure rather than semantic similarity. I highly recommend checking out what the Claude Cod…

Don’t take this the wrong way, but did you use an LLM to generate this reply? The reply is good, but the writing style just piqued my curiosity.

This may not be what is meant here, but I wonder if in the future anybody who actually bothered to learn to write well will automatically be flagged as likely having used AI to write their prose.

For instance, everyone seems to believe that em dashes are something only an AI would use -- but I've been using them in my writing for a long time.

Re: Why Cline doesn't index your codebase

#90

I never had good experience with RAG anyway, and it felt "hacky". Not to mention most of it basically died when most models started supporting +1M context. LLMs are already stochastic. I don't want yet another layer of randomness on top.

> and it felt "hacky"

I think the pattern that coined "RAG" is outdated, that pattern being relying on cosine similarities against an index. It was a stop gap for the 4K token window era. For AI copilots, I love Claude Code, Cline's approach of just following imports and dependencies naturally. Land on a file and let it traverse.

No more crossing your fingers with match consign and hoping your reranker did drop a critical piece.

Post reply on HN