Software,
beyond files.
A new way to store and manage code
for people and AI.
AI changed who writes code.
Kin changes what they build on.
If you're like a lot of teams right now, AI is helping you write more code, but the review work keeps piling up. I've felt it myself. The next change arrives before you've finished understanding the last one.
The questions are familiar. What calls this function? What else uses the code I'm changing? What context should the next person or agent have before they touch it?
I'm building Kin around a simple idea: the repository should keep the connections we need to answer those questions.
Kin keeps code, the connections it finds and change history together. People and AI can use that record when deciding what to change next.
A function is something you can ask about. A recorded call is something you can follow. The code and its connections belong in the same repository record.
Keep the code
and its connections
together.
One repository record.
Different ways to work with it.
These are the connections
inside Kin itself.
The artwork flowing through this page comes from the public repository graphs of Kin, KinDB, KinVFS and Kin Editor. Every point represents a captured entity. Every line follows a returned relationship.
The connections are recorded.
The space and movement are visual choices.
About these captures ↓
Give the next step
a better starting point.
Before changing a function, inspect the callers Kin has recorded. When an agent needs context, let it query code and relationships through MCP. During review, use that record to identify connections worth checking alongside the diff.
Those are the workflows Kin is built to support. They still need judgment. A recorded connection is evidence about the code. An empty result is not proof that nothing depends on it, and a graph does not establish that a change is correct.
Git already has a graph of commits, trees and blobs. Kin puts named code and resolved relationships into the repository model itself. Existing projects need a path in, too: migration, Git coexistence and familiar file views are part of making that transition practical.
AI shouldn't have to
reconstruct the software
before it can improve it.
Open source.
Early. Ready to evaluate.
Kin is available as a public alpha under Apache-2.0. It includes the local repository foundation, CLI, daemon and MCP server. Start with a disposable copy of a small, supported repository and compare its answers with code you know.
Building and maintaining the graph has real costs in time, memory and storage. Coverage depends on the language and repository. Some workflows still have gaps. Our proof page records specific runs and their failures, and the documentation describes the supported path today.
- Kin
- Open-source local foundation
- Public alpha
- KinLab
- Hosted collaboration being built on Kin
- In development
KinLab scope is agreed individually. The local alpha does not establish hosted production readiness.
I want to hear where the record helps, where it misses a connection, and what would make it useful in your actual workflow. That's how we build the next version.