Your Coding Agent Is Guessing What Your Change Breaks. AxiomCode Graph Hands It a Map
A type-aware call graph that Claude Code, Codex and Cursor can query, what its edge labels mean, and what its license allows
Ask a coding agent what a change will break, and watch what it does. It searches. It runs something like grep -rn "save(" across the repo, reads a screenful of matches, and decides which ones matter.
That works until your codebase has forty methods called save. Grep matches names. It has no idea which save a given line is calling, so the agent either reads all forty (burning context) or guesses (missing callers). The answer to "what does this touch?" ends up being a guess with a confident tone.
AxiomCode Graph, a young project that turned up in a promoted "featured" slot on Trendshift this week, tries to replace that guess with a map. It builds a call graph of your repository the way a compiler would see it and lets the agent ask direct questions: who calls this, what does this change reach, which tests should I run. The interesting part is not the headline benchmark. It is that every link in the map carries a label saying how sure the tool is.
The problem with matching names
A call graph is just a list of "this function calls that function" links across your code. Plenty of tools build one. The difference is how they decide which function a call points to.
Many fast code-graph builders use tree-sitter, a parser that reads the shape of code (this is a function, this is a call) without knowing what type anything is. When it sees order.save(), it knows a method named save is being called. It does not know that order is an Order, so it can't tell Order.save apart from User.save or Cache.save. It matches by name, like grep with better manners.
AxiomCode's README says it resolves each call "from the receiver's declared and inferred type, as the compiler does." In the example above, it looks at what order is and links the call to Order.save only. The resolution rules are written in Soufflé, a logic language for this kind of analysis, which is why the project describes its results as deterministic: same code in, same graph out.
The output lands in a single SQLite file at .axiomcode/out/graph.sqlite, one schema across languages. Your agent never reads that file directly. It asks questions through a command-line tool or an MCP server (MCP being the standard way coding agents plug in outside tools).
What your agent can ask
The README lists a handful of commands, and they map cleanly onto the questions an agent should be asking before it edits anything:
axiomcode impact <name>shows who calls a function, what a change to it reaches, and which tests are related.axiomcode impactwith no name does the same for your uncommitted edits.axiomcode path <A> <B>shows the call chain from one function to another.axiomcode testslists the tests your uncommitted edits reach, with arun:line you can paste.axiomcode link <file:line> <target>records a call the engine couldn't resolve, inaxiomcode-links.tsv, so the next query knows about it.
Through MCP, the agent sees the same ideas as tools, including impact, path and tests. The docs disagree on the exact count: one README section says the plugin has four MCP tools, another names three, and the v0.1.9 release notes list five commands (adding context and link). Check what your installed client actually shows.
That tests command is the one I would try first. "Which tests should I run for this diff?" is a question agents answer badly today, usually by running everything or nothing.
The labels are the real feature
Here is the part worth slowing down for. No static analysis tool resolves every call. Code calls through interfaces, through dependency injection (where a framework decides at runtime which object gets passed in), through libraries whose source isn't in the repo, through strings. A tool that hides those gaps hands your agent a map with confident lines drawn over unexplored territory.
AxiomCode labels every link with one of four tiers, per the README:
known_edge: resolved to one specific target.multi_inferred: the call could go to a set of candidates (an interface with several implementations, say).boundary_lib: the call goes into a library the tool did not expand.ambiguous_unknown: the tool could not work it out.
Calls it cannot resolve stay in the database with an empty target instead of disappearing. The README is explicit that coverage "is not resolution precision," and tells you to read results alongside each edge's tier.
This is the useful mental model for any code-intelligence tool you hand to an agent. A map is only as trustworthy as its labels for the parts nobody surveyed. An impact result made entirely of known_edge links is something an agent can act on. A result that leans on ambiguous_unknown is a list of places a human should look.
What the numbers say, and who said them
The README reports strong results. On 748 held-out bugs (ones not used while tuning the tool) from Defects4J (a public collection of real Java bugs, each with tests that reveal it), AxiomCode included every bug-revealing test for 94.9% of bugs, against 61.5% for the best tree-sitter-based builder. On call resolution, it reports 96.5% of Java calls resolved correctly against 78.9% for the next tool, and 88.8% of TypeScript calls against 71.6%, using five open-source projects per language. It names GitNexus, CodeGraph, Code-Review-Graph and Graphify among the tools it compared.
Treat those as the project's own measurements. The README does not say anyone outside AxiomCode ran them, the comparisons are against named competitors, and the call-resolution tests cover Java and TypeScript only. One line, "The map prunes 99.9% of the codebase," comes with no method or project attached, so I would not repeat it to anyone.
None of that makes the tool bad. It means the honest way to judge it is on your own repo, which is cheap to do.
Put this into practice
The engine is an npm package, @axiomcode/code-graph. You need Node 22.13 or newer and Python 3. On Windows, the CLI runs under Git for Windows' bash. On Linux arm64, native modules compile during install, so have build tools such as build-essential ready.
1. Install and try it from the terminal first.
npm i -g @axiomcode/code-graph
cd your-repo
axiomcode index
axiomcode impact SomeFunctionYouKnowWell
Pick a function you know cold. You are checking the tool, not your code. Do the callers it lists match what you would have said? Which tiers show up? If axiomcode index needs hints, the README documents --lang, --src and --library flags.
2. Keep the graph out of git. Add .axiomcode/ to your .gitignore, as the README asks. The graph and its refresh log live there.
3. Plug it into your agent. For Claude Code, the README gives a plugin route:
claude plugin marketplace add AxiomCodeAI/axiomcodegraph
claude plugin install axiomcode@axiomcode
Codex, Gemini CLI and Cursor's agent have their own one-liners in the README, and any MCP client can run the server directly:
{ "mcpServers": { "axiomcode": { "command": "npx", "args": ["-y", "@axiomcode/code-graph", "mcp"] } } }
Start a new agent session afterward so it picks up the tools.
4. Change your prompt, not just your tools. Agents keep grepping out of habit. Tell yours plainly: before editing a function, call impact on it, and before finishing, call tests and run what it returns. Ask it to report any edge that is not known_edge.
5. Feed back what it misses. When you find a call the graph didn't resolve, record it with axiomcode link. If background rebuilds get in your way, the README says AXIOMCODE_NO_REFRESH=1 turns them off.
What to expect: Java, TypeScript and Python are marked stable. JavaScript and C# are beta, and HTML and CSS (added in v0.2.0) are beta too. If your repo is mostly one of the stable three, the first impact query is a fair test. If it is mostly JavaScript, temper your expectations.
Honest limitations
It is source-available, not open source, for now. AxiomCode ships under the Functional Source License (FSL-1.1-Apache-2.0). Internal use, non-commercial education and research, and professional services for a licensee are explicitly permitted. What you may not do is offer it in a commercial product that substitutes for it or offers "the same or substantially similar functionality." Each release converts to Apache-2.0 on the second anniversary of its release. For using it on your own code, that is fine. For building a code-intelligence product on top of it, read the license twice.
It is very new. The releases feed shows six releases between September 29 and October 14, ending at v0.2.0. The default branch is dev. The star count is a couple of hundred. Expect fast changes and some rough edges.
The README is quiet on network behavior. It describes local background rebuilds and a SQLite file on disk, but says nothing about telemetry either way. If your code is sensitive, watch its traffic on a test repo before you point it at the real one.
Static analysis has a ceiling. Reflection (code that looks up methods by name while it runs), string-based dispatch and heavy dependency injection defeat every tool like this. The tiers tell you where that happened. They don't fix it.
The benchmarks are the vendor's. Strong numbers on Defects4J tell you the approach is promising for Java. They don't tell you how it does on your monorepo.
The question to ask your agent tomorrow
Next time your coding agent finishes a change, ask it one thing: "How do you know nothing else calls this?"
If the honest answer is "I grepped," you have found the gap AxiomCode is built for. Install it on a branch, run impact on three functions you know well, and look at the tiers. If the map matches what you know, give it to your agent. If it doesn't, you have learned exactly where your agent was guessing all along, and that is worth knowing either way.
Sources: AxiomCodeAI/axiomcodegraph README, reviewed at the v0.2.0 tag; LICENSE.md (FSL-1.1-Apache-2.0); releases; Defects4J; tree-sitter. Benchmark figures are AxiomCode's own, as published in its README in October 2026.