Dependency Graphs for AI Coding Agents
The most expensive question in software is "what else will this break?" AI coding agents are usually bad at answering it. They can see the code they're editing, not everything that depends on it. A dependency graph closes that gap. This article explains what a dependency graph should include for AI-assisted development, and how to use one before the agent writes any code.
What a useful dependency graph shows
A package manager's dependency tree lists libraries. For AI coding, you need much more:
- Module and file dependencies: which parts of the code import which.
- Cross-repository dependencies: where one repository relies on another.
- Service calls: where one service calls another over the network.
- Data dependencies: which code reads or writes which tables or collections.
- Third-party packages, when they matter to the question.
Both directions matter
For any component, you need both:
- Depended on by
- what points into it. These are the things that break if you change it.
- Depends on
- what it points to. These are the things that can break it.
An agent that only follows imports sees the second direction. The first is what prevents breaking changes.
Direct vs inferred dependencies
Some dependencies can be read straight from source, like an import or a function call. Others, especially calls between services, have to be inferred from evidence such as URLs, client code and configuration. A trustworthy graph keeps these separate. It shows which relationships are certain and which are likely, so neither you nor the agent treats a guess as fact.
Using a dependency graph before a change
- Find the component you're about to change.
- Read "Depended on by" and list every consumer, including those in other repositories.
- Verify uncertain edges. If an inferred call matters, check the actual code that makes it.
- Give the list to the agent as part of the plan, so it updates or protects every consumer.
Dependency graphs in CodeZero
CodeZero includes a Code Graph built from your organisation's repository index:
- Organisation-wide view: modules, files, data and cross-repository dependencies, without treating each repository as an isolated project.
- Modules / Files levels, plus grouping to control how much detail you see.
- Filters for one repository or all of them, with optional third-party packages and the data layer.
- Depended on by / Depends on for every selected node.
- Direct vs inferred edges. Inferred service calls are shown as dashed lines. Click Verify to have your agent check the relevant code, and the result is saved for your whole organisation.
The same graph powers CodeZero's chat, Feature Mapping and change planning, so your agent plans with the dependencies already in view.
FAQ
What's the difference between Code Graph and Feature Mapping?
Code Graph shows how the whole system is connected. Feature Mapping focuses on how one product feature maps to the code and dependencies that implement it.
Does it work without a coding agent?
Yes. Code Graph, Git Tree and repository browsing work without an agent. Verifying inferred edges and agent turns require Claude Code.