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!

Comments URL: https://news.ycombinator.com/item?id=50289830

Points: 1

# Comments: 0

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.

Comments URL: https://news.ycombinator.com/item?id=49636442

Points: 3

# Comments: 1

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!