Hey HN! I'm Troy.
Over the last six months, in whatever spare time I could find, I've been building Kin. It's an open-source code repository and version control system written in Rust for people and AI agents.
This started because I was paying for coding agents out of my own pocket and kept watching them work out parts of the code we'd already gone through in another session. I tried Markdown notes and instruction files, but the code would change, the notes wouldn't, and the next session would start in the wrong direction. It was frustrating paying to piece the same things back together.
Around the same time, an AJR song came on while I was driving and brought back a whole memory of heading to a high school baseball game. That sent me down a rabbit hole about how we store connections, and I kept coming back to the code: why wasn't more of that structural understanding part of the repository itself?
With Kin, the graph is the repository, not an index sitting next to Git. Functions, types, recorded relationships, and change history are repository data that you commit, branch, and merge. The original source is preserved byte for byte, and filesystem projections let supported editors and build tools work with ordinary files. There's Git import and export for supported workflows too.
The review side matters a ton to me. When an agent changes a shared helper, I still have to work out what else I should inspect. Kin lets me query its recorded callers and follow those connections. The CLI and MCP server query the same graph, so the agent can use it while working and I can inspect it during review.
You can build persistent code intelligence around Git. I wanted to see what changes when those relationships are part of what the repository versions.
Underneath Kin is kin-db, the graph storage engine I wrote for it. Both are Apache-2.0. Local repository queries don't require a hosted account, though installation and the initial embedding model download need network access.
It's still an alpha, so start with a disposable copy of a small, supported repository. Importing brings in reachable Git history, which can take real time and memory. Language and relationship coverage are incomplete, and the graph can miss connections. You still need your compiler, tests, and your own judgment.
Hey HN! I'm Troy. Over the last six months, in whatever spare time I could find, I've been building Kin. It's an open-source code repository and version control system written in Rust for people and AI agents.
This started because I was paying for coding agents out of my own pocket and kept watching them work out parts of the code we'd already gone through in another session. I tried Markdown notes and instruction files, but the code would change, the notes wouldn't, and the next session would start in the wrong direction. It was frustrating paying to piece the same things back together.
Around the same time, an AJR song came on while I was driving and brought back a whole memory of heading to a high school baseball game. That sent me down a rabbit hole about how we store connections, and I kept coming back to the code: why wasn't more of that structural understanding part of the repository itself?
With Kin, the graph is the repository, not an index sitting next to Git. Functions, types, recorded relationships, and change history are repository data that you commit, branch, and merge. The original source is preserved byte for byte, and filesystem projections let supported editors and build tools work with ordinary files. There's Git import and export for supported workflows too.
The review side matters a ton to me. When an agent changes a shared helper, I still have to work out what else I should inspect. Kin lets me query its recorded callers and follow those connections. The CLI and MCP server query the same graph, so the agent can use it while working and I can inspect it during review.
You can build persistent code intelligence around Git. I wanted to see what changes when those relationships are part of what the repository versions.
Underneath Kin is kin-db, the graph storage engine I wrote for it. Both are Apache-2.0. Local repository queries don't require a hosted account, though installation and the initial embedding model download need network access.
It's still an alpha, so start with a disposable copy of a small, supported repository. Importing brings in reachable Git history, which can take real time and memory. Language and relationship coverage are incomplete, and the graph can miss connections. You still need your compiler, tests, and your own judgment.
Code and install instructions: https://github.com/firelock-ai/kin
Pick a function where you already know the callers and see what Kin spits out. I'd love to hear what it gets wrong and whether you'd keep using it.