Zero-Friction Code Intelligence

Your agent doesn’t understand your code. It reads it — line by line, file by file, grep by grep — but it doesn’t understand it. It doesn’t know who calls authenticate. It doesn’t know what breaks if you change UserSession. It doesn’t know that the function it’s about to delete is the only thing standing between your checkout flow and a null pointer.

So it guesses. It dumps entire files into context, burns tokens on imports and comments and code that has nothing to do with the task, and produces a fix that looks right until you realize it missed three callers in two other modules.

This is the state of the art. Your agent is operating on text, not structure.

---

The problem every agent team hits

If you’re using an agentic coding harness — Claude Code, Cursor, Codex, Aider, or anything else — you’ve already felt this. The agent works well on small, isolated changes. But the moment the task touches multiple files, crosses module boundaries, or involves a function that’s called from twelve places, the agent starts making mistakes.

The root cause is always the same: the agent doesn’t know the shape of your code. It doesn’t have a call graph. It doesn’t know which functions depend on which other functions. It doesn’t know the blast radius of changing a type signature. So it reconstructs that understanding from scratch every time — by grepping, by reading files one at a time, by inferring structure from text. This costs tokens, costs turns, and frequently produces wrong answers.

An agent that greps for a function name gets back dozens or hundreds of text matches — comments, log messages, documentation, variable names that happen to contain the substring. It then has to read each file, decide which matches are actual call sites, and build a mental model of the dependency structure. All of that work is repeated in the next session, because none of it was persisted.

Structural code intelligence eliminates this entirely. Instead of text matching, your agent queries the actual call graph. git-kb code callers authenticate returns five real call sites — not two hundred text matches. The agent reads five functions instead of fifty files. It has complete, correct information about who calls what and what breaks if something changes.

The practical effect: agents that use structural code intelligence produce more accurate changes, touch fewer files, and waste dramatically fewer tokens on irrelevant context. When your agent runs impact before a refactor, it knows the blast radius. When it runs dead before deleting code, it has proof that nothing calls it. When it runs callers before changing a signature, it has the complete list of call sites to update.

This isn’t about making agents marginally better. It’s about giving them the same understanding of your codebase that a senior engineer carries in their head — the kind of understanding that comes from knowing the call graph, not just the text.

---

Introducing zero-friction code intelligence

As of today, git-kb code works on any Git repository. Absolutely no dependencies required.

brew install gitkb
cd your-project
git-kb code index
git-kb code callers authenticate

That’s it. Your agent has a call graph.

Zero dependencies. Nothing to configure. Nothing added to your project. Install, index, query — instant structural understanding of any Git repository.

---

What you get

git-kb code index parses your source files at the AST level using tree-sitter, extracts every symbol (function, method, struct, type, trait, interface, class), maps every call site, resolves imports, and builds a complete call graph. The index currently supports 17 per-language crates: Rust, TypeScript, JavaScript, Python, Go, Java, Swift, Kotlin, Ruby, C, C++, C#, PHP, Scala, Elixir, Haskell, and Lua — with more coming.

Once indexed, you have access to the full suite of code intelligence queries.

Callers and callees

git-kb code callers authenticate

CALLER                          FILE                           LINE
Session.validate_token          src/auth/session.rs            127
Middleware.require_auth          src/middleware/auth.rs          43
CheckoutFlow.verify_user        src/checkout/flow.rs           89
ApiHandler.login                src/api/handlers/login.rs      31
test_auth_happy_path            tests/auth_test.rs             15

This is not grep. git-kb code callers returns the actual call sites from the AST. Every function that invokes authenticate, with the exact file and line number.

For agents, this is the difference between a confident refactor and a broken build. When your agent needs to change a function’s signature, it knows — not guesses — every caller that needs updating.

git-kb code callees works in the other direction: given a function, what does it call? This lets an agent trace execution paths forward, understanding what a function depends on before modifying it.

Impact analysis

git-kb code impact src/auth/session.rs

