The file-first model is ending. Kin is the semantic system of record for AI-native software work.Learn more →
← Engineering Blog

Why I Built Kin

Troy Fortin Jr··
kinopen-sourceversion-controlai

Every developer alive has muscle memory for git add, git commit, git push. Git is one of the most successful tools ever built. It won. So why would anyone try to replace it?

I didn’t set out to replace Git. I set out to solve a problem that Git was never designed to handle: giving AI agents useful context without burning through your entire token budget on irrelevant code.

The Problem

Git tracks lines in files. That model works brilliantly when your primary collaborator is a human reading diffs in a terminal. But the fastest-growing class of code collaborators, AI agents, don’t work that way.

When an AI agent needs to understand a function, it doesn’t want the 2,000-line file that function lives in. It wants the function body, its callers, its dependencies, and maybe the interface it implements. Instead, most agent integrations dump entire files into the context window and hope the model figures out what matters. The result is predictable: wasted tokens, degraded reasoning, and missed connections.

The mismatch runs deeper than context stuffing. When a developer renames processOrder to handle_order and moves it to a new file, Git sees a deletion and an addition. A human reviewer can squint and figure it out. An AI agent? It loses track of the entity entirely. The identity is gone. Every downstream reference is now a mystery.

I kept running into these problems in my consulting work at Firelock. I was building AI-powered systems for clients and watching agents struggle with the same class of failures: bloated context, lost identity, no way to ask “what does this function actually affect?”

Why Existing Tools Fall Short

The natural reaction is to bolt semantic understanding onto Git. That’s what most tools do: RAG-based code search, embedding-powered retrieval, and wrapper scripts that try to extract structure from file diffs.

These tools help, but they are limited by what Git can express directly. A commit hash does not itself answer “what calls this function?” or describe a change in terms of entities instead of line numbers. Vector search can find similar code, but it does not by itself provide the dependency graph or provenance needed to support that answer.

The abstraction is wrong. Files are containers, not concepts. Lines are formatting, not meaning. If you want semantic understanding, you need a semantic foundation.

The Kin Approach

Kin

So I built one. From scratch, in Rust, with no Git dependency.

Kin is a version control system where the source of truth is a graph of semantic entities such as functions, types, classes, and modules, plus relationships such as calls, imports, implementations, and references. Source files still exist, but they’re projections of this graph, not the primary artifact.

This inversion changes everything:

  • Context delivery is graph traversal, not file dumping. Need to understand a function? Traverse supported relationships, pull in relevant signatures, and respect a token budget. The agent gets a bounded, evidence-backed context pack instead of an undifferentiated file dump.
  • Provenance and evidence are first-class. Kin reports what the graph supports, carries source evidence into retrieval and review, and makes gaps visible. Rename-stable identity across arbitrary refactors is still roadmap work, not a promise in the current release.
  • Token budgets are first-class. Ask Kin for context with a 4,000-token budget and it will build the most informative pack it can within that limit, prioritizing by graph proximity to your focal point.
  • Review is about entity impact, not line diffs. When you review a change in Kin, you see which entities were modified and what they affect downstream. Not “lines 47-53 changed in utils.ts” but “the validateInput function’s contract changed, impacting 3 callers and 1 API endpoint.”

Architecture in Brief

Kin organizes code understanding into four planes:

  • Semantic Plane: The graph of entities, relationships, contracts, and changes. This is the source of truth. Backed by KinDB, a purpose-built embedded graph engine I built specifically for this workload.
  • Projection Plane: Source files, Git commits, docs, and other rendered views of semantic state. Files are outputs, not inputs.
  • Execution Plane: Workspaces, validation runs, and evidence capture. Proves that changes do what they claim.
  • Control Plane: Reviews, governance, assistant adapters, and benchmarks. Manages quality and trust.

Parsing is powered by Tree-sitter with 14 parser adapters. A content-addressable blob store (SHA-256 addressed) holds raw source text. The implementation is a multi-crate Rust workspace designed to be embedded, extended, or run standalone.

For the full architectural deep dive, check out the README.

KinDB: The Foundation Layer

KinDB

Early on, I tried using existing graph databases, starting with KuzuDB and then evaluating SurrealDB, CozoDB, Neo4j, and IndraDB. None of them could do what I needed at the speed I needed it.

