Two kinds of knowledge
GitNexus helps agents understand what’s connected — call chains, dependencies, symbol relationships. It parses the codebase into a knowledge graph and exposes it through MCP tools. When an agent asks “what calls this function?” or “what breaks if I change this file?”, that’s structural navigation.
sourcebook helps agents understand how the project actually works — conventions, constraints, patterns, what to avoid. It analyzes the import graph, mines git history, and infers behavioral patterns. When an agent needs to know “this project uses Vitest not Jest” or “src/types.ts is the hub file with 15 dependents”, that’s project knowledge.
Structural knowledge answers: what is this code connected to?
Project knowledge answers: how should I write code here?
Where each approach shines
“Trace all callers of this function”
GitNexus: graph query returns the complete call chain instantly.
sourcebook: agent uses standard code search (grep/find).
Edge: GitNexus
“Add i18n strings following the existing pattern”
GitNexus: agent can see file dependencies but doesn’t know the i18n convention.
sourcebook: AGENTS.md tells the agent the i18n pattern, which files to touch, and the naming convention.
Edge: sourcebook
“Rename this exported function across the codebase”
GitNexus: rename tool coordinates multi-file changes via the graph.
sourcebook: agent uses standard find-and-replace.
Edge: GitNexus
“Add an API endpoint following existing patterns”
GitNexus: agent can see what existing endpoints connect to.
sourcebook: AGENTS.md specifies the routing pattern, validation approach, and where endpoints live.
Edge: sourcebook
The insight
These approaches are complementary, not competing. Graphs help agents explore a codebase. Project knowledge helps agents decide what to do once they get there.
The failure mode without structural knowledge: an agent makes a change that breaks something downstream — it didn’t see the dependency chain.
The failure mode without project knowledge: an agent writes code that works but violates conventions, uses the wrong patterns, or spends minutes exploring before finding the right file — it didn’t know how the project operates.
In practice, the second failure mode is far more common. Agents rarely break downstream code because most coding tools already have basic dependency awareness. What agents consistently get wrong is orientation: which file to edit, which pattern to follow, what not to touch.
What we’ve observed
We benchmarked different context strategies on real GitHub issues across Cal.com, Hono, and Pydantic. Agents with upfront project knowledge targeted the right files faster and produced more thorough patches. The biggest gains came from knowing conventions and constraints before starting — knowledge agents can’t infer by reading code.
We haven’t benchmarked GitNexus directly yet. When we do, we’ll update this page with head-to-head results on the same tasks. For now, the comparison is architectural: what kind of knowledge each tool provides, and when each matters.
Full benchmark methodology and results →
When to use which
Use GitNexus when your agent needs to trace call chains, understand blast radius of changes, or coordinate multi-file renames via the dependency graph. Best for large refactors, navigation-heavy tasks, and understanding downstream impact.
Use sourcebook when your agent needs to understand project conventions, know which files matter most, and write code that follows existing patterns. Best for feature work, bug fixes, and onboarding new agents to a repo.
Use both when working on a large, unfamiliar codebase where the agent needs both orientation (sourcebook) and navigation (GitNexus). The tools don’t conflict — they provide different layers of the same stack.