i originally got into this because i wanted a better way to figure out what a code change might affect. callers, tests, related files, all the stuff you end up digging through a repo to find. i was already pretty deep into it before i properly looked around and realized how many similar projects existed. apparently there's a whole category of tools for this, and i had missed most of it when i started. at that point, just having another code graph didn't feel like much of a reason to keep going. the question i got stuck on was whether the relationships in the graph were actually right. so i've been testing that part pretty heavily with Ripplet, a local code graph that coding agents can query through MCP. i compared its call relationships against compiler-generated SCIP indexes across 12 repos. 77,408 call sites in the comparison, 92.3% recall, and zero incorrect call edges among the ones it claimed. the important bit is that it doesn't just make up a relationship when it can't resolve one. those end up marked UNVERIFIED that means it can still miss things, especially with dynamic dispatch and runtime behavior, but at least a guess isn't presented as a fact. i also tested it with Haiku 4.5 on rename tasks across 13 repos. with Ripplet, 13/13 completed correctly; without it, 12/13. total cost was $0.81 vs $1.82, with 85 vs 420 agent turns. these are my own tests, obviously, and the sample isn't huge. i'm still trying to find cases that break the approach rather than just collecting numbers that look good. the code and the test details are here if anyone's curious: https://pypi.org/project/ripplet/ https://github.com/sh4-p/ripplet how are you guys testing whether a code graph is actually useful to an agent, beyond just asking it questions and seeing whether the answers look reasonable?   submitted by   /u/sh4rkwav3 [link]   [comments]