DEPTH  FILE                              CALLERS
0      src/auth/session.rs               —
1      src/middleware/auth.rs             3
1      src/api/handlers/login.rs         2
2      src/checkout/flow.rs              4
2      src/api/handlers/admin.rs         1
3      tests/integration/checkout.rs     2

Impact analysis walks the call graph transitively. It answers: if I change this file, what’s the blast radius? How many files are affected at each depth?

This is what agents need before any refactor. Not “which files mention this symbol” but “which files would break, and how far does the damage propagate?” An agent that checks git-kb code impact before touching a file scopes its changes correctly. An agent that doesn’t is gambling.

Dead code detection

git-kb code dead src/

SYMBOL                          FILE                           LINE  REASON
format_legacy_response          src/api/legacy.rs              42    no_callers
OldSessionManager               src/auth/old_session.rs        1     no_callers
parse_v1_webhook                src/webhooks/v1.rs             28    no_callers

Zero-caller detection across your entire codebase. git-kb code dead finds every function, method, struct, and type that nothing calls — candidates for safe deletion.

Dead code detection has a well-known false positive problem: framework entrypoints, route handlers, CLI commands, test functions, serde callbacks, and public API exports all look “dead” to a naive caller analysis because they’re invoked by runtime machinery, not by other code. GitKB classifies these separately — MCP handlers aren’t dead code, route handlers aren’t dead code, test functions aren’t dead code. The output distinguishes genuine dead code from symbols that are alive via framework or export conventions.

Symbols, stats, and doctor

git-kb code symbols --file src/auth/session.rs lists every function, struct, trait, impl block, type alias, and constant in a file — with signatures, line ranges, and visibility. When an agent encounters an unfamiliar module, symbols gives it the table of contents before it reads a single line.

git-kb code stats provides a health dashboard for your index: symbol counts by language, resolved versus unresolved call edges, indexing coverage. git-kb code doctor goes further — actionable diagnostics about what’s healthy and what needs attention.

Entrypoints and flows

git-kb code entrypoints identifies the entry points into your system: CLI command handlers, HTTP route handlers, test functions, public API surfaces, main functions. These are the roots of your call graph — the places where execution begins.

git-kb code flows traces execution paths from entrypoints through the call graph — a high-level view of how requests, commands, and events move through your system without reading every file along the path.

Query templates

git-kb code query hotspots
git-kb code query dead-code-explain

Prebuilt architectural queries that answer common questions in one command. Hotspots finds the most-called symbols — the high-fan-in functions that are most critical and most dangerous to change. Dead-code-explain provides evidence for each dead code candidate, explaining why it was classified that way.

---

Spec-driven development, grounded in truth

Code intelligence changes how specs get written.

Without structural understanding, a spec is an educated guess: “we probably need to change the auth module, and it probably affects the checkout flow.” The agent implements that guess, discovers reality is different, backtracks, burns tokens re-reading files, and produces a revision that’s closer but still not complete.

With code intelligence, a spec is grounded in truth from the living codebase. Before writing a single line of implementation, an agent can:

• Run git-kb code callers validate_session and know exactly which 8 call sites need updating — with file paths and line numbers baked into the spec
• Run git-kb code impact src/auth/session.rs and describe the precise blast radius: “3 direct callers, 7 transitive dependents across 4 modules”
• Run git-kb code dead and identify cleanup opportunities that should be part of the change
• Run git-kb code callees validate_session and enumerate every downstream dependency the implementation needs to preserve

The result is a spec that reads like a surgical plan, not a rough sketch. Every claim is backed by the call graph. Every file listed is there because the graph says it’s affected. Every acceptance criterion can be verified against the same structural queries that generated it.

This is what we mean by grounding specs with truth. Code intelligence output lets agents iterate to 100% confidence in how a spec is defined — and that high confidence directly correlates to both a reduction in token usage during implementation and a dramatically higher probability of success. An agent implementing a grounded spec doesn’t waste turns discovering the shape of the code. It already knows the shape. It spends its attention on the actual problem.

---

