I Let an AI Coding Agent Build a Map of My Codebase, Here's What Happened

Every time you ask an AI coding assistant to fix a bug or explain how something works, it usually starts from zero. It reads files, greps around, and slowly rebuilds an understanding of your project that it already had yesterday. Today is September 2, 2026, and this problem is getting more attention because AI coding agents are now doing far more autonomous, multi-step work than they were even a year ago, which means the cost of "starting from scratch" every session adds up fast, both in time and in the token bill.

That is the exact problem a tool called Graft tries to solve. I tried it out on a real project, not a toy demo, and I want to walk you through what it actually does, what it found, and where it falls short.

What Graft actually is

Think of Graft as a librarian for your code. Instead of an AI agent wandering through folders every time it needs to understand something, Graft builds an index once: a folder of small, linked text files that describe what each part of your code does, which functions call which other functions, and how everything connects.

It does this in two layers:

1. A structural graph, built with a code-parsing technique called tree-sitter. This layer needs no AI model at all. It just reads your code the way a compiler would, and extracts function names, classes, and the connections between them.
2. An optional concept layer, which uses an AI model to write plain-language summaries of what each part of the code is for. This part costs money to run because it calls an AI model, so it is opt-in.

The important part: the first layer, the one that maps out your whole codebase, costs nothing and needs no API key. It just parses your files locally.

Why I decided to test it on a real project

I work across several real codebases in one repository: an Android app written in Kotlin, a website built with a modern web framework, a couple of small backend services, and a handful of Python scripts for odd jobs. One of those codebases, the Android app, has a single file that has grown to well over three thousand lines because new features kept getting bolted onto it instead of being split out properly. This is an extremely common situation in real software projects. Everyone means to refactor "later," and later keeps getting pushed back.

Before touching a file like that, you want to know exactly what depends on what, so a small change doesn't quietly break something three screens away. That is precisely the kind of question Graft is built to answer, so it felt like a fair, honest test.

Setting it up

Step 1: Install the tool

Graft installs as a small command-line program, similar to installing any developer tool globally on your machine:

npm install -g @nanonets/graft

Step 2: Preview what it would change

Before wiring anything into your project, you can ask it to show you exactly what files it would create or modify, without touching anything yet:

graft init --dry-run

This printed a short list: a few configuration files for AI coding assistants, a skill file, and a folder for the generated graph itself. Seeing this list before committing to anything is a good sign of a tool that respects your project.

Step 3: Run it, scoped to just this project

Some tools like this also want to write global configuration that affects every project on your machine, not just the one you're working in. I did not want that, so I used a flag to keep everything local:

graft init --no-global -y

This parsed every real source file in the project (in my case, 77 files across Kotlin, TypeScript, JavaScript, and Python) and built a graph with 561 distinct pieces of code and 1,229 connections between them, in a few seconds, with no AI model involved and no cost.

Putting it to work

Here's where it got interesting. I asked Graft for a repo-wide orientation map, and it immediately flagged one function inside that giant Android file as the single most depended-upon piece of code in the whole project, with ten other places calling into it.

Then I asked a more pointed question: show me everything that would be affected if I changed that one function. Graft traced the entire chain: every screen, every helper file, every place that function's behavior would ripple out to, instantly and for free.

Getting that same answer by reading the code manually, or by asking an AI assistant to grep through everything, would have meant reading roughly 200,000 tokens' worth of file content. Graft's own accounting tool showed it had saved that much by reusing the graph instead. At current pricing for a mid-tier Claude model, that is somewhere around forty cents saved in a single exchange. It sounds small, but that saving repeats every single time anyone, human or AI, asks a similar question about that codebase, which is where the real value adds up.

What I didn't love

Not everything about it was free of friction. Once wired in, Graft installs a hook that runs on every single message you send to your AI coding assistant, checking whether the graph has something relevant to offer. On two separate occasions, when I asked plain conversational questions that had nothing to do with the code, it still chimed in with a suggestion to go check the graph. It wasn't wrong to try, but it was unnecessary noise on those turns.

It's also worth being clear-eyed that this is a very new tool. It was first published only a couple of months before I'm writing this, and it has already gone through dozens of small version releases in that short window. That pace of change is exciting, but it also means it hasn't had years of real-world battle testing the way older developer tools have.

Conclusion

Graft solves a real, everyday annoyance in working with AI coding assistants: the constant re-discovery of code that never changes between sessions. On a genuinely messy, multi-language project, it produced accurate, useful answers in seconds, for free, using nothing but local parsing. It is not magic, and it does add a small amount of chatter to your workflow, but as a foundation for helping an AI assistant understand a codebase before making changes, it earned its place.

Merits

• Builds a full map of a multi-language codebase in seconds, with no AI model required for the core feature
• Costs nothing to run for the structural graph, since it works entirely offline
• Can trace the full "blast radius" of a change, meaning everything that depends on the code you're about to edit
• Can be scoped to a single project without touching your other projects' settings
• Keeps its generated data out of version control automatically, so it doesn't clutter a shared repository
• Works across many programming languages at once in the same project

Demerits

• Installs a hook that runs on every single message, which can feel noisy on conversations unrelated to code
• Very new software, with a short track record so far
• The deeper, AI-summary layer still requires your own AI model access and does cost money if you turn it on
• Setup touches several configuration files across your project, so it's worth reviewing what gets written before accepting it

Caution

This article is meant to be educational and reflects one person's hands-on experience with a specific tool at a specific point in time. Any commands, numbers, or version details mentioned here can change as the tool evolves, so check the tool's own official documentation before installing it yourself. If you try it on a shared project, review every file it proposes to create or modify first, and never assume a new developer tool is risk-free just because someone else had a good experience with it.

Frequently asked questions

• What is Graft? — It's a tool that builds a local, linked map of a codebase so AI coding assistants (and developers) can understand it quickly without re-exploring it from scratch every time.
• Does it require an AI model to work? — No. Its core feature, the structural map of your code, works entirely offline using a code-parsing technique. An optional deeper layer does use an AI model, but that part is not required.
• Is it safe to install on an existing project? — You can preview exactly what it would create or change before agreeing to anything, which is a reasonable safety check before adopting any new developer tool.
• Does it work with more than one programming language in the same project? — Yes, it parsed multiple languages together in the same run during my test, including a compiled mobile app language and several web scripting languages.
• Will it affect my other projects on the same computer? — Only if you let it. There is a setting to keep everything scoped to a single project folder.
• Is it worth using on a small, simple project? — Probably not as much. The benefit grows with the size and messiness of a codebase, especially large files that have accumulated a lot of history.
• Does the generated map need to be committed to version control? — No, it's designed to be regenerated locally and is typically excluded from version control automatically.
• What's the biggest downside? — A hook that checks in on every message, which can feel like unnecessary chatter on conversations that have nothing to do with code.

Tags

#ai #developertools #codingagents #productivity #softwareengineering #devtools #automation #codereview #techtools #programming