/GRAFT Skill + Astra: THIS IS ABSOLUTELY CRAZY!

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: /GRAFT Skill + Astra: THIS IS ABSOLUTELY CRAZY! · Channel: AICodeKing · 10:56 · Watch on YouTube

Topics: AI agents, Software engineering with AI, AI developer tools

Summary

The video demonstrates using the open-source Graph (Graft) tool with the Verdant coding agent to inspect a small document service and trace its code relationships. A failing test reveals that viewers can export shared documents even though the app’s policy allows exports only for editors and owners. Graph queries help identify that the export service checks read permission but never calls the export-permission helper; Verdant then applies the fix, and all nine tests pass. The video also covers setup, automatic graph refresh, visualization, costs, and limitations, emphasizing that graph results support rather than replace code review and testing.

Key points

Graph builds a queryable code graph of functions, imports, and relationships; its structural analysis uses Tree-sitter and does not require an AI provider key.
The optional deep layer adds AI-written summaries and concept nodes and may incur provider costs.
The demo uses Graph’s command-line workflow through Verdant; the tested version is 0.18.0 and requires Node 20 or newer.
The sample service has a permissions bug: a viewer can export a document despite the defined policy requiring editor or owner access.
Graph queries locate relevant functions and show that the export service does not call the existing export-permission helper.
Verdant fixes the issue by checking export permission in the export service, after which all nine tests pass.
Graph detects stale code and refreshes its structural graph when queried, including for an uncommitted edit in the demo.
Static analysis has limitations, and graph connections alone do not establish that an implementation is correct; inspect the code and run tests.
Token-saving estimates are not proof of equivalent savings across a complete agent session, and the demo does not reproduce the maintainers’ benchmark.

Chapters

Start	Chapter	Summary
00:02	What Graph does and its two layers	The video introduces Graph’s code-relationship queries, distinguishes the free structural graph from the optional AI-powered deep layer, and explains the basic setup.
02:05	Setting up the Verdant demo	The presenter describes Verdant’s workflow, installs and runs the Graph CLI, and introduces the document service’s export-permission bug.
04:12	Tracing the export-permission bug	After establishing the failing test, the presenter uses Graph queries to find the export code and discover that the service never calls the export-permission helper.
07:20	Fix, refresh, and verify	Verdant adds the missing permission check, Graph refreshes its stale structure, and all nine tests pass while intended read and editor access remain intact.
08:21	Visualization, limitations, and conclusion	The video shows Graph’s visualization, discusses analysis and token-estimate caveats, and concludes with advice to try the structural layer on a real project.

Quotes

The basic build uses tree sitter to analyze code structure. — 01:34

The query itself is deterministic retrieval. — 05:46

The helper can be correct while the feature using it is still broken. — 06:49

A graph showing the new call does not by itself prove the implementation is correct. — 08:21

This small walk through verifies the commands and the bug fix workflow. — 09:54

Concepts and entities

Graph, Graft, Verdant, Tree-sitter, MCP, @nanonets/graph, Node.js

Full transcript (original language)

00:02 [music] Hi, welcome to another video. So, if you use AI coding agents, you have probably seen this happen. You open a project, ask for a small fix, and the agent spends the next few minutes searching files, reading imports, and figuring out how everything connects. Then, you start another task, and it does a lot of that work again. Today I want to show you an open source project called Graph that tries to make that process more efficient. It builds a code graph that your agent can query so it has a better

00:33 starting point when it needs to understand your project. And for this video I actually installed it and used it through Verdant. I prepared a small document service with a permissions bug ran the tests and asked Verdant to investigate it using Graph. So we have a concrete example to look at along with the commands and outputs you can reproduce yourself. So let’s get right into it. First, what does graft actually do? It reads the source code and records things like functions, imports, and the connections between them. You can ask where something is implemented, look at

01:03 a files available functions, or trace which parts of the project call a particular function. That information is useful because a coding task usually involves more than finding one matching word. If I change a permissions function, I also want to know which services use it. And if a service behaves incorrectly, I want to follow the path that led to that behavior. Now, graft has two layers and this is an important distinction. The basic build uses tree sitter to analyze code structure. You can build the graph and run the queries we are using today

01:34 without giving graph an AI provider key. There is also an optional deep build which adds AI written summaries and concept nodes that uses your configured model provider. So there can be API costs depending on the provider you choose. We are using the structural layer in this demo. All the results you will see here work without that additional model call. The project is MIT licensed and the structural graph does not require a separate database server. It keeps its generated files inside a graft folder in your project.

02:05 The build also adds that folder to git ignore because you can regenerate it from the code. So the basic setup is quite approachable, but free graft queries do not make the coding agent itself free. If your agent or model has usage charges, those still apply. Keep those two costs separate. Now I have Verdant open here. The basic workflow is to open a project folder, create a task, and describe what you want the agent to do. It can inspect files, edit the code, and run terminal commands with the progress and results shown in the task. You also have a model selector and there

02:37 is plan mode when you want to work through an approach before implementation. For this example, the requirements are already clear. So I’m giving the agent a specific investigation to carry out. Verdant also gives you file views and change summaries. So once the agent edits something, you can inspect what changed. There is a code review feature as well. And for larger work, its manager can break a goal into subtasks and coordinate workers. One thing to keep in mind is that tasks in the same workspace share the files. Creating another task does not automatically mean every edit is isolated. For this walkthrough, I opened a dedicated demo folder which

03:08 keeps the example easy to follow. Now, Graph does not currently have a dedicated Verdant entry in its integration installer. What we are doing here is asking Verdant to run the Graph CLI. Verdant also supports MCP and Graph has an MCP server, but the integration I actually tested for this video is the command line workflow. First, I asked Verdant to check the node version and install graft locally. The version I tested is 0.18.0 and it requires node 20 or newer. My machine was running node 22. For a quick

03:40 setup on your own machine, you can use npx with the at nanonets/graph package. For the recording, I pinned the version and installed it in a separate tooling folder so we can repeat the same example. I have put the exact commands in the companion notes. Once that is installed, we can run graft build inside the code repository. There is no provider key to enter for this part. I also disabled optional telemetry for the demo commands. Now let’s look at the example. This is a small document service with owners, editors, viewers, and unrelated users. A viewer should be

04:12 able to read a shared document, but exporting it as a CSV file should require an editor or owner. These are rules for our sample app. A different product could choose a different export policy. The point is to see whether the code follows the policy we have actually defined. So let’s run the baseline tests. We have nine tests, eight pass and one fails. The failing test says a viewer cannot export a shared document but the handler returns status 200 instead of 403. And if we run the example directly, we can see the same thing. The viewer can read, which is

04:43 expected. The viewer cannot edit, which is also expected. But the viewer can export the document, which is the bug we put into this fixture. I like using a small example like this because you can follow the entire path. It is synthetic data and we are calling the route handlers locally. There is no production account or deployed service involved. Now for the first graft example, let’s understand the codebase. Verdant runs graft build and it produces 29 nodes and 66 edges from nine JavaScript files including the tests. Those numbers are

05:15 from this tiny fixture so they are not a scalability benchmark. Then we run graft map to get an overview and ask where document export permissions are checked. We add the d- source flag. So the results include the relevant code alongside the file locations. Okay. The first result is the export document function. The next result is the export permission helper. We also get the export route handler and the function that loads a document for a user. That is a useful collection of files for this question. We can see the export function fetching the document and immediately

05:46 turning it into CSV. We can also see a separate helper that permits owners and editors to export. Graph is returning relevant source here. Verdant is still responsible for reading that source and reasoning about whether the behavior is correct. The query itself is deterministic retrieval. So we are not paying another model just to produce these search results. There is also the skeleton command. We run it on the permissions file and it lists the function signatures for checking a document’s role. Read permission, edit permission, and export permission. That gives us a quick overview of the files