Built for performance

Code intelligence is only useful if it’s fast enough to be part of every query, every spec, every agent turn. If indexing takes minutes and queries take seconds, agents won’t use it — they’ll fall back to grep because it’s faster.

GitKB’s code intelligence is built in Rust, powered by tree-sitter for AST parsing, and designed for the scale of real engineering organizations. In other words, it is lightning fast — most operations finish in 30ms or less.

Indexing speed. git-kb code index can operate on a single repository or an entire collection of repositories at once. Our own development workspace — 57 repositories of Rust and TypeScript, several hundred thousand lines of code — indexes in 3 seconds. A typical single-repo project indexes in a fraction of that.

Incremental updates. GitKB’s optional daemon watches your files and re-indexes on save with a 500ms debounce. When you modify a file, the index updates in the background — effectively instantaneous. Your agent always queries the current state of your code, not a stale snapshot from the last manual index run.

Query latency. All read operations — callers, callees, impact, dead code, symbols, stats — execute against the precomputed AST graph. Typical response times are under 30 milliseconds. This is fast enough for an agent to query the call graph on every tool call, in every turn, without perceptible delay. Code intelligence becomes ambient — always available, never a bottleneck.

Graph density. On our workspace, a single index operation produces 19,400+ symbols from 2,300+ files, with 170,000+ call sites extracted and 52,000+ resolved call edges in the graph. The call graph resolves trait dispatch, interface implementations, import aliases, and cross-module references — the same graph we use internally to develop GitKB itself, across 17 per-language crates.

---

The bigger picture

Everything described above works today on any Git repository with zero setup. And it gets more powerful from there.

git-kb init unlocks the full knowledge engineering platform: typed documents (tasks, specs, incidents, architectural decisions), a traversable knowledge graph with wikilink edges, git-like commits with full audit trails, and distributed sync between machines and teams.

The power of the full platform is that code intelligence and project knowledge become connected. A task document references the code symbols it affects. An incident links to the commit that fixed it. An architectural decision explains why the code is structured the way it is. Specs reference exact callers and blast radii, grounded by the same code intelligence tools you’re already using. Future agents — and future engineers — don’t just see the code. They see the whole story.

When you’re ready, the upgrade path is one command:

git-kb init

Your existing code index carries forward. Everything you’ve already indexed is preserved. Knowledge engineering builds on code intelligence — it doesn’t replace it.

But the deeper consequence of building code intelligence directly into the protocol is what it does to the knowledge graph itself. GitKB’s graph edges don’t just connect documents to documents — they reach directly into your codebase at the AST level. A spec references a function by its symbol identity, not by a line number that goes stale after the next commit. A task’s blast radius is computed from the actual call graph the moment the task is created. A search for “which documents mention this function?” returns results grounded in structural references, not string matching.

This is a level of technical fidelity that isn’t possible when code intelligence and knowledge management are separate systems. When they share a protocol, documents stay honest — their claims about the code are verifiable against the same graph that produced them. And that fidelity compounds: the more your knowledge base knows about your code, the more precisely agents can plan, implement, and verify their work.

---

Try it

You can feel the difference in about a minute.

brew install gitkb
cd your-project
git-kb code index
git-kb init claude   # or: git-kb init codex

Then ask your agent a question:

“What’s the blast radius of changing the authenticate function?”

“Find all the dead code in src/api/ and tell me what’s safe to delete.”

“Write a spec for refactoring the checkout flow — ground it with callers, callees, and impact analysis.”

Your agent now has structural understanding of your codebase. It will use kb_callers, kb_impact, kb_dead_code, and the rest of the code intelligence toolkit automatically — because GitKB teaches your agent how to use it through the harness integration.

No account. No configuration. No dependencies. Just ask.

If you want to talk to the people building this: Discord.

Read more: Code Intelligence docs · All features · Smarter Models Won’t Save Your Codebase · From Context Engineering to Knowledge Engineering

---

Your agents have been reading your code. It’s time they understood it.

— Matt Walters