What Is a Dependency Graph for AI Coding? (And Why It Cuts Tokens by 63%)

AI coding agents are burning your tokens on files they don't need.

You ask for a small refactor, and the agent responds by slurping hundreds of files into its context window. Most of them are irrelevant. You're paying for the model to read noise.

The problem isn't the model. It's how agents understand code structure — or rather, how they don't. File trees, fuzzy search, and recency heuristics don't scale past a few hundred files.

Dependency graphs do.

Why AI Coding Agents Read Too Many Files

Most AI coding agents navigate codebases with three crude signals:

• File paths and names
• Keyword search
• Recently edited files

Ask about a function and the agent:

Summary

This piece explains why AI coding agents waste tokens without a structural understanding of your codebase, and how vexp’s static dependency graph fixes that by turning blind file exploration into targeted context retrieval.

Core Idea: Dependency Graph for AI Coding

A dependency graph is a directed graph where:

• Nodes = files, functions, classes, interfaces, types
• Edges = imports, calls, extends/implements, references

Example edges:

• OrderService.createOrder() → InventoryService.checkStock() (call edge)
• PaymentHandler → Transaction (type import/reference edge)

By building millions of these edges across your repo, vexp gives the AI a precise map of how code actually connects, instead of forcing it to guess via filename heuristics and broad search.

Static vs Dynamic Graphs

• Static dependency graph (what vexp uses):
• Built by parsing source code (no execution)
• Captures imports, type references, inheritance, interface impls, statically resolvable calls
• Incrementally updated as files change
• Dynamic dependency graph:
• Built from runtime instrumentation
• More accurate for highly dynamic languages but expensive and less practical at scale

vexp chooses static graphs for speed, scalability, and always-on applicability during normal development.

Why This Matters for AI Coding Agents

AI agents have a limited context window and no built-in understanding of your architecture. Without a graph, they:

1. Start from the mentioned file
2. Read referenced files
3. Guess related files by name/folder
4. Pull in recent git changes
5. Do keyword/semantic search

Step 3 is guesswork, and steps 2–5 often drag in irrelevant files, burning tokens and adding noise.

With a dependency graph, context selection becomes targeted retrieval:

• Given a task like “fix the bug in OrderController.processPayment”, vexp:

1. Locates processPayment in the graph
2. Traverses outward (what it calls, what types it uses)
3. Traverses inward (who calls it, what middleware wraps it)
4. Ranks nodes by graph centrality + semantics
5. Returns only the highest-value snippets within the token budget

Result: the model sees the right 5–20 files instead of 100+ loosely related ones.

Measured Impact (FastAPI Benchmark)

On a FastAPI project (7 tasks, 21 runs per arm, Claude Sonnet 3.5):

• 65% reduction in input tokens vs no context engine
• 58% reduction in total API cost
• 22% faster task completion
• +14 percentage points higher completion rate

The dependency graph is the main driver of these gains by:

1. Pruning Irrelevant Files

Most large repos: thousands of files; any given task: ~5–20 truly relevant.

The graph lets vexp:

• Start from the symbol(s) you’re working on
• Follow real import/call/type edges
• Exclude files that are not structurally connected

2. Ranking by Graph Centrality

Not all connected nodes are equally important.

vexp uses graph centrality (PageRank-style) so that:

• Functions/types heavily referenced across the codebase rank higher
• Leaf helpers or one-off utilities rank lower

This ensures the most influential code gets into the context window first.

3. Cross-Language Awareness

vexp builds a unified graph across:

• TypeScript, JavaScript, Python, Go, Rust, Java, C#, C, C++, Ruby, Bash

It can connect, for example:

• TS frontend → Python backend endpoints
• Go services → Protobuf/IDL definitions
• Python workers → YAML configs

So the agent can follow real cross-language relationships instead of being siloed by language.

4. Session Memory Integration

Over time, vexp enriches the graph with usage signals:

• Files you open
• Functions you edit
• Tests you run

These observations are attached to graph nodes and influence ranking in future sessions. The graph becomes not just a theoretical map of possible relationships, but a map weighted by what your team actually touches.

How vexp Builds and Uses the Graph

vexp’s graph is built by vexp-core, a Rust daemon.

Incremental Indexing

```bash

npm install -g vexp-cli

cd your-project

vexp-core index --workspace .

```

• Index stored locally as index.db (gitignored)
• .vexp/manifest.json (with blake3 hashes) is committed so teammates can share structure without the full DB
• Initial index (up to ~50k files): ~30–120 seconds
• Incremental updates on file change: milliseconds

Graph Traversal in run_pipeline

When your AI agent calls run_pipeline, vexp:

1. Parses the task description to extract keywords and likely symbols
2. Seeds the graph with starting nodes via hybrid search (keyword + semantic)
3. Traverses outward to a configurable depth (typically 2–3 hops)
4. Scores nodes using: