Graft: how I would cut repeated code searches for an AI agent

When I ask an AI agent to change something in a project, I want it to reach the relevant code quickly. Before the edit, though, there is a whole job to do: find the file, understand who uses it, and check whether the change reaches other parts of the application.

That is what interests me about Graft. It builds a map of code relationships so an agent can navigate with less repeated searching. Here is how I would bring it into my workflow, and what I would measure before deciding it saves me time and tokens.

Before switching models, I would look at where the time goes

A capable model can produce a good answer after taking a long route to it. Suppose I ask it to change appointment cancellation in a booking app. It might search for "booking," open several files, find the cancellation function, then discover a notification that also needs updating.

Each round adds search results to the context for the next decision. When too much irrelevant material accumulates, keeping the task focused becomes harder. I would want to know how much of the work went into finding the code and how much went into solving the problem.

I would not translate a reduction in tokens directly into the same reduction in spending or subscription usage. Those are different measures, and the effect depends on the product, model, and accounting rules. Time to a correct fix matters more to me than a broad promise of "fewer tokens."

What I want from a code map

I think of a graph as a map of items and connections. An item might represent a function or class. A connection might show a call to another function or a dependency on a file.

For the booking app, I would want to trace something like this:

Cancellation button
  -> cancellation handler
  -> booking service
  -> database update
  -> notification

This is an illustration, not output from a project I tested. It captures what I want to understand before editing: where the process starts, what changes the data, and what happens afterward.

Semantic search can help locate a relevant area. Similar wording, however, does not establish a connection in the code. For "who calls this function?" I would prefer to inspect explicit relationships. For an exact string, I would still use ordinary text search. I see no reason to limit myself to one retrieval method for every question.

I would start with the structural map

Graft is an open-source tool with a CLI and coding-agent integrations. Its basic mapping analyzes code structure without calling a model. An optional layer adds explanations written by a model.

I would keep the two modes separate: graft build needs no model key; graft build --deep adds explanations through a configured provider. I would not assume an existing coding-agent subscription automatically covers that layer. Graft's official documentation.

I would begin with the structural map and ask questions about an area of the project I already understand. If I still need explanations, I would assess the extra layer separately. That gives me a way to see what each part contributes.

How I would set it up

With Node.js and npm installed, I would begin with the documented package:

npm install -g @nanonets/graft

Then, from a terminal inside the project folder:

graft init --dry-run
graft init

The first command previews the files setup would change. After reviewing them, I would select the relevant agent in init. Current setup can build the map itself, so I would not automatically add another build step from an older guide. Installation and agent setup.

I would also inspect changes to the agent's configuration. For Codex, the documentation describes possible user-level writes outside the repository; --no-global skips those. That is one reason I would review the dry run first.

When I want automatic context, and when I want a lookup

I think about the integration in two ways. Hooks can add context at defined points in a workflow. With MCP tools, the agent can request information when it has a question.

Getting an initial direction sounds useful to me. But irrelevant material attached to every request also consumes context. I would inspect what actually reaches the conversation, rather than treating a successful installation as proof of useful retrieval.

This is the kind of task I would give the agent:

Before changing appointment cancellation, use the code map to locate the entry point and its dependencies. Read the relevant implementation, check for another cancellation path, and propose a change with appropriate tests. If the map does not cover part of the flow, identify that gap and continue searching the code.

I want the map to shorten the investigation. The implementation and the application's behavior still need to support the final decision.

How I read the savings figures

Graft's developers report a controlled test of 162 runs across two repositories. Their main comparison reports averages of 42% fewer tokens, 46% fewer tool calls, 60% less time, and 32% lower cost. Correctness in that comparison was 93% for both sides. These are the developers' results, not measurements from a test I conducted. Benchmark details.

I would not turn those numbers into a promise for every project. A claim such as "up to four times cheaper" describes an outcome at the end of a range, not an average I can assign to my work in advance.

To assess the tool, I would choose several tasks from the same project: finding a bug, making a change across files, and updating a known file. I would use the same starting commit, model, and settings, then compare correctness as well as resource use. I would record the initial graph-building time separately.

If an agent finishes sooner but misses an existing path, I do not count that as a saving.

The map needs to remain useful after edits

A stale map can send an agent to the wrong place. Graft describes structural refresh before queries and updates after changes, depending on the integration. I would test that with a small edit followed by a question about the changed code.

I would not assume the map contains every relationship. Dynamic behavior, excluded files, and differences in language support can leave gaps. I would use the result to direct my investigation, then complete it with source reads and tests.

I still need a requirements document, too. A code map can help explain what the application does; it does not decide what a customer wanted it to do. I would keep the PRD, product decisions, and project notes available to the agent separately.

Where I would try Graft first

I would begin with an existing project whose parts depend on one another, particularly one I return to over time. That gives the tool more opportunities to reduce repeated orientation. In a small project or an empty folder, setup may contribute less at the beginning.

My test is straightforward: do I get a correct change with less unnecessary reading and less waiting? If so, I would keep Graft in the workflow. If not, I would stick with focused search and clear instructions.

Tool details and documentation were checked on September 9, 2026.