> But they have to get better at understanding the repo by asking the right questions.

How I am tackling this problem is making it dead simple for users to create analyzers that are designed to enriched text data. You can read more about how it would be used in a search at https://github.com/gitsense/chat/blob/main/packages/chat/wid...

The basic idea is, users would construct analyzers with the help of LLMs to extract the proper metadata that can be semantically searched. So when the user does an AI Assisted search with my tool, I would load all the analyzers (description and schema) into the system prompt and the LLM can determine which analyzers can be used to answer the question.

A very simplistic analyzer would be to make it easy to identify backend and frontend code so you can just use the command `!ask find all frontend files` and the LLM will construct a deterministic search that knows to match for frontend files.

▲

mrits 3 days ago | parent [-]

How is that better than just writing a line in the md?

▲

sdesol 3 days ago | parent [-]

I am not sure I follow what you are saying. What would the line be and how would it become deterministically searchable?

▲

mrits 3 days ago | parent [-]

frontend path: /src/frontend/* backend path: /src/*

I suppose the problem you have might be unique to nextJS ?

	▲	sdesol 3 days ago \| parent [-]
		The issue is frontend can be a loaded question, especially if you are dealing with legacy stuff, different frameworks, etc. You also can't tell what the frontend code does by looking at that single line. Now imagine as part of your analyzer, you have the following instructions for the llm: --- For all files in `src/frontend/` treat them as frontend code. For all files in 'src/' excluding `src/frontend` treat as backend. Create a metadata called `scope` which can be 'frontend', 'backend' or 'mix' where mix means the code can be used for both front and backend like utilities. Now for each file, create a `keywords` metadata that includes up to 10 unique keywords that describes the core functionality for the file. --- So with this you can say - `!ask find all frontend files` - `!ask find all mix use files` - `!ask find all frontend files that does [this]` and so forth. The whole point of analyzers is to make it easy for the LLM to map your natural language query to a deterministic search. If the code base is straightforward and follows a well known framework, asking for frontend or backend wouldn't even need an entry as you can just include in the instructions that I use framework X and the LLM would know what to consider.