AI assistance disclosure: This article was drafted with the help of Claude. All technical content, design decisions, code references, and screensh...
For further actions, you may consider blocking this person and/or reporting abuse
I built something similar at some point, started off with just a roslyn script for dependency graphing, into a mermaid graph. Switched to Neo4J, then wrote a custom graph db. Purely so the AI can understand relations and cause and effect. Didnt hurt that with a constraint metric let it generate integration and unit tests... So stripped the graphing, but kept the roslyn and added more boilerplate removal, rule enforcement, simplified initialization, performance optimization, translations and called it V.A.L.I.D.
Interesting trajectory — that's a lot of graph DB swapping. We went the other direction and kept everything in BigQuery from the start: the data volume doesn't really justify a dedicated graph DB (the whole monorepo fits as a few tables with edges modeled as joins), and once BigQuery Graph (still preview) hits GA, the traversal speed gap should mostly close.
The constraint-metric-into-test-generation angle you mentioned is interesting — that's an axis we haven't really pushed yet.
Graph DB's are interesting, because while they all do the job, some do some jobs better. Especially when it comes to additional detail. Eg. mapping every method and variable in a codebase, then cross-referencing their interactions, method of interaction, functional modifications and state-tracking across hidden layers, you deal with quite a long path, instead of just 'this is front end, this is backend, for this item', which is where it becomes a case of how much info is enough for you and how many layers do you want (i.e. keep it low context for initial load, followed by deeper context on query), for when you want to use a LLM to suggest changes. Then wiring in a MCP and skills file, so the LLM doesnt need to trace it step by step, it's just A-Z pathfinding across the graph db, following all the vectors and map constraints for each step, to see what might break it. (a bit of what I built into the software foundry).
The MCP-as-conversation-partner direction overlaps with what I wrote here: dev.to/ryantsuji/graph-rag-isnt-a-... — we let Claude Code orchestrate 10-20 tool calls per session against the graph, with each response embedding "next move candidates" so the agent pathfinds without a hand-coded trace.
The layered loading you mention (low context initial, deeper on query) is something we don't do explicitly yet — per-call granularity stays flat. That's an interesting axis worth thinking about.
I made a custom MCP system, where it queries the tool, with a LoD, so it can reference how much context it needs for the call, which tied with an efficiency scorer (success:token draw), so it can see what LoD is the sweet spot, it dynamically adjusted it's requirements as it needed to for the task I gave it, so it doesnt need repeated tool calls to achieve the goal. When combined with a scripting tool, to build a flow, it works really well.
This is a strong argument for using static analysis as a source of grounded edges rather than just dumping more code into a model context.
The boundary-node idea is the key part for me: API, DB, and event edges need provenance and freshness so an agent can ask “what do I know, how was it derived, and where might this graph be incomplete?”
That makes the graph useful as an inspection surface, not just retrieval context.
That's exactly the framing I want to push toward. Today the closest we have is a daily boundary-analysis cron that compares connection rates day-over-day — it catches a class of staleness ("a parser fell behind a new pattern, a whole API class went invisible") but it doesn't yet give the agent first-class provenance per edge.
The piece I'd most like to layer on top of that is dynamic analysis — production execution counts per edge — so the agent can distinguish "edge exists in static analysis" from "edge actually fires N times per day in production." That turns the graph from "what could be called" into "what is actually called," with dead-code edges visible as a separate signal. Not covered in Part 2 — still on my circling-around list.
The recall math is the part that justifies writing a fresh parser for every framework. People wave off "90% is fine," but once you're walking three or four hops, 0.9 per hop quietly turns into a coin flip, and for tracing what a change breaks, the missing link is the one that causes the incident. I also appreciate that you named the entry point problem instead of hiding it: the graph is great once you know where to stand, but finding where to stand from a vague bug report is still a grep. I'm curious whether Part 2's SPG layer is mostly aimed at that, since it feels like the thing standing between this and asking the graph in plain English.
Yes — SPG (Part 2) is exactly aimed at that entry-point problem.
The shift is: instead of extracting structure from code (where you have no semantic anchor to land on), you write the intent into the code as JSDoc tags — what the function is for, business context, stack — and vectorize that into the node. "The subscription fee calculation for members" then lands you on the right function without knowing its name.
The catch is the annotations have to actually exist at scale, which only works if AI is writing them and AI is reviewing them. But once that pipeline runs, the entry point becomes a semantic query rather than grep + inference.
(And yeah — the recall math is the actual justification for the per-framework parser work. Walking a graph isn't worth doing if each hop is a coin flip.)