- 128comments
- 177comments
- 33comments
- 218comments
- 57comments
- 11comments
- 43comments
- 5comments
- 71comments
- 238comments
- 235comments
- 34comments
- 9comments
- 50comments
- 16comments
- —discuss
- 166comments
- 3comments
- 142comments
- 23comments
- 12comments
- 174comments
- 89comments
- 16comments
- 70comments
- 130comments
- —discuss
- 275comments
- 15comments
- 147comments
A while ago, I realized I kept giving the same advice to teammates and friends when they ran into a programming issue they couldn't easily solve: go to GitHub and look at how others solved it.
There is a huge pool of underused example material across open source. Most problems developers face are not that novel. With enough digging, someone has already solved the same issue in code or at least posted a workaround to an issue or discussion thread.
The trouble is that GitHub search is limited and works only when you already know the right keywords. You also need the time and patience to go through and read all the results, connect information across files, repositories, issues, discussions, and other metadata, and then turn that into a working solution. The same limitations apply to Stack Overflow and other search tools.
LLMs changed a lot, but they did not change this. They do not perform equally well across all programming languages, and their training data is always stale. They cannot reliably show how to combine multiple libraries in the way real projects do. For these and many other cases, they need a real, canonical code example rather than an outdated piece of documentation written for humans.
That is why I started building GitHits. It is designed to handle the work that humans and AI coding agents struggle with: finding real solutions in real repositories and connecting the dots across the open source ecosystem.
GitHits searches millions of open-source repositories at the code level, finds real code and surrounding metadata that match the intent of your blocker, and distills the patterns it finds into one example.
The initial product is in private beta, with MCP support to connect GitHits to your favorite coding agent IDE or CLI.
What makes it different from Context7 and other generic documentation search tools:
- It is built around unblocking, not general search
- It does not require manual indexing jobs
- It works for humans through the web UI and for agents through the MCP
- It clusters similar samples across repositories so you can see the common path real engineers took
- It ranks the sources using multiple signals for higher quality: the selected sources might be, for example, a combination of code files, issues, and docs
- It generates one token-efficient code example based on real sources
It is not perfect yet. Right now, GitHits supports only Python, JS, TS, C, C++, and Rust. More languages and deeper coverage are coming, and I would appreciate early feedback while the beta is still taking shape. If you have ever lost hours stuck on a blocker you knew someone else had solved already, I would love to hear what you think.
The MCP is great! Whenever I don’t like a solution, or my agent is stuck, I say use GitHits and it synthesizes a better solution based on real projects. I’ve had good results with frontend (html, css) and Golang, too.
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.
Really interesting idea, thanks for sharing. When working on new projects, a lot of my learning comes from studying what others have already built so I can reuse patterns around architecture, UX, and product decisions. Those learnings tend to be transferable across tech stacks, so they’re not tightly bound to a specific programming language. Could you share the thinking behind using programming language as the primary way to organize or distill these examples?
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.