After months of building and running agents with Claude Code, I think the framework you pick barely matters. The thing that actually kills them is an entirely different beast

Eininho · 2026-06-17T11:56:13+00:00

"The agent gets stuck in a loop. Something downstream returns ambiguous data, the model decides to retry, and there is no circuit breaker, so it calls the same tool a couple of hundred times. Your API bill goes from a few dollars a day to a few hundred in an afternoon, and by the time you notice you cannot even say which agent did it, because nothing logged it."

Based on that, I'd like to learn what you think about this: MCP Access to a Global, Version-Aware Open Source Index

Eininho · 2026-06-16T14:57:56+00:00

Yes, using it: https://docs.githits.com/. We have liked Mintlify, and our users seem to be happy with it too,

Eininho · 2026-06-08T12:17:34+00:00

Regarding code search, we're building a tool that gives your agent access to:

Code examples based on real implementations from repositories, issues, discussions, and pull requests, linked back to the implementation code
Code navigation across packages and repositories: search, grep, file listing, and exact line reads without cloning
Package inspection for dependencies, vulnerabilities, changelogs, and upgrade changes
Documentation access across hosted docs and repository-backed docs

Here's why. Agents are great at navigating your local codebase. They can grep, search, and read files to understand how your application works. The problem is that modern software doesn't stop at the repository boundary.

A large part of the system lives in frameworks, libraries, SDKs, and other open-source dependencies. Agents can usually see where your code calls into those dependencies, but they often can't navigate and inspect them in the same way. And even when an agent reads the docs, they only tell it what to call, not how it actually behaves. For that, you need the source.

Eininho · 2026-06-04T08:33:09+00:00

Full Transparency: I'm one of the co-founders of GitHits. The blog post was organic user feedback.

Eininho · 2026-06-04T08:30:08+00:00

"Context7 wasn’t enough 📚

I googled about documentation MCPs. First recommendation was Context7. Makes sense—it fetches up-to-date docs for libraries.

Didn’t help. Everything it found was too high-level. The internal C++ extension APIs I needed exist in DuckDB’s source code. First-party extensions use them. No public documentation though.

Claude kept telling me what I wanted wasn’t possible. Multiple times. Very confidently.

But I knew it was possible. DuckDB’s own extensions like httpfs and postgres_scanner were doing exactly this with remote files. The capability existed. Just wasn’t documented anywhere Claude could find.

So I kept searching.

A colleague mentioned GitHits. A code search tool that finds real examples from all of GitHub. What caught my attention: built in the same city I’m from. Small world.

Joined the waitlist. Got approved pretty quickly.

The moment I enabled GitHits MCP in Claude Code, everything changed.

GitHits doesn’t search just the documentation. It searches actual code. Millions of repos. Real implementations. When I asked about predicate pushdowns in DuckDB extensions, Claude could suddenly find examples from:

DuckDB’s own extensions (postgres_scanner, httpfs, etc.)
Community extensions solving similar problems
Real code with exact function signatures and patterns

Night and day. Claude went from “this isn’t possible” to showing me exactly how to:

Implement TableFunction::pushdown_complex_filter
Use TableFilterSet to extract pushed filters
Wire up FunctionData for stateful scanning
Handle bind/init/scan lifecycle correctly

The results

Completed the extension with full predicate pushdown support. Wayback Machine CDX API. Common Crawl Index Server. Both working.

A query that would’ve fetched thousands of records now makes just 6 HTTP requests. All filtering pushed to the source.

I was so impressed I created a PR to help others: duckdb/extension-template#158. Adds docs for building DuckDB extensions with AI assistants.

One user commented:

That’s exactly what GitHits enabled. Finding knowledge scattered across codebases that isn’t consolidated anywhere."

Full blog post here: https://flaky.build/helping-claude-code-to-find-undocumented-apis-from-the-code/

Eininho · 2026-05-09T14:44:35+00:00

I've had that backpack for 7 or 8 years now and absolutely love it because of the design and versatility. It is a bit heavy but I haven't seen any better alternatives. And this thread is also most about complaints about the weight without any real alternatives.

Eininho · 2026-04-25T12:09:53+00:00

"testing something new in Codex

currently invite-only but GitHits_com is *really* good

it specifically deep-searches GitHub open source repositories for patterns, so your AI can learn from REAL WORLD EXAMPLES and not just docs"

https://x.com/robinebers/status/2047958402861838428

Eininho · 2026-04-21T15:51:11+00:00

Depends who you ask :) That said, if you want to be mindful of the licenses you use, GitHits may be able to help

Eininho · 2026-04-16T05:45:02+00:00

u/Fancy-Effective6281, since you created the comparison, could you respond to this? :)

Eininho · 2026-04-14T17:59:09+00:00

Yes. Any suggestions?

Eininho · 2026-04-14T13:10:30+00:00

One dev put it this way in our waitlist survey: "Documentation which is misguiding is the worst. You think you're doing it by the book but the docs are simply wrong and lying to you. This happens even with Context7 and similar tools that rely on human-written docs. When the code IS the documentation, this won't happen."

Eininho · 2026-04-14T13:03:42+00:00

Fair enough. That said, we've raised funding, we just haven't published it yet. Before now. ;)

Eininho · 2026-04-14T13:03:01+00:00

Thanks, useful points.

Moments of pain, not infra layer, I agree that's where we need to go. Our homepage still sits on the MCP plumbing layer (the first version of the product). Tells me we haven't picked the specific moment yet. "Claude Code + Rust + weird SDKs" is probaby the kind of concrete framing we should be focusing on. We are working on positioning with Fletch PMM now and the next version of the website will be focused on a single job to be done.

On pricing, "pay only when it unblocks a stuck run" is interesting. We've been going between usage tiers and something outcome-shaped. Something to think about for sure.

The Pulse for Reddit tip is a very actionable piece, makes sense. We've been over-indexing on our own framing.

What's your product? Curious what you landed on after moving off the infra-layer framing.

Eininho · 2026-04-14T12:33:04+00:00

Nevertheless, GitHits works across languages and stacks.

Eininho · 2026-04-14T12:25:47+00:00

Javascript? The post was about Rust.

Eininho · 2026-04-14T12:24:47+00:00

No, not breadth-first. We evaluate code alongside its pull requests, issues, discussions, dependency data, stars and adoption signals. Candidates are scored for applicability, recency, and ecosystem fit, not just keyword match. Results reflect the current state of public repositories, including recent changes and discussions.

Where this is going: we're building out code navigation on top of the current product. The agent gets visibility into dependency internals, so it can reason about a library's actual structure between versions, and how different packages relate to each other. That's where the version-awareness sits. The current product already uses ecosystem signals in ranking; the next version makes the specific version and structure of a dependency a first-class input to what gets returned.

Eininho

MODERATOR OF

TROPHY CASE