Code search and indexing

[tarjeir]

I've been using Codecompanion.nvim about six months and find it to be the most flexible AI plugin for Neovim, providing an excellent experience overall. However, I believe it could benefit greatly from implementing code base indexing. This feature, present in tools like Aider and Cursor, allows for a more context-aware AI assistance, which is crucial for working with large projects. Just now I do, and I find myself often jumping to one of the mentioned tools to perform refactors and improvements. Adding this capability would significantly enhance Codecompanion.nvim's already impressive functionality. I know Aider is using ctags and it is quite impressive. What do you think?

[olimorris]

Ahhh yes. It was something I mulled over for many months. I wrote about this in my "essay" when I introduced workspaces. My findings aligned to that of the author of this awesome blog post:

Every few days there’s a new “AI-powered IDE” on Product Hunt. They’re solving the wrong problem. Making code suggestions without deep context is like having a brilliant junior dev who just joined yesterday - they’ll write clean code that subtly breaks everything.

The key isn’t better code generation. It’s better code understanding.

That's why I went the direction I did with workspaces and opted against implementing indexing. And tbh, it's paying dividends in CodeCompanion. I'm in the middle of refactoring workflows and it's been brilliant. It feels like the LLM has a much deeper understanding of my work than if I'd have just shared 10+ files with it.

I think an indexing solution could have a place in the plugin, however it would need to be able to generate something akin to a workspace file / context management system output. I know Aider also uses Tree-sitter to build up a map of a repo which is very similar to the /symbols slash command output. My issue again with that is there's no associated context. You're leaving it to the LLM to fill in the blanks.

The downside of the approach that myself and the blog author have taken is that users need to invest time to curate the workspace file. For some in 2025, that's an activity they probably can't be bothered to do 😆.

[tarjeir]

That blog post resonates strongly with my own experiences. I've found myself crafting tailored prompts for specific modules in my codebase, creating a tight coupling between prompts and code structure. However, I've noticed limitations as the codebase expands, particularly when it comes to refactoring and integrating tests. Asking the LLM to analyze file-based prompts struggle to capture the full context when dealing with cross-module interactions. Most models are quite easy to confuse. Refining the approach, I'd suggest:

Identifying core files: Pinpointing the main entry points for the module or code section targeted for changes.
Feature-based change grouping: Categorizing all related functions and classes (and their locations) that interact with the target module, both inbound and outbound.
Architectural modeling: Constructing a high-level mental model, potentially using a graph representation.
Focused implementation! Go

I believe this could be implemented in various ways, leveraging workspaces and code analysis like ctags. It is maybe not an easy feat and most likely will not be compatible with all languages.