Live data from Hacker News

Why Cline doesn't index your codebase

cline.bot

91–100 of 131 posts

Re: Why Cline doesn't index your codebase

#91

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.

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…

Hi, nick, given that this product is opensourced, I have a request/ wish:

It would be wondeful if some of the tools the projects uses are exposed to build on. Like the tools related to AST, finding definitions, and many more

Re: Why Cline doesn't index your codebase

#92
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 doesn't read like an LLM at all...

Re: Why Cline doesn't index your codebase

#93
post #65

Earlier quoted context omitted.

at some point they will move from scanning files to scannign the AST and then token consumption will be greatly reduced by default, the challenge is that then you need something generic enough like tree-sitter to reduce the monumental effort of integrating a number of parsers.

Why would an AST greatly reduce LLM token consumption?

a lot of token are used reading files whole just to understand where to fit the feature requested and the edit point, access to an AST would allow the llm to see the project "wireframe" so to say, by asking classes or method level granularity, and only then retrieving the source for the symbol that most likely contains the edit point the llm needs. some token consumption there is anovaidable as the llm need the source to build a diff, but still, it's focused on the feature than the search.

Re: Why Cline doesn't index your codebase

#94
post #40

I kept wondering why Cursor was indexing my codebase, it was never clear. Anyway context to me enables a lot more assurance and guarantees. RAG never did. My favorite workflow right now is: - Create context with https://github.com/backnotprop/prompt-tower - Feed it to Gemini - Gemini Plans - I pass the plan into my local PM framework - Claude Code picks it up and executes - repeat

Can you give an example of a local PM framework? What happens in this step - ticket creation?

Re: Why Cline doesn't index your codebase

#95
Have you guys at Cline considered using LLMs to create summaries of files and complex functions? Rather than read a 500 line function, feed it a short comment on what the function is doing. I'd like to use a local LLM to create summaries at every level: function, file, directory. Then let the LLM use that to find the right code to read. This is basically how I navigate a large code base.

Re: Why Cline doesn't index your codebase

#96

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.

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…

If you're putting everything in the context window, is it still considered "retrieval"? Did we have a preexisting robust definition of what constitutes retrieval?

Re: Why Cline doesn't index your codebase

#97
post #51
post #49

Earlier quoted context omitted.

I've always wondered... Making agents edits (like vibe coding), all the tools I've tried (Cursor, Zed, VSCode) are pretty equal since most of the brains are in the underlying models themselves. But the killer app that keeps me using Cursor is Cursor Tab, which helps you WHILE you code. Whatever model they have for that works beautifully for me, whereas Zed's autocomplete model is the last thing that keeps me away fro…

I use Cline within Cursor — best of both worlds!

What's the benefit? If you're paying $20/month for cursor you already get all the agentic coding as part of it.

Re: Why Cline doesn't index your codebase

#98

Terrible stuff and a reddish flag. First of all, gpt signs all over the blog post, reads like a bottom of the barrel linkedin post. But more importantly, why double and triple down on no RAG? As with most techniques, it has its merits in certain scenarios. I understand getting VC money so you have to prove differentiation and conviction in your approach, but why do it like this? What if RAG does end up being useful?…

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…

How is it better than Claude Code? I have decent experience with CC, but haven't used Cline. Are there good tutorials for best practices with it?

Re: Why Cline doesn't index your codebase

#99

I generally agree with the article and the approach given practical constraints, however it’s all stop gap anyway. Using Gemini 2.5’s 1MM token context window to work with large systems of code at once immediately feels far superior to any other approach. It allows using an LLM for things that are not possible otherwise. Of course it’s damn expensive and so hard to do in a high quality way it’s rare luxury, for now…

It's always a tradeoff, and most of the time chunking and keeping the context short performs better.

I feed long context tasks to each new model and snapshot just to test the performance improvements, and every time it's immediately obvious that no current model can handle its own max context. I do not believe any benchmarks, because contrary to the results of many of them, no matter what the (coding) task is, the results start getting worse after just a couple dozen thousand tokens, and after a hundred the accuracy becomes unacceptable. Lost-in-the-middle is still a big issue as well, at least for reasoning if not for direct recall - despite benchmarks showing it's not. LLMs are still pretty unreliable at one-shotting big things, and everything around it is still alchemy.

Re: Why Cline doesn't index your codebase

#100

Have you guys at Cline considered using LLMs to create summaries of files and complex functions? Rather than read a 500 line function, feed it a short comment on what the function is doing. I'd like to use a local LLM to create summaries at every level: function, file, directory. Then let the LLM use that to find the right code to read. This is basically how I navigate a large code base.

I've just used Cline to produce files like that, and then later when starting a task in plan mode I tell it to read those files to get a sense of the project's structure. I also tell it to update them as necessary after whatever task we're doing is finished.
Post reply on HN