zed
zed copied to clipboard
AI Assistant should have embedding context of the entire codebase
Check for existing issues
- [X] Completed
Describe the feature
For complex projects, expkicitly adding code context of relevant files becomes insufficient since changes and context gets too distributed and out of direct coverage and Assistant's suggestions have reduced marginal utility.
Continuously updated code context embeddings always available to chat assistant solves this problem.
If applicable, add mockups / screenshots to help present your vision of the feature
No response
I still hop between Cursor and Zed for this very reason. The full codebase indexing capabilities of Cursor are invaluable in a large codebase where one person can't understand / know where things are at. It makes my entire team way more independent than they would otherwise be.
I've reached the point with Zed and ollama that I now need the editor to have more context about what I'm talking about.
Please take a look at integrating swiftide. It's specifically designed for this task.
It would be huge if all rustdocs, posix man pages, code from dependent crates, and previous code revisions from the git history were searchable in a vector db for providing query context.
Same here ! It is the missing feature for me
I believe this is the most important but overlooked feature for Zed editor to become a effective meaningful AI-native editor.
Exact same thing, always coming back to Cursor for that and their Composer feature, even when my heart wants me to make the full switch to Zed, Why is this so low in the Requested features ? it genuinely feels like the most important
This is definitely necessary. A lot of newer models like Gemini 2 can handle a lot more than a full code base. Manually adding individual files is too cumbersome
Man I really love Zed but have the same issue. A lot of the time I need codebase context + full docs from specific libs = better outcome
Not sure if it's the same as Cursor's automatic (ctrl + enter) full codebase context but in Zed if adding let's say a '../src' folder from working codebase with the help of /file command in assist then it seem's to have a similar full codebase aware (source files folder) context ready to be used.
I created a tool for this. It will generate codebase.md file which you can then add it to zed's context with the /file slash command
bunx codebasemd
Configure it
bunx codebasemd --help
https://www.npmjs.com/package/codebasemd https://github.com/enzojs/codebasemd
@enzojs this won't generate the embeddings, caching etc.
Plus one here, it's what I'm missing, as a recent returnee to Zed from Cursor.
Is this part of work under development? I'll really like this feature. Maybe I could help develop this, is there any part of zed development work related to this feature?
anybody know if this is currently in dev ?
would be amazing
It seems to me this is part of Agentic Editing, isn't it?
This seems to me to be solved by the latest AI assistent release, right?
@bittelc, I couldn't find any mention of indexing the code base using embeddings in the May 7th blog post you linked to.
The latest release at the time when you posted your comment must have been either 0.186.7 (May 14th) or 0.185.16 (May 12th). I can't find code base indexing related items in the change logs.
Also @pantierra, the page you linked to on Agentic Editing specifically states
Automatic context discovery
The agent can search your codebase for what it needs; no need to manually specify context or wait for indexing.
Am I missing something – do latest Zed releases actually index my code using embeddings?
Is there any update on this, as it seems like the code is being indexed? @notpeter
I'm also curious why this was closed as completed, as it does not seem to be implemented. The blog post @bittelc linked seems to imply the developers do not think indexing is useful, but the larger a codebase becomes, the more useful indexing also becomes. Without indexing, the agent just guesses as to what filenames seem relevant, or greps for search terms that it thinks would be relevant, the same as a human would do. This can be inaccurate, which leads to it becoming more time consuming because the agent has to check multiple files and run multiple grep calls, and tool calls are expensive. Codebase indexing using a specialized LLM model for embeddings enables semantic search, the agent does not have to guess the exact terminology that is used, it can search for related terms and the codebase index will retrieve the relevant code locations.
Interestingly, it seems some work was done to implement this a year ago in https://github.com/zed-industries/zed/pull/10329, but all calls to the semantic_index crate appear to have been removed at some point between then and now.
Yeah this is not implemented. Seeing wasted tokens at work @notpeter why closed? or is this not planned?
Can this be reopened
Can we reopen this issue please?
I take it back. Did some testing and there's no proof embedding beats regular grep. Seems like the best solution is a bit of both or like cognition did recently make agentic search go burrrrr
175 likes on the issue itself seems like something people really want. I am interested in where to draw the line though as this feature could possibly be realised with a mcp server too
I take it back. Did some testing and there's no proof embedding beats regular grep. Seems like the best solution is a bit of both or like cognition did recently make agentic search go burrrrr
is this in terms of performance or token usage? At least the reason I want this feature is that it will use less tokens.
is this in terms of performance or token usage? At least the reason I want this feature is that it will use less tokens.
For accuracy. Vscode found the wrong file most times zed found the correct file bit of course used more tokens. e.g vscode will jump to /UI and search from there while zed will search full codebase. But of course you can manually steer zeds agent to the right place
I see thanks for sharing the results and doing the testing. Although there might be a slight difference between vscode and cursor performance due to they are using different indexing at least I think. I am not sure so please do not take my word for it.