Having a separate planning / research phase helps with this. Make the LLM curate a plan by gathering internal and external context. Then execute the plan in another fresh session. Of course if the planning phase itself ends up in the local min then I would just start a new planning session with the learnings.
I think most relevant data that provides best answers lives in GitHub. Sometimes in code, sometimes in issues or discussions. Many libs have their docs there as well. But the information is scattered and not easy to find, and often you need multiple sources to come up with a solution to some problem.
The main reason is that most real blockers are tied to a specific language ecosystem. Even if the high-level ideas transfer across languages, the actual fix usually depends on the language’s APIs, tooling, and conventions. When someone is searching, they typically need something that fits the environment they are working in at the moment.
So the language choice in GitHits mainly steers the system toward code that is immediately usable.
Another part of the story is that finding patterns across languages is a much harder problem. It requires a level of semantic, cross-language search that does not really exist yet in a reliable way. I would love to reach that point, but today the best results come from staying within one ecosystem at a time.
Under the hood, there are several search modes, and not all of them are strictly language specific. The language selection guides the search, but it does not fully constrain it. And at some point, there might be a more generic search mode that is not tied to any single language at all, but that will take more research and iteration.
Thanks! While those languages are not yet "officially" supported, GitHits works with them as well. The results might not be that good as with the ones I have enabled officially since the search and final output is partially steered by the selected language.