The problem is specific: code graphs have a batch-write, continuous-read pattern. You parse on commit, then query repeatedly between commits. General-purpose graph databases pay a tax for flexibility I do not need: query language parsing, dynamic schemas, and transaction models designed for many concurrent writers. Kin needs predictable typed graph access, durable snapshots, and retrieval primitives shaped around software entities.

So I built KinDB. It’s a purpose-built, embeddable graph engine in Rust:

  • HashMap-based adjacency lists with compiled Rust queries: no query language and zero parsing overhead
  • Snapshot-oriented concurrency: readers work from immutable graph state while replacement state is prepared separately
  • Full-text search via Tantivy and vector similarity via HNSW, both built in rather than bolted on
  • Incremental indexing: changed inputs update the relevant graph and retrieval state instead of requiring an unrelated full rebuild
  • Cryptographic integrity: Merkle DAG verification detects tampering at the entity level

KinDB is the storage and retrieval engine exercised by Kin’s current snapshot, text-search, vector-search, and daemon-reopen paths. Engine-specific benchmark claims belong with their pinned artifacts in the KinDB repository rather than as floating numbers on this page.

KinDB is Apache-2.0 licensed and usable independently. Any Rust application that needs a fast, typed code graph can embed it without depending on Kin. Details at firelock.ai/labs/kin-db.

What Works Today

Kin is in public alpha. I’m shipping what works and being transparent about what doesn’t yet.

The CLI is functional: kin init, kin commit, kin status, kin trace, kin context, kin diff, kin review, and more. You can initialize a project, parse it into a semantic graph, query entity relationships, build token-budgeted context packs, and review changes at the entity level.

The MCP server works. MCP-compatible assistants including Claude Code, Codex, Gemini CLI, and Cursor can query Kin’s semantic graph for context, impact analysis, dead code detection, and review data.

Git interop works. Import your existing Git history into Kin’s graph, or export Kin state back to Git commits. Adoption is reversible: delete .kin/ and your source files are untouched.

Tree-sitter parsing currently ships 14 parser adapters, with language-specific depth varying by adapter. The live repository documents the exact support surface.

The benchmark harness (kin bench) measures context quality, token savings, and development velocity metrics. I’m using it to prove that the approach works quantitatively, not just philosophically.

The current investor-citable evidence is a pre-registered n=26 Multi-SWE-Bench evaluation on one Go suite, model, and runtime. Kin leads the lexical baseline on symbol F1 (.318 vs .289), span F1 (.326 vs .297), and line F1 (.307 vs .266). File F1 is a statistical tie, not a claimed win. Kin used 1.00x tokens and 0.95x tool calls, and its runs were bit-identical on 26 of 26 tasks versus 3 of 26 for the lexical baseline. This measures retrieval and localization, not patch success. The public proof summary and governing artifacts pin Kin at 2508da69 and kin-bench at 2c9875a.

What’s still hardening: reconciliation edge cases with broken ASTs, semantic merge conflict resolution, multi-workspace coordination, and performance on very large repos. I’m working on it in the open.

What’s Next

The roadmap includes more language support, richer cross-language contracts (OpenAPI, Protobuf, GraphQL, database schema linking), distributed semantic merge, editor integrations, and deeper MCP capabilities for multi-agent workflows.

I’m also investing in native mode, where Kin manages the working directory directly and materializes projections from graph-owned state. On the engine side, startup and persistence work continues, but those performance targets remain roadmap until a pinned proof package supports them.

Try It

Both projects are open source under Apache-2.0, with no strings attached.

Kin: Semantic version control. The CLI, MCP server, parsing pipeline, and everything above the graph engine.

curl -fsSL https://get.kinlab.dev/install | sh
kin setup
cd your-project
kin init .

KinDB: The embedded graph engine. Usable independently if you need a fast, typed code graph in Rust.

git clone https://github.com/firelock-ai/kin-db.git
cd kin-db
cargo build --release
cargo test

Product pages: Kin on Firelock Labs · KinDB on Firelock Labs

If you find rough edges, open an issue. If you want to discuss the approach, join us on GitHub Discussions. If you want to contribute, check out CONTRIBUTING.md.

Git changed how we collaborate on code. I think Kin can change how machines understand it.