KIT is 100% FREE

A local code-intelligence knowledge graph for your AI coding agent.

Give your AI agent a structured, deterministic map of your backend so it knows where to look and spends less tokens and context guessing.

npm i @kerno/cli

Documentation

Setup in 60 seconds | Works with any code AI code agent

Deterministic SCIP index

Get compiler-level accuracy on types, call targets, and interface implementations.

Pre-built dependency graph

Query the full call chain across modules in a single tool call without expensive exploration.

Full blast radius discovery

Understand the exact risk of every code change, by seeing everything it affects.

HTTP framework agnostic

Discovers how your codebase uses HTTP libraries from the index itself.

Detect all service dependency

Identifies which internal and third-party services the codebase depends on.

Stays current with your codebase

Index updates automatically on every commit.

Product

Agent Kerno Intelligence Tools (KIT)

Docs Blog Pricing Log in

npm i @kerno/cli

FAQs

Frequently asked questions

Got more questions? Drop us a message on Discord.

Does Kerno copy or download my codebase?

No. Your code never leaves your machine. The codebase index is stored locally, and your code runs in a secure, isolated environment during testing. Your code remains completely private and inaccessible to anyone, including our team.

How does the indexer understand a repository's structure?

Build tool analysis is a first-class concern. Rather than relying solely on file layout heuristics, the indexer leans heavily on your build configuration to infer how a project is structured, what it's built with, and how its internal packages and modules depend on one another.

Does Kerno use SCIP's single protobuf file format?

The index uses a text-based format with one file per indexed source file. This is less convenient to work with than a single binary blob, but it scales with the codebase rather than duplicating it. Git handles garbage collection and compression naturally.

The practical upside is that subsequent indexes are tiny diffs, meaning you can retain a full history of indexes across your commit history without meaningfully multiplying storage costs.

Does the index include hover docs or inline code snippets?

No. There's no support for short code snippets of the kind you'd see in IDE hover tooltips. The focus is entirely on symbols — specifically making a codebase's symbol graph queryable by agents, not on enriching the editing experience.

What are the limitations of KIT?

KIT is new, and without real-world usage feedback the honest answer is: we don't yet have a clear picture of where it breaks down across the diversity of projects in the wild. Beyond that known unknown, two concrete limitations exist today.

First, KIT is tied to git, it assumes a git repository and leans on git's own machinery for storage and history.

Second, indexing is not yet incremental; the groundwork is there, but currently a full re-index is required each time.

External packages, the compiler knows the package is real (it's installed, it resolves), but it only sees a reference to a type inside it, not the type itself. The indexer never actually read that package's source.

To verify SomeType is real, you'd have to index all of langchain too — and all its dependencies, and so on. That's the rabbit hole that makes indexing slow. Instead, the system trusts: "the package is real, and we'll take the type reference at face value."

‍So the mental model is: package identity is verified, type identity inside external packages is assumed.

Can KIT cross-reference multiple microservice repos?

In principle yes, but nothing along these lines has been designed or researched yet. It would require the other repository to be reachable at index time, plus a mechanism to declare which packages correspond to that external repo. Given those conditions, cross-repo symbol navigation would be technically feasible, it just doesn't exist today.

How is KIT different from a SCIP index?

See the earlier question on index format for a full breakdown, but the short version: KIT is text-based and per-file where SCIP is a single binary protobuf; KIT leans on build tool analysis where SCIP relies on language-server output; KIT is designed specifically for agent queryability rather than IDE tooling; and KIT deliberately skips third-party packages, whereas a SCIP index typically includes them.

How do I scale this to all my engineers?

KIT data lives inside the git repository itself, so it distributes exactly the way code does — clone, pull, fetch. That said, it is invisible to most git tooling by default and won't propagate between teammates unless it's explicitly included in a push or fetch. The practical way to handle this is via a git hook, or by having Kerno's agent manage synchronisation as part of its normal operation.

Does KIT update as my code evolves?

It updates on demand whenever you explicitly run the indexer. Indexing is not yet incremental, so each run re-indexes rather than patching the previous result. In practice this is less painful than it sounds: if you're committing frequently, running the indexer on each commit keeps the index continuously current, and because subsequent indexes produce small diffs the overhead stays low.