06:17 API without dumping every function body into the conversation. Now for the second example, let’s follow the callers. We ask graph which parts of the project call the export document function with a depth of two. It shows the route handler and then the connections to the demo and test. Then we ask the same thing about the export permission helper. And here is the useful clue. The output points to the tests, but there is no call from the export service. So the policy exists and there is even a test checking that policy directly. But the actual export

06:49 path never uses it. This is why testing a helper alone is not enough. The helper can be correct while the feature using it is still broken. If we follow the source, the export service loads the document through a function that checks read access. A viewer passes that check because viewers are allowed to read. The export service then creates the CSV without checking the stricter export permission. That explains both the failing test and the missing connection in the graph. So we have something concrete for the agent to fix. Now I ask Verdant to enforce the existing export

07:20 policy inside the export service. The change is small. Import the permission helper. Import the error type and reject the request if the user cannot export. We keep the existing tests exactly as they are. And here is the third example which I think is quite useful. After the edit, we run graph check before rebuilding anything. It reports that the graph is stale and identifies the export service has changed. Then we run the same graft question again without manually running another build. The output says it refreshed the graph because one file changed and the source excerpt now includes the new permission

07:51 check. If we ask for the callers of the export permission helper again, the export document function now appears. So we can see the connection that was missing before the fix. A subsequent freshness check reports that the graph is current. This matters when an agent is making several changes in a session. You want its next query to reflect the updated code. In this run, that worked with an uncommitted edit. And I also repeated the sequence in a separate temporary copy to verify it. Now, let’s run the tests again. All nine pass. The viewer

08:21 gets 403 when trying to export. While the editor can still export successfully, the viewer can still read the document, too. So, we have kept the intended read access. So, that’s great. The graph helped us find and inspect the relevant connection and the tests verified the resulting behavior. I would still keep both parts of that workflow. A graph showing the new call does not by itself prove the implementation is correct. Graph also has an interactive visualization. I exported the code graph and opened it inside Verden’s browser panel. You can switch between the graph

08:52 and a file outline. Select a function and inspect what it depends on and what depends on it. I have included both the before and after exports with the examples. Now there are a few limitations to keep in mind. Static analysis has limits especially with dynamic behavior and graph’s language support varies in depth. The graph is useful context but you still need to inspect the code when the result is ambiguous. The automatic refresh we tested update structure. It does not regenerate paid AI summaries every time you ask a question. If a refresh fails, graph can fall back to the existing graph. So pay attention to its notices.

09:24 And if you want the deep layer, make sure it actually ran with your configured provider. A successful command alone does not prove those summaries were generated. You will also see token- saving estimates in some graph outputs. Those compare the returned context with reading the covered files in full. They are estimates and they do not prove that our complete Verdant session used that percentage fewer tokens. The maintainers separately report 42% fewer tokens and 60% less time in their controlled benchmark. Those are their results. This small walk through verifies the commands

09:54 and the bug fix workflow. It does not reproduce that benchmark or establish a speed up over using Verdant alone. For Verdant’s pricing, the current monthly options start at $5 for light. Starter is $19, pro is $59, and max is $179. The pricing page also lists 100 free credits valid for 7 days for new users. Check the current limits and model costs when you choose a plan. Personally, I think Graph is worth trying when your agent repeatedly needs to understand

10:25 relationships across a codebase. You can start with a structural graph, use a few targeted queries, and see whether the results help on your actual project before setting up the optional deep layer. And Verdant gives us a convenient place to run that workflow, inspect the output, review the changes, and keep the tests alongside the task. The complete example includes the original failing version, the fixed version, the graph exports, and a replay script that runs the sequence in a temporary copy. Overall, it’s pretty cool. Anyway, let me know your thoughts in the comments.

10:56 [music] If you like this video, consider donating through the super thanks option or becoming a member by clicking the [music] join button. Also, give this video a thumbs up and subscribe to my channel. I’ll see you in the next one. Until then, bye. [music] >> [music]