Loading today’s stories
Product1 distinct publisher3 min readPublished
Engineering orgs say 30% to 75% of their new code is machine-written, which moved the expensive work from writing to reading, and Vitali Avagyan's answer is to parse the repository into a graph you can query.
The Product Desk · Product desk
Compiled by The Product DeskSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
product
On-device inference turns a phone's temperature into a release-gating variable1 distinct publisher
build
The number a graph benchmark won't print: 740 of 744 operations failed at 40 clients1 distinct publisher
build
A five-way graph database benchmark spent its first four hours measuring undersea cable1 distinct publisher
build
A CognoDB-side benchmark puts the vendor mid-pack, and ships the repo so you can check1 distinct publisher
An engineer about to rename a service asks the assistant which functions call it, and the assistant does what it does: searches for the string and reads back whatever the match window contains. Teams describe that as the agent reading the codebase [5]. It is a text search with a token budget attached.
The class of question that breaks it is structural. Avagyan's example is asking for the longest nested function call in a repository, which today's agents attempt by searching imports and invocations and then counting, a task LLMs handle badly [6]. With relationships between methods and functions already stored as a graph, he says, the same answer comes from a Cypher query in milliseconds, and both tokens and wall-clock time go down [7][8]. The same logic applies to semantic search, which returns functions whose names look close to your query without being the thing you asked about [14].
The interview contains no measured comparison. The evidence offered is the creator's own experience that on some problems his harness finds solutions faster and more accurately than the ones he uses beside it [11], which is a hypothesis you can test on your own repository, not a result you can cite in a planning doc [18].
That adoption figure deserves the same scrutiny. Engineering orgs self-report that somewhere between 30% and 75% of their new code is machine-written [2]. That range is 45 percentage points wide [17], which tells you the industry has no shared definition of what counts. Either end has the same consequence for staffing: the expensive activity moved from writing to reading, for new hires and for the agents [3].
The cost of entry lives in the build, not in installing a plugin. Tree-sitter gives you the syntactic relationships from the abstract syntax tree, and Avagyan says that alone is not enough because languages and frameworks vary too much, so precise mapping needs a correct build per framework and language [12]. He also tried the shortcut of having an LLM produce the graph in one pass and got hallucinated edges and nodes, which is why the parsers do that work [16]. If your monorepo is two languages with a clean build, indexing is an afternoon. If every service builds its own way, the graph is a platform project.
To size this before committing, take the questions your team asked the repository last week and sort them on two axes: does the answer come from a name match or from a relationship (call graph, inheritance, cross-service dependency), and is it asked once or every week. Name match asked once is what grep is for, and keeping grep is Avagyan's own recommendation, alongside semantic search, with the model choosing per question [9][15]. Relationship questions asked weekly are the only quadrant an index pays for, and the number to record there is not tokens saved in a demo but time to a first correct answer and how often the answer needed correcting. If that quadrant has fewer than three real entries, the index can wait a quarter.
Ranked by verification strength, evidence, and original report placement.
Avagyan says graphs and text search are not exclusive: grep, other types of search and graph search can run together, and given both contexts the AI decides which way to go.
Avagyan says precisely mapping codebases to graphs requires a correct build for each framework and programming language, and that Tree-sitter, which parses the abstract syntax tree and gives syntactic relationships, is not enough on its own because of the variety between languages and frameworks.
The project supports semantic search as an add-on for things like code comments, and in practice graph parsing and semantic search tend to be complementary.
Avagyan found that asking LLMs to one-shot graph representations did not work because they hallucinated some relationship edges and nodes, so the project uses Tree-sitter parsers for different languages instead.
Heavybit published an article by Andrew Park titled "Is the Key to Understanding Code Treating it as a Graph?"
Developer Vitali Avagyan argues the key to understanding code, particularly across different languages, is to stop treating it as lines of plain text and treat it as a relational graph, which is the basis of his open-source project code-graph-rag.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 27, 2026
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One interview, maker narrating
Split the story in two and the halves score very differently. How the graph is built — per-language Tree-sitter parsers, one unifying ontology, runtime call edges merged with static ones, LLM-generated graphs rejected for hallucinating nodes — is first-hand, specific and inspectable in an open-source repository. Everything comparative is Avagyan describing his own tool to a friendly interviewer, and the framing statistic that justifies the whole exercise names no organisation at all.
Author is the only named user
Count the users and you reach one. The project's reach is described in capability terms — a dozen-plus languages, 7,000-plus tests in the loop — not in users, forks, downloads or deployments, and the sole usage account is the creator running it beside his other harnesses. The 30% to 75% AI-code figure measures the problem's size, not this tool's traction.
Milliseconds quoted, nothing timed
The gap opens at the comparisons. A millisecond Cypher answer is presented against grep loops and vector similarity without either side ever being timed, and the graph build that has to happen first goes uncosted. Avagyan is notably restrained in places — he says text and graph search complement rather than replace each other, and that his tool wins on 'some problems' — which keeps this from being the louder kind of overstatement.
Maker's case, vendor-adjacent staging
Every efficiency claim is made by the person whose project benefits from it, in a developer-tooling library that runs on maker interviews, illustrated by an image credited to Memgraph — a graph database vendor with an obvious stake in code being modelled as a graph. None of that makes the technical account wrong; it does explain why no one in the piece argues the other side.
Clear account, unchecked
We are confident about what was said — the quotes are direct, the architecture is described in enough detail to verify against the repository, and the missing pieces are missing consistently. We are much less confident about what any of it delivers, because a single interview with the tool's author gives us nothing to triangulate against.