troyjr4103
Joined 7 months ago
Karma
5
Submissions
11
Member since
Mar 13
Recent submissions
Comment · 3 days ago
Congrats on the launch, this is a great one!!
I work on agent tooling on the software side, and the pattern you describe is exactly what we see there too. Generation got fast and cheap. Validation stayed slow and human. In software the review queue became the bottleneck.
In firmware it sounds worse, because the queue was a physical board!
Curious how you triage the gaps your validation rigs find. When the sim and the board disagree on timing, how do you decide which one is wrong? And how often is it the board setup rather than the model?
Good luck today, rooting for you!
Comment · 1 month ago
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.
Comment · 7 months ago
Author here. Kin replaces Git's file-and-diff model with a graph of semantic entities (functions, types, modules) and their relationships. The graph is the system of record. Files become projections.
The motivation: AI coding agents waste enormous time and tokens reconstructing code structure from files. Kin gives them a graph they can query directly via MCP. Token-budgeted context packs instead of file dumps.
Validated benchmark across 10 popular repos using Codex CLI: 69/70 wins, 50% faster, 45% fewer tokens. Randomized planted artifacts with automatic validation. Full methodology published in the repo.
It's alpha. I ship what works and am transparent about what doesn't yet.
Happy to answer questions!
[email protected]