Why Cline doesn't index your codebase(cline.bot)
cline.bot
Why Cline doesn't index your codebase
https://cline.bot/blog/why-cline-doesnt-index-your-codebase-and-why-thats-a-good-thing
130 comments
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 Code team discovered (48:00 https://youtu.be/zDmW5hJPsvQ?si=wdGyiBGqmo4YHjrn&t=2880). They initially experimented with RAG using embeddings but found that giving the agent filesystem tools to explore code naturally delivered significantly better results.
From our experience, vector similarity often retrieves fragments that mention the right keywords but miss the actual implementation logic. Following code structure retrieves the files a developer would actually need to understand the problem.
So yes -- I should have been clearer about the terminology. It's not "no retrieval" -- it's structured retrieval vs similarity-based retrieval. And with today's frontier models having massive context windows and sophisticated reasoning capabilities, they're perfectly designed to build understanding by exploring code the way developers do, rather than needing pre-digested embeddings.
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 Code team discovered (48:00 https://youtu.be/zDmW5hJPsvQ?si=wdGyiBGqmo4YHjrn&t=2880). They initially experimented with RAG using embeddings but found that giving the agent filesystem tools to explore code naturally delivered significantly better results.
From our experience, vector similarity often retrieves fragments that mention the right keywords but miss the actual implementation logic. Following code structure retrieves the files a developer would actually need to understand the problem.
So yes -- I should have been clearer about the terminology. It's not "no retrieval" -- it's structured retrieval vs similarity-based retrieval. And with today's frontier models having massive context windows and sophisticated reasoning capabilities, they're perfectly designed to build understanding by exploring code the way developers do, rather than needing pre-digested embeddings.
Probably good to add a disclaimer at the top that clarifies the definition, since RAG is ultimately just a pattern, and vector indexes are just one way to implement the pattern.
Indeed, industry at large sees RAG as equivalent to "vector indexes and cosine similarity w.r.t. input query", and the rest of the article explains thoroughly why that's not the right approach.
Indeed, industry at large sees RAG as equivalent to "vector indexes and cosine similarity w.r.t. input query", and the rest of the article explains thoroughly why that's not the right approach.
> industry at large sees RAG as equivalent to "vector indexes and cosine similarity w.r.t. input query"
Yep, and this is getting really old. Information retrieval is not a new problem domain. Somehow, when retrieved info is fed into an LLM, all nuance is lost and we end up with endless pronouncements about whether retrieval is/is not "dead".
Yep, and this is getting really old. Information retrieval is not a new problem domain. Somehow, when retrieved info is fed into an LLM, all nuance is lost and we end up with endless pronouncements about whether retrieval is/is not "dead".
Following dependencies is the way to go IMHO. Saying "Code Doesn't Think in Chunks", is IMHO not correct. Developers do thing in chunks of codes. E.g. this function calls that function uses that type and is used here and there. It is not really a file based model like Cline uses. The file based model is "just" simpler to implement :-) . We use a more sophisticated code chunking approach in https://help.sap.com/docs/build_code/d0d8f5bfc3d640478854e6f... Let's see, maybe we should open source that ...
Maybe you should indeed! Without looking into too much details, how CLI-friendly would this tool be?
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
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
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?
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.
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.
This doesn't read like an LLM at all...
I wonder if the more we use LLMs the more our written patterns will begin to match them. Those of us who work with them the most are likely to be affected earliest.
[deleted]
btw that podcast was recorded in jeff's office :)
The article reads fine to me.
Yes by technicality RAG could mean any retrieval, but in practice when people use the term it’s almost always referring to some sort of vector embedding and similarity searching.
Yes by technicality RAG could mean any retrieval, but in practice when people use the term it’s almost always referring to some sort of vector embedding and similarity searching.
Wittginstein would concur
> 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.
Is it? None of these terms even existed a couple of years ago, and their meaning is changing day by day.
I guess that's technically true, but RAG has colloquially taken on the meaning of vector database retrieval. Perhaps there's a paper out there that defines RAG specifically as any data retrieval, but at this point in time that's so general a term that it's bordering on useless. It's like saying "network connected application". No one has said that for decades now that it's status quo. Also, there are many types of networks, but "network connected app" generally meant TCP, despite it not being in the name.
[deleted]
Fairly pedantic take.
Cline is the most impressive agentic coder tool I’ve used and it seems to be getting better. I’ve learned to work with it to the extent where I can plan with it for 10-15 minutes, set it loose on my codebase, go get lunch, and then its diff is almost always completely on the money. You should commit often for those rare cases where it goes off the rails (which seems to happen less frequently now).
Using Gemini 2.5 pro is also pretty cheap, I think they figured out prompt caching because it definitely was not cheap when it came out.
Using Gemini 2.5 pro is also pretty cheap, I think they figured out prompt caching because it definitely was not cheap when it came out.
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 from it.
What do Cline users use for the inline autocomplete model?
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 from it.
What do Cline users use for the inline autocomplete model?
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.
Cursor changed their pricing recently and now charge a 20% markup on LLM API calls to use their "Max" models (which from what I gather are the full extent of the LLM context windows you get in the API anyway).
I also don't love that Cursor generally plays "context compression" games since they have an incentive to keep their costs minimal. I just don't love any of these tools that try to be a bit too smart as a middleman between you and the LLM (where smart is often defined as 'try to save us the most money or be maximally efficient without the user noticing').
Cline also tries to be smart, but it's all for the benefit of the user. I like the transparent pricing -- you bring your own API key so you're paying the underlying API costs without a middle man markup.
Am I being pennywise and should I just use Cursor directly? Maybe...but I've found my Cline results to be generally better for the more complex queries.
I also don't love that Cursor generally plays "context compression" games since they have an incentive to keep their costs minimal. I just don't love any of these tools that try to be a bit too smart as a middleman between you and the LLM (where smart is often defined as 'try to save us the most money or be maximally efficient without the user noticing').
Cline also tries to be smart, but it's all for the benefit of the user. I like the transparent pricing -- you bring your own API key so you're paying the underlying API costs without a middle man markup.
Am I being pennywise and should I just use Cursor directly? Maybe...but I've found my Cline results to be generally better for the more complex queries.
Everything you’re saying is valid for agentic coding.
But I’m also missing the regular Cursor Tab inline autocomplete when I’m coding, cuz I still often write code line by line like a caveman.
So what’s the cline alternative to it? Or am I thinking of this wrong?
But I’m also missing the regular Cursor Tab inline autocomplete when I’m coding, cuz I still often write code line by line like a caveman.
So what’s the cline alternative to it? Or am I thinking of this wrong?
Like a caveman! :)
I actually haven't explored the inline autocomplete space that much yet. I really like Cursor Tab (or Supermaven or even plain 'ol Copilot) -- they all seem really good. I'm sure there's a Cline equivalent out there, but I don't know what it is (yet).
I actually haven't explored the inline autocomplete space that much yet. I really like Cursor Tab (or Supermaven or even plain 'ol Copilot) -- they all seem really good. I'm sure there's a Cline equivalent out there, but I don't know what it is (yet).
Copilot Next Edit
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.
So you're effectively keeping two copies of the codebase but the second copy is written in prose?
Would it double your codebase? Do you think it would work for a large codebase?
Not anywhere close. It's basically just maintaining a simple descriptive index the model can later use to decide what files it needs to read given the task you've given it.
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…
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.
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.
1 million tokens is still not enough for real life codebases (100Ks to millions loc)
And it's obviously expensive use this approach.
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:
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
- repeatHow does this work?
It’s not clear how context is used to plan by Gemini then the plan is fed to local framework. Do I have to replan every time context changes?
It’s not clear how context is used to plan by Gemini then the plan is fed to local framework. Do I have to replan every time context changes?
They use a tool like the one they linked to put all their files into one file that they give to gemini.
Then they put the plan into their "PM framework" (some markdown files?) to have Claude Code pick tasks out of.
Then they put the plan into their "PM framework" (some markdown files?) to have Claude Code pick tasks out of.
Can you give an example of a local PM framework? What happens in this step - ticket creation?
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.
Same experience. Claude Code is much better than all other tools. I suspect Claude Code uses some private features of Claude model that's not available to other tools. It only makes sense that Anthropic will develop their model in conjunction with the tool to produce best result.
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.
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.
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.
>Not to mention most of it basically died when most models started supporting +1M context.
Do most models support that much context? I don't think anything close to "most" models support 1M+ context. I'm only aware of Gemini, but I'd love to learn about others.
Do most models support that much context? I don't think anything close to "most" models support 1M+ context. I'm only aware of Gemini, but I'd love to learn about others.
GPT 4.1 / mini / nano
As the context grows, all LLMs appear to turn into idiots, even just at 32k!
> We evaluate 12 popular LLMs that claim to support contexts of at least 128K tokens. While they perform well in short contexts (<1K), performance degrades significantly as context length increases. At 32K, for instance, 10 models drop below 50% of their strong short-length baselines. Even GPT-4o, one of the top-performing exceptions, experiences a reduction from an almost-perfect baseline of 99.3% to 69.7%.
https://news.ycombinator.com/item?id=44107536
> We evaluate 12 popular LLMs that claim to support contexts of at least 128K tokens. While they perform well in short contexts (<1K), performance degrades significantly as context length increases. At 32K, for instance, 10 models drop below 50% of their strong short-length baselines. Even GPT-4o, one of the top-performing exceptions, experiences a reduction from an almost-perfect baseline of 99.3% to 69.7%.
https://news.ycombinator.com/item?id=44107536
This paper is slightly outdated by LLM model standards -- GPT 4.1 or Gemini 2.5 haven't been released at that time.
Yes, I mentioned that in the comment in the linked post. I wish someone was running this methodology as an ongoing project, for new models.
Ideally, isn't this a metric that should be included on all model cards? It seems like a crucial metric.
Ideally, isn't this a metric that should be included on all model cards? It seems like a crucial metric.
I've been wondering when someone would finally use the actual code structure to do RAG. It seems like such an obvious, if somewhat harder (at least if you need to support many languages), approach.
The vector/keyword based RAG results I've seen so far for large code bases (my experience is Cody) has been quite bad. For a smaller projects (using Cursor) it seems to work quite well though.
The vector/keyword based RAG results I've seen so far for large code bases (my experience is Cody) has been quite bad. For a smaller projects (using Cursor) it seems to work quite well though.
Aider has been doing that for a long time now, it was the first project to do this afaik.
The most funny thing is how synchronicity worked its magic:
Roo Code experimental code indexing using vector DB dropped 3 days ago. Theire using Tree-sitter (the same as Aider) to parse sources into ASTs and do vector embedding on that product, instead of plaintext.
https://news.ycombinator.com/item?id=44117455
Roo Code experimental code indexing using vector DB dropped 3 days ago. Theire using Tree-sitter (the same as Aider) to parse sources into ASTs and do vector embedding on that product, instead of plaintext.
https://news.ycombinator.com/item?id=44117455
This seems like a marketing piece, very poorly justified.
First, large context models essentially index their context as it grows bigger, or else they can't access the relevant parts of it. However it can't be as comprehensive as with RAG. There is also nothing that makes navigating the context from point to point easier than with RAG.
It seems they're trying to convince people of their superiority, but it's BS, so they're trying to bank on less knowledgeable customers.
Indexing is essentially a sorted projection of a larger space, based on the traits and context you care about. There's no magical way for a context to be more accessible, if it has no such semantical indexing, implicit or explicit. Also RAG doesn't mean you can't embed AST and file structure as a concern. A vector is a set of dimensions, a dimension can be literally anything at all. AI is about finding suitable meaning for each dimension and embedding instances in that dimension (and others in combo).
First, large context models essentially index their context as it grows bigger, or else they can't access the relevant parts of it. However it can't be as comprehensive as with RAG. There is also nothing that makes navigating the context from point to point easier than with RAG.
It seems they're trying to convince people of their superiority, but it's BS, so they're trying to bank on less knowledgeable customers.
Indexing is essentially a sorted projection of a larger space, based on the traits and context you care about. There's no magical way for a context to be more accessible, if it has no such semantical indexing, implicit or explicit. Also RAG doesn't mean you can't embed AST and file structure as a concern. A vector is a set of dimensions, a dimension can be literally anything at all. AI is about finding suitable meaning for each dimension and embedding instances in that dimension (and others in combo).
Cursor does it.
Cline doesn't.
Aider goes the middle way with repo maps.
Let's see what works best.
Cline doesn't.
Aider goes the middle way with repo maps.
Let's see what works best.
I would even classify aider a different way because it avoids what the blog posts is talking about (or moves the responsibility more to the human). In aider you can manually define or basically override which files are important for your context and for the LLM to know. With 1M context windows that's like a no brainer (except for extremely massive projects). I mean the repo map truly helps but I compare it with like driving a manual car... you shift the gears yourself by selecting the relevant files yourself and not your "automatic car"/AI code assistant for you like on cursor, cline, roo, claude code etc.
When I'm in the middle of a conversation with AI, sometimes I like to change the code immediately ("Oh that's wrong, let me fix that first"). Does it mess the context? Or I need to close/Ctrl+C and reopen?
As far as I know, Aider uses the latest content of the file, each time you ask something.
Btw. You can also trigger Aider via comments. This way you can mix it with your changes immediately.
https://aider.chat/docs/usage/watch.html#ai-comments
Btw. You can also trigger Aider via comments. This way you can mix it with your changes immediately.
https://aider.chat/docs/usage/watch.html#ai-comments
What's the difference between Aider's repo map and the Cline AST? Sounds like a small difference in implementation than a difference in concept.
I think, the repomap is an AST that doesn't go down all the way.
I thought Cursor had support for MCP now? So in theory it can now navigate the code base, query for code structure, and so on as well no?
Eh... I'm not convinced. I like cline, I've been using it here and there and I think it found a good mix between "vibesus take the wheel" and "hey, I'm still here and I enjoy doing this". I was particularly surprised that it worked pretty well with local models. A lot of that is on the model (tested w/ devstral) but a lot of it is on the cradle (e.g. aider is great at what it does, but local model support is hit and miss).
First, like some other comments have mentioned RAG is more than result = library.rag(). I get that a lot of people feel RAG is overhyped, but it's important to have the right mind model around it. It is a technique first. A pattern. Whenever you choose what to include in the context you are performing RAG. Retrieve something from somewhere and put it in context. Cline seems to delegate this task to the model via agentic flows, and that's OK. But it's still RAG. The model chooses (via tool calls) what to Retrieve.
I'm also not convinced that embedding can't be productive. I think nick is right to point out some flaws in the current implementations, but that doesn't mean the concept in itself is flawed. You can always improve the flows. I think there's a lot to gain from having embeddings, especially since they capture things that ASTs don't (comments, doc files, etc).
Another aspect is the overall efficiency. If you have somewhat repetitive tasks, you'll do this dance every time. Hey, fix that thing in auth. Well, let's see where's auth. Read file1. Read file2. Read fileN. OK, the issue is in ... You can RAG this whole process once and re-use (some) of this computation. Or you can do "graphRAG" and do this heavy lifting once per project and have AST + graph + model dump that can be RAGd. There's a lot of cool things you can do.
In general I don't think we know enough about the subject, best practices and useful flows to confidently say "NO, never, nuh-huuh". I think there might be value there, and efficiencies to be gained, and some of them seem like really low hanging fruit. Why not take them?
First, like some other comments have mentioned RAG is more than result = library.rag(). I get that a lot of people feel RAG is overhyped, but it's important to have the right mind model around it. It is a technique first. A pattern. Whenever you choose what to include in the context you are performing RAG. Retrieve something from somewhere and put it in context. Cline seems to delegate this task to the model via agentic flows, and that's OK. But it's still RAG. The model chooses (via tool calls) what to Retrieve.
I'm also not convinced that embedding can't be productive. I think nick is right to point out some flaws in the current implementations, but that doesn't mean the concept in itself is flawed. You can always improve the flows. I think there's a lot to gain from having embeddings, especially since they capture things that ASTs don't (comments, doc files, etc).
Another aspect is the overall efficiency. If you have somewhat repetitive tasks, you'll do this dance every time. Hey, fix that thing in auth. Well, let's see where's auth. Read file1. Read file2. Read fileN. OK, the issue is in ... You can RAG this whole process once and re-use (some) of this computation. Or you can do "graphRAG" and do this heavy lifting once per project and have AST + graph + model dump that can be RAGd. There's a lot of cool things you can do.
In general I don't think we know enough about the subject, best practices and useful flows to confidently say "NO, never, nuh-huuh". I think there might be value there, and efficiencies to be gained, and some of them seem like really low hanging fruit. Why not take them?
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.
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?
I'm not convinced--codebase indexing is still a killer feature in Cursor. I have tens of thousands of reference files stashed in the project directory to be indexed so that any time the model reaches out to the codebase search tool with a question, it finds a file with the answer. Lots of it is not code and has no AST representation; it's documentation. Without codebase indexing, it may entirely miss the context.
1. This argument seems flawed. Codebase search gives it a "foot in the door"; from that point it can read the rest of the file to get the remaining context. This is what Cursor does. It's the benefit of the agentic loop; no single tool call needs to provide the whole picture.
2. This argument is "because it's hard we shouldn't do it". Cursor does it. Just update the index when the code changes. Come on.
3. This argument is also "because it's hard we shouldn't do it". Cursor does it. The embeddings go in the cloud and the code is local. Enforced Privacy Mode exists. You can just actually implement these features rather than throwing your hands up and saying it's too hard.
This honestly makes me think less of Cline. They're wrong about this and it seems like they're trying to do damage control because they're missing a major feature.
1. This argument seems flawed. Codebase search gives it a "foot in the door"; from that point it can read the rest of the file to get the remaining context. This is what Cursor does. It's the benefit of the agentic loop; no single tool call needs to provide the whole picture.
2. This argument is "because it's hard we shouldn't do it". Cursor does it. Just update the index when the code changes. Come on.
3. This argument is also "because it's hard we shouldn't do it". Cursor does it. The embeddings go in the cloud and the code is local. Enforced Privacy Mode exists. You can just actually implement these features rather than throwing your hands up and saying it's too hard.
This honestly makes me think less of Cline. They're wrong about this and it seems like they're trying to do damage control because they're missing a major feature.
Sounds like you're the exception rather than the rule. I've never seen a project with tens of thousands of files worth of accurate documentation. Any project that has that much documentation the majority of it is outdated and/or wrong. Some of it is still useful, but only in a historical context.
The code is the authoritative reference.
The code is the authoritative reference.
Sure, I'm a power user with a monster codebase, never said that I wasn't. RAG is a power user feature.
The files are generated from external sources, pulling together as much information as I could collect. It's a script so I can keep it up to date. I think there is roughly no programmer out there who needs to be told that documentation needs to be up-to-date; this is obvious enough that I'm trying not to be offended by your strawman. You could have politely assumed, since I said I have it working, that it does actually work. I am doing productive work with this; it's not theoretical.
The files are generated from external sources, pulling together as much information as I could collect. It's a script so I can keep it up to date. I think there is roughly no programmer out there who needs to be told that documentation needs to be up-to-date; this is obvious enough that I'm trying not to be offended by your strawman. You could have politely assumed, since I said I have it working, that it does actually work. I am doing productive work with this; it's not theoretical.
By documentation I assumed you meant internal documentation, like on a company Wiki.
External documentation is presumably already in the LLM's training data, so it should be extraneous to pull it into context. Obviously there's a huge difference between "should be" and "is" otherwise you wouldn't be putting in the work to pull it into context.
External documentation is presumably already in the LLM's training data, so it should be extraneous to pull it into context. Obviously there's a huge difference between "should be" and "is" otherwise you wouldn't be putting in the work to pull it into context.
I'd guess the breakdown is about:
- 80%: Information about databases. Schemas, sample rows, sample SQL usages (including buried inside string literals and obscured by ORMs), comments, hand-written docs. I collect everything I can find about each table/view/procedure and stick it in a file named after it.
- 10%: Swagger JSONs for internal APIs I have access to, plus sample responses.
- 10%: Public API documentation that it should know but doesn't.
The last 10% isn't nothing; I shouldn't have to do that and it's as you say. I've particularly had problems with Apple's documentation; higher than expected hallucunation rate in Swift when I don't provide the docs explicitly. Their docs require JavaScript (and don't work with Cursor's documentation indexing feature) which gives me a hunch about what might have happened. It was a pain in the neck for me to scrape it. I expect this part to go away as tooling gets better.
The first 90% I expect to be replaced by better MCP tools over time, which integrate vector indexing along with traditional indexing/exploration techniques. I've got one written to allow AI to interactively poke around the database, but I've found it's not as effective as the vector index.
- 80%: Information about databases. Schemas, sample rows, sample SQL usages (including buried inside string literals and obscured by ORMs), comments, hand-written docs. I collect everything I can find about each table/view/procedure and stick it in a file named after it.
- 10%: Swagger JSONs for internal APIs I have access to, plus sample responses.
- 10%: Public API documentation that it should know but doesn't.
The last 10% isn't nothing; I shouldn't have to do that and it's as you say. I've particularly had problems with Apple's documentation; higher than expected hallucunation rate in Swift when I don't provide the docs explicitly. Their docs require JavaScript (and don't work with Cursor's documentation indexing feature) which gives me a hunch about what might have happened. It was a pain in the neck for me to scrape it. I expect this part to go away as tooling gets better.
The first 90% I expect to be replaced by better MCP tools over time, which integrate vector indexing along with traditional indexing/exploration techniques. I've got one written to allow AI to interactively poke around the database, but I've found it's not as effective as the vector index.
A better argument against vector embeddings for AI code agents is that model performance degrades with number of tokens used (even when well below the context window limit), and vector chunks are more prone to bloating the context window with unhelpful noise than more targeted search techniques.
Claude Code doesn't do vector indexing, and neither does Zed. There aren't any rigorous studies comparing these tools, but you can find plenty of anecdotes of people preferring the output of Claude Code and/or Zed to Cursor's, and search technique is certainly a factor there!
Claude Code doesn't do vector indexing, and neither does Zed. There aren't any rigorous studies comparing these tools, but you can find plenty of anecdotes of people preferring the output of Claude Code and/or Zed to Cursor's, and search technique is certainly a factor there!
Same with Augment. Indexing makes a huge difference in a large monorepo and I can't imagine working in an editor that doesn't support an LLM with full indexing.
Does anybody else see high CPU and GPU utilization on this site with a process called ClineBot?
I cant help but think this article was published as a direct response to Cline's (arguably superior) fork, Roo Code, releasing an experimental Codebase Indexer in the past week...
https://docs.roocode.com/features/experimental/codebase-inde...
Augment Code's secret sauce is largely its code indexer, and I find it to be the best coding agent around.
https://docs.roocode.com/features/experimental/codebase-inde...
Augment Code's secret sauce is largely its code indexer, and I find it to be the best coding agent around.
Isn't this what is called CAG (context augmented generation) these days?
1. Although I think RAG for code is nonsense, CAG seems to be very expensive even with cachig - imagine a huge code base. There should be a more efficient option.
2. How about indexing documentation - RAG should be okay there?
They could still RAG the AST and just use different chunking strategies
It doesn’t seems like what they are doing necessarily replaced RAG, even if it can
The times I’ve implemented RAG, I’ve seen an immediate significant improvement in the answers provided by the model
Maybe they need some metrics to properly assess RAG vs no-RAG
It doesn’t seems like what they are doing necessarily replaced RAG, even if it can
The times I’ve implemented RAG, I’ve seen an immediate significant improvement in the answers provided by the model
Maybe they need some metrics to properly assess RAG vs no-RAG
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?
Would that work?
LSP generally uses an AST representation of the code under the hood. And an AST representation is generally larger - often much larger - than the original code. So I'm not sure what the benefits of this would be compared to just loading the actual code into the context.
Does cline expose this retrieval mechanism to the user? If yes, could I randomly chose points in my codebase, ask cline to do its “intelligent walk” and store the results in a graph database for graph-RAG?
Totally irrelevant on the subject, but the screen recording in the article caught my attention: what tool does one use to create the screen recording with zoom and mouse tracking?
The most popular one is Screen Studio[0], but there are a few alternatives there, like Tella[1].
[0]: https://screen.studio/
[1]: https://landingpage.tella.com/
[0]: https://screen.studio/
[1]: https://landingpage.tella.com/
Screen Studio is fantastic and unlike a lot of other commercial screen recorders has a one-time purchase cost (though you can also pay monthly).
Since I use Windows and Screen Studio is Mac only, I tried Tella and can definitely vouch for it. (I am on their free trial though)
My company is working on a similar tool to Cline, and we had an intern project last summer to create a tool for AI-for-coding RAG: https://github.com/accretional/semantifly
Ultimately we came to a similar conclusion and put the project on ice: chunking and vector similarity search are fundamentally not great approaches for code RAG.
I don't really agree with most of Cline's other assertions because those are pretty easy to work around (I suspect they may just be content slop?). It's pretty easy to vectorize and re-chunk code as you change it as long as you have a fixed way of encoding vectors, and you can also generate indices or do more expensive changes to encoding as part of your CI/CD. Indices can be stored in your git repo itself so theres not really a security risk either. Our tool made this pretty easy to do. An index can literally just be a file.
No, the problem is really that vector search (especially with a-kNN) is fundamentally a fuzzy/lossy kind of search, and even when the vector search part works perfectly, your choice of k will usually either include more information than you intend or miss information that didn't meet the top-K threshold. And naive implementations that don't add additional context or are unconditionally searching based on your prompt will probably bias or confuse your model with code that might seem relevant but isn't (eg if you are trying to debug deployments, you include a bunch of your code related to deployments, but the bug is in the application code, and also you have a bunch of deployment scripts in your codebase that are for different platforms and are extra irrelevant).
It's significantly more work to make a vector based approach to code-RAG actually good than it is to get a naive implementation working. We have a different approach to Cline but it's similar in that it uses things like references and how the developer actually understands their codebase.
Ultimately we came to a similar conclusion and put the project on ice: chunking and vector similarity search are fundamentally not great approaches for code RAG.
I don't really agree with most of Cline's other assertions because those are pretty easy to work around (I suspect they may just be content slop?). It's pretty easy to vectorize and re-chunk code as you change it as long as you have a fixed way of encoding vectors, and you can also generate indices or do more expensive changes to encoding as part of your CI/CD. Indices can be stored in your git repo itself so theres not really a security risk either. Our tool made this pretty easy to do. An index can literally just be a file.
No, the problem is really that vector search (especially with a-kNN) is fundamentally a fuzzy/lossy kind of search, and even when the vector search part works perfectly, your choice of k will usually either include more information than you intend or miss information that didn't meet the top-K threshold. And naive implementations that don't add additional context or are unconditionally searching based on your prompt will probably bias or confuse your model with code that might seem relevant but isn't (eg if you are trying to debug deployments, you include a bunch of your code related to deployments, but the bug is in the application code, and also you have a bunch of deployment scripts in your codebase that are for different platforms and are extra irrelevant).
It's significantly more work to make a vector based approach to code-RAG actually good than it is to get a naive implementation working. We have a different approach to Cline but it's similar in that it uses things like references and how the developer actually understands their codebase.
I noticed that Sonnet 4 likes to use code search tool in cursor. Probably giving model option of tool to use is not bad thing to do.
[deleted]
Yep. Have definitely been replacing RAG solutions with search+feed the context window instead lately as well.
What does that mean? In what way does "search and feed" differ from "retrieve and augment?" Those are practically synonyms to me - is it about tool use vs prompt crafting?
Correct. RAG is a general term as you describe, but it has become inextricably linked with vector databases in the minds of a lot of people, to the extent that GP and even the blog post we're discussing use RAG specifically to mean the use of a vector database after chunking input to create embeddings.
I agree with you that RAG should be a generic term that is agnostic to the method of retrieval and augmentation. But at the moment, in a lot of people's minds, it specifically means using a vector database.
I agree with you that RAG should be a generic term that is agnostic to the method of retrieval and augmentation. But at the moment, in a lot of people's minds, it specifically means using a vector database.
I’m not an expert here, but isn’t “search and feed the context window” exactly what RAG is?
Like the other comment already said, the search is still Retrieval, and putting it into the context window is Augmenting, and the LLM request leads to the Generation. A.k.a. RAG.
The security argument is a valid one, as long as the prompts aren't passing through Cline's servers but instead directly sent to the LLM providers. If they go through an intermediary step, it's a pretty pointless difference. Yet it's very hard to make money off of a coding assistant where the prompts don't pass through their servers in one way or form. Cline is for-profit and currently their only monetization is to get users to use their credits system, meaning prompts go through them. In other words, if Cline is to succeed and monetize you, the security advantage sounds questionable.
This is a hilariously obvious LLM sentence by the way:
> Your codebase isn't just text – it's your competitive advantage
When creating articles aimed at LLM power users (which this one is), just have a human write it. We can see through the slop. Come on, you're VC backed, if you were bootstrapping I wouldn't even be calling this out.
The other arguments I used to agree with - compression and RAG means loss of quality, increasing context windows and decreasing prices means you should just send a lot of context.
Then I tried Augment and their indexing/RAG just works, period, so now I'm not convinced anymore.
This is a hilariously obvious LLM sentence by the way:
> Your codebase isn't just text – it's your competitive advantage
When creating articles aimed at LLM power users (which this one is), just have a human write it. We can see through the slop. Come on, you're VC backed, if you were bootstrapping I wouldn't even be calling this out.
The other arguments I used to agree with - compression and RAG means loss of quality, increasing context windows and decreasing prices means you should just send a lot of context.
Then I tried Augment and their indexing/RAG just works, period, so now I'm not convinced anymore.
> This is a hilariously obvious LLM sentence by the way:
> > Your codebase isn't just text – it's your competitive advantage
An LLM would have correctly used an em dash, not an en dash. ;)
> > Your codebase isn't just text – it's your competitive advantage
An LLM would have correctly used an em dash, not an en dash. ;)
This is so well-known by now that replacing those is tablestakes :) The ".. isn't just A - it's B" isn't yet to the greater public.
This pattern is so prevalent that in any decent LLM business content generation product you're forced to hardcode avoidance/removal of that phrase, otherwise it's bound to show up in every article.
This pattern is so prevalent that in any decent LLM business content generation product you're forced to hardcode avoidance/removal of that phrase, otherwise it's bound to show up in every article.
Even cline documentation seems to be slop generated.
just coincidentally I saw an excerpt of an recent interview from Swyx when someone made this exact same point. Can't find it but wonder if that's the author and anyone has a link?
the third point is applicable to a number of tools and systems, but who would claim that using git doubles your security surface?
"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
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
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? You'll just have to admit you were wrong and cursor and others were right? I don't get it.
Just say we don't believe RAG is as useful for now and we take a different approach. But tripling down on a technique so early into such a new field seems immature to me. It screams of wanting to look different for the sake of it.
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? You'll just have to admit you were wrong and cursor and others were right? I don't get it.
Just say we don't believe RAG is as useful for now and we take a different approach. But tripling down on a technique so early into such a new field seems immature to me. It screams of wanting to look different for the sake of it.
I build these systems for a living, and I just made a post about why code is different from natural text: https://news.ycombinator.com/item?id=44107379
RAG is useful for natural text because there is no innate logic in how it's structured. RAG chunking based on punctuation for natural language doesn't work well because people use punctuation pretty poorly and the RAG models are too small to learn how they can do it themselves.
Source code, unlike natural text, comes with grammar that must be followed for it to even run. From being able to find a definition deterministically, to having explicit code blocks, you've gotten rid of 90% of the reason why you need chunking and ranking in RAG systems.
Just using etags with a rule that captures all the scope of a function I've gotten much higher than sota results when it comes to working with large existing code bases. Of course the fact I was working in lisp made dealing with code blocks and context essentially trivial. If you want to look at blub languages like python and javascript you need a whole team of engineers to deal with all the syntactic cancer.
RAG is useful for natural text because there is no innate logic in how it's structured. RAG chunking based on punctuation for natural language doesn't work well because people use punctuation pretty poorly and the RAG models are too small to learn how they can do it themselves.
Source code, unlike natural text, comes with grammar that must be followed for it to even run. From being able to find a definition deterministically, to having explicit code blocks, you've gotten rid of 90% of the reason why you need chunking and ranking in RAG systems.
Just using etags with a rule that captures all the scope of a function I've gotten much higher than sota results when it comes to working with large existing code bases. Of course the fact I was working in lisp made dealing with code blocks and context essentially trivial. If you want to look at blub languages like python and javascript you need a whole team of engineers to deal with all the syntactic cancer.
RAG does not just mean similarity search. It means retrieving all relevant content, including the AST dependencies. Whatever you would want to know if you were to answer the query yourself.
Than it must be able to search every book and paper ever written because when it comes to deciding if an algorithm is correct I need to read the original paper that defined it and any updates in the literature since then.
Since that rag system doesn't, and probably will never, exist we are stuck with vector embeddings as the common definition everyone working in the field uses and understands.
Since that rag system doesn't, and probably will never, exist we are stuck with vector embeddings as the common definition everyone working in the field uses and understands.
If you were to do this by hand, would you search every book and paper ever written? That is not feasible so you have to make a trade-off.
For alternatives to vector search, see GraphRAG and AST parsing; e.g., https://vxrl.medium.com/enhancing-llm-code-generation-with-r... or https://github.com/sankalp1999/code_qa
For alternatives to vector search, see GraphRAG and AST parsing; e.g., https://vxrl.medium.com/enhancing-llm-code-generation-with-r... or https://github.com/sankalp1999/code_qa
That's what google scholar is for. Use it to find the meta analysis papers and go from there.
Which incidentally shows why RAG just means vector store + embedding model, since your definition means different things to different people and an implementation can't exist until we figure out AGI.
Which incidentally shows why RAG just means vector store + embedding model, since your definition means different things to different people and an implementation can't exist until we figure out AGI.
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 they are clearly on the right path from direct experience.
That’s not universally true. I’ve had a better experience with Amazon Q than I’ve had with Cline.
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.
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.
>My workflow involves manual copying and pasting from the browser into my own text editor.
Cline with mcp-playwright: https://github.com/executeautomation/mcp-playwright
There is no free tier like other tools, but it's far more transparent in that regard; it uses an Anthropic/OpenAI/etc. API key directly, and your only costs are direct token usage.
The real "aha" moment with this kind of thing is in realizing that the agent can not just use the tool as provided, but it can write scripts to dynamically execute on the page as well. So it's not just going to a page and dumping a bunch of HTML back into the client; it actually analyzes the DOM structure and writes JS snippets to extract relevant information which are then executed in the browser's runtime.
Cline with mcp-playwright: https://github.com/executeautomation/mcp-playwright
There is no free tier like other tools, but it's far more transparent in that regard; it uses an Anthropic/OpenAI/etc. API key directly, and your only costs are direct token usage.
The real "aha" moment with this kind of thing is in realizing that the agent can not just use the tool as provided, but it can write scripts to dynamically execute on the page as well. So it's not just going to a page and dumping a bunch of HTML back into the client; it actually analyzes the DOM structure and writes JS snippets to extract relevant information which are then executed in the browser's runtime.
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.
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.
I agree. This is the golden tool that doesn't get the hype. Well as golden as tools get. Hope they can keep delivering. It seems to hit my personal sweet spot.
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?
What's incredible to me is that it's open source. I've learned a ton about prompting and agent workflows, tool use, etc. from its code.
The post may not be written very well (although it seems mostly fine to me) but it doesn't seem GPT-written at all. Especially as it has obvious typos that LLMs don't make:
> ...and this choice isn't an oversight's a fundamental design decision that delivers better code quality, stronger security, and more reliable results
> ...and this choice isn't an oversight's a fundamental design decision that delivers better code quality, stronger security, and more reliable results
The limitations of RAG / strengths of a more structured (AST) approach for the case of code are spelled out well. Its punchy and too the point. Don't see these issues.
[deleted]