Kin Introduces a Graph-Native Repository for AI-Written Software

Summary

Kin is a public-alpha code repository designed for software written by people and AI agents. Instead of treating files and changed lines as the primary repository objects, it stores a graph of code entities, relationships, exact source, changes, and provenance; files remain projections so existing editors, compilers, build systems, and Git workflows can continue to work. Its purpose is to preserve structural context across tasks and agents, allowing reviewers to inspect the likely impact of a change without reconstructing the repository from scratch. The local CLI can import a complete reachable Git history with `kin init`, build semantic entities and relationships for supported languages, and answer locate, reference, trace, and impact queries from the graph. The graph must be built before agent tools are useful, and embedding is a separate step for local vector similarity. In a documented ripgrep example, Kin traces callers and downstream entities affected by a one-line signature edit before a compiler runs; the article says this demonstrates impact analysis, not correctness, which still depends on compilers, tests, and human review. Kin also includes a daemon, bundled MCP server, VS Code extension, graph-backed filesystem projection, advisory review tooling, and an agent runner that can use OpenAI-compatible endpoints. The core is open source under Apache-2.0, while KinLab is a separate proprietary hosted collaboration layer. Git remains an import and export boundary during adoption, while Kin becomes authoritative for its own history, refs, tree state, and semantic relations. The alpha has substantial constraints: indexing long histories can require minutes and substantial memory, embedding downloads roughly 522-523 MB, semantic coverage is limited to listed language adapters, relationships can be incomplete, Windows support is early, and repositories with submodules or Git LFS are refused. Review is advisory rather than merge-blocking, and the article cautions that published benchmark evidence is limited in scope and should not be generalized beyond its stated proof package.