What Is a Dependency Graph? How It Shows Blast Radius Before a Code Change

A dependency graph shows what depends on what, so it is the quickest way to see what a code change can break before you merge it. Most teams have several dependency graphs, and none of them crosses every repository. The guide below explains how to read a dependency graph, which kind answers which question, and how to see the blast radius of a change while there is still time to act.

What Is a Dependency Graph?

A dependency graph is a directed graph in which each node is a unit of software and each edge points from a unit to something the unit needs. Direction carries the meaning: an edge from checkout to billing-api says checkout needs billing, never the reverse. Read forwards, a dependency graph gives you build order. Read backwards, the same graph tells you who is affected when something changes.

Nodes and edges

A node can be any unit a team builds, ships or calls: a package, a module, a build target, a service, a file or a function. An edge records one “needs” relation, such as an import, an API request, a shared table or a container image. The node type decides the zoom level, and the edge type decides which kinds of break the graph can show.

Direct and transitive dependencies

A direct dependency is one edge away: checkout calls billing-api. A transitive dependency sits at the end of a longer path: checkout needs billing-api, which needs payments-lib, so checkout depends on payments-lib too. Bazel’s documentation also separates direct dependencies from the transitive closure. Most surprises come from transitive edges, because nobody wrote them down in the file they were editing.

Cycles and DAGs

A cycle is a circular dependency, where A needs B and B needs A. Build tools need a directed acyclic graph (DAG) to work out an order, which they compute with a topological sort that places every node after the nodes it needs. A cycle in a dependency graph is usually a design smell, because neither side can change or ship on its own.

A three-node example

Take a small chain of three services:

1. checkout calls billing-api.
2. billing-api imports payments-lib.
3. payments-lib depends on nothing inside the company.

Read forwards, the dependency graph says build payments-lib first, then billing-api, then checkout. Read backwards from payments-lib, the graph says a change there reaches billing-api directly and checkout transitively. The backwards reading is the one that matters in review.

The Dependency Graphs You Already Have, and Where Each One Stops

Every engineering team already runs on several dependency graphs. Each one answers one question well inside one boundary, so the useful skill is knowing which dependency graph you are reading before you trust it with a change.

1. Package dependency graph. Built from manifests and lock files, the package graph lists the libraries a repository uses. GitHub’s dependency graph adds versions, licenses, known vulnerabilities, dependency review on PRs and an SBOM export, according to GitHub Docs, and npm explain gives a local view. The package graph stops at declared packages: a changed API response with no version bump never appears.
2. Build or project graph. Monorepo build tools such as Nx and Bazel model projects or targets as a graph to order tasks and run only what a change affects. Bazel separates the declared graph, written in BUILD files, from the actual graph the code needs. The build graph stops at the edge of the workspace.
3. Code graph and call graph. Functions, classes and files are the nodes, and calls and imports are the edges. A code graph is the most detailed of the four and usually covers one parsed repository at a time.
4. Service and data graphs. Service catalogs record which service depends on which, and runtime service maps draw the calls they observe. Catalog entries depend on people keeping them current, and runtime maps show only traffic that already happened.

Most teams have three or four dependency graphs. The real question for a code change is whether any of them reaches across repositories and stays current with the code that just changed.

How a Dependency Graph Shows Blast Radius

Blast radius is the group of dependents a change can affect, and you find it by walking the dependency graph backwards from the change. Dependencies tell you what a change relies on. Dependents tell you what a change can break, so the dependents are the blast radius. Change impact analysis is the practice of reading that group before the merge rather than after the incident.

Reading blast radius from a dependency graph takes four steps:

1. Find the changed node. Name the function, endpoint, schema, config file or artifact the change touches.
2. Follow the incoming edges to direct dependents. List everything that calls, imports, queries or pulls the changed node.
3. Keep walking for transitive dependents. Repeat from each dependent until the paths end, because a break two hops away still ships to the same customers.
4. Weigh each edge by type. A renamed private helper and a changed API contract can be the same size in the diff and very different in reach.

Itamar Friedman, Co-founder and CEO of Qodo, wrote on X on 14 October 2026:

“Severity matters. Blast radius might matter even more: a small leak in a shared pipe can flood the whole building.”

Itamar FriedmanCo-founder and CEO at Qodo

Edge types that carry blast radius

Imports are only one way a change travels. Engineering teams also depend on events and APIs across many applications, and on database setup, migration scripts and deployment configs that other repositories rely on. A graph that tracks only imports misses those paths. Qodo’s cross-repository code review groups relationships between repositories into four types that carry blast radius:

Why diff size is the wrong measure

A one-line change to a shared contract can break five services, while a long documentation change breaks nothing. Review effort should follow blast radius, not line count, an argument Itamar Friedman made in Qodo’s 25 August 2026 webinar The Code Governance Layer Your AI Stack Is Missing, describing a coding agent that saw one repository while the change influenced five. A dependency graph without contracts can say what is connected, but not which connection a change puts at risk.

For high-velocity teams, reading blast radius early is a speed tool. Knowing what a change touches before the merge means the right people review the risky edge, safe changes go through quickly, and fewer changes come back as rollbacks. For enterprise engineering teams with hundreds of repositories, the same habit keeps one team’s release from stalling another’s.

Why Single-Repo Dependency Graphs Miss the Real Blast Radius

The costly breaks sit between repositories, in contracts nobody declared, and a dependency map kept by hand is already behind the code. Single-repo graphs fail in three ways:

1. One repository only. The package and build graphs see the repository you are in. A checkout service in another repository that reads your API response stays invisible, so the change looks safe in review and breaks in production.
2. Declared, not derived. Catalogs, manifests and BUILD files show what someone wrote down. The undeclared consumer, such as a nightly job that reads a table directly, is the one that breaks.
3. Stale. A graph built last quarter describes last quarter’s system. Coding agents now change code more quickly than anyone updates a diagram, so a hand-kept dependency map drifts further behind every week.

The cost shows up at release time. Siloed teams that build and test in isolation find each other’s dependencies only when a release stalls on a prerequisite nobody mentioned. High-velocity teams hit the same wall sooner, because more changes per day means more chances to cross an edge nobody tracked.

Copying every repository into a coding agent’s context does not close the gap. Cloning repos so an agent can search them burns tokens and still misses versions, in-flight changes and third-party dependencies, as Itamar Friedman argued in Qodo’s August 2026 code governance webinar. The answer is a cross-repo dependency graph built from code and kept current as part of the governance layer.

Context is the gap leaders name: in the Qodo State of AI Code Quality 2026 report, 43% of engineering leaders cite insufficient agent context as one of their biggest quality and governance gaps. For a side-by-side view of tools, see the roundup of blast radius tools.

Qodo Turns the Cross-Repo Dependency Graph Into Review Context

A dependency graph tells you what a change can break, and Qodo makes sure review looks there. Qodo is an AI code review and code governance platform that checks each change against the full structure and history of the system, across every connected repository, not against the diff alone. Teams merge sooner with fewer rollbacks: high-velocity teams get the check with nothing to configure, and enterprise engineering teams get the same check on every pull request across hundreds of repositories and Git providers.

You can’t review code with the same tool that wrote it, so Qodo stays independent of the coding agent that made the change.

Qodo builds the graph from code, across repositories

Qodo’s ingest agents parse source files, split code along abstract syntax tree (AST) boundaries, and read configs, CI definitions and documentation to see how each repository connects. A graph database stores call graphs and dependency chains next to PR and commit history, according to Qodo’s platform architecture. The result works as a code knowledge graph for the whole organization, and the context engine reasons across it for impact analysis and review.

Qodo infers typed relationships you can inspect and correct

Qodo discovers relationships between repositories automatically and classifies each one as Code, Service, Data, Pipeline, Docs or Other. Teams can add a relationship by hand or retry one with instructions that describe the dependency. Every relationship has a downloadable markdown file of what Qodo inferred, so tech leads can check the reasoning behind each of the repository relationships.

Relationships span Git providers, so a GitHub service is checked against its GitLab, Bitbucket or Azure DevOps dependency in the same review.

Software Map keeps the code map current

Software Map shows every connected repository as a graph, sized by how connected each one is, with contracts followed to the services that consume them. The map rebuilds itself as pull requests land, so the code map matches today’s system with nothing to configure. Leaders use the Monitor view to see where review findings concentrate, and the Relationships tab switches between Graph and Table views when a list reads more easily than a picture.

Qodo checks the pull request against the dependents

When a pull request changes a shared library, an API contract or a database schema covered by a relationship, Qodo reads the related repositories and traces the impact in both directions. A breaking change appears as a Cross-repo conflict finding with a direct link to the affected lines in the related repository.

The developer decides what happens next: update the change, coordinate with the affected team, or accept the break on purpose. The same review checks the PR against the team’s rules, so one pass covers both standards and blast radius. Qodo learns from which findings developers accept or dismiss on every merged PR, so the next review of a shared contract reflects the calls the team already made.

Qodo gives the coding agent the graph before the edit

The cheapest break to fix is the one the coding agent never writes. Through the Qodo Agentic Toolbox, coding agents in Claude Code, Codex, Kiro or any MCP client ask Codebase Wisdom questions such as “Which services depend on the billing API?” and get answers drawn from the cross-repo graph, PR history and live Git state. Cross-repo tools list the relationships for a repository or explain the link between two repositories, so the agent plans the change across every consumer before it edits a line.

Where Dependency Tracking Breaks Down, and How Qodo Fixes Each Case

The three scenarios below are illustrative composites built from patterns engineering teams describe when they evaluate change impact tools. None is a single customer story.

A typical case: a schema change that breaks a nightly data job. A data platform team drops a column its own services no longer read, and the package and build graphs show no dependents. A reporting job in another repository still reads the table directly, so the break shows up the next morning. Qodo classifies Data relationships between repositories and raises a Cross-repo finding on the pull request when a change to a shared schema reaches a related repository.

A typical case: a shared library change that passes every test the team runs. An enterprise engineering team changes a shared library and runs the full test suite in its own repository, which passes. The services that consume the library sit in other repositories, so their tests never run before the merge. Software Map shows which repositories depend on the library, and the coding agent can ask Codebase Wisdom which services depend on it before the edit.

A typical case: a hand-kept dependency map that drifts. A platform team keeps a service catalog and an architecture diagram, updated at quarterly reviews. Coding agents change code every day, so the map is already behind when a reviewer opens it. Software Map rebuilds itself as pull requests land, and every inferred relationship comes with a markdown file tech leads can check.

Hands-On: Read the Blast Radius of One API Change, Layer by Layer

The scenario below is example data, not a customer report. A team changes the response shape of a shared billing-api endpoint: the amount field becomes an object with value and currency. No package version changes. The consumers that break are a checkout service and a nightly revenue-export data job, each in its own repository.

Package and build layers

1. Check the package layer locally. Run npm explain on the shared client package to see which local packages pull it in. The output lists local consumers only, and shows nothing about services that call the endpoint over HTTP.

npm explain @example/billing-client

2. Check dependents on GitHub. Open the repository’s Insights tab, then Dependency graph, then Dependents. GitHub lists dependents for public repositories only and does not report them for private repositories, according to GitHub Docs.
3. Check the build layer in an Nx workspace. Show the affected projects, then run only their tests.

nx graph --affected
nx affected -t test

4. Check the build layer in Bazel. Query reverse dependencies of the changed target inside the workspace.

bazel query "rdeps(//..., //billing/api:lib)"

Each command answers its own question well, and none of them can see checkout or revenue-export, because both sit in other repositories and neither declares a package dependency on billing-api.

Cross-repo layer with Qodo

5. Open the Software Map. In the Qodo portal, go to Repositories, then the Relationships tab, then Graph, and narrow the map to billing-api. The map shows a Service relationship to checkout and a Data relationship to revenue-export. Switch to Table view for type and description, and download the relationship markdown to check what Qodo inferred. Blur real organization, repository and people names in any screenshot.
6. Ask before the edit. Install the Qodo Agentic Toolbox and ask the coding agent about the dependents before it writes the change. The agent calls Codebase Wisdom and the cross-repo tools, and plans updates for both consumers.

curl -fsSL https://get.qodo.ai | sh
qodo tools
qodo cross-repo overview

Prompt for the coding agent: “Which repositories depend on the billing-api invoice response, and what breaks if amount becomes an object?”

7. Open the pull request. If the PR still changes the response without updating a consumer, Qodo raises a Cross-repo conflict finding linked to the affected lines in checkout. If the consumer fix lives in its own open PR, link that PR in the description so Qodo evaluates the conflict against that branch rather than main.

Nnenna Ndukwe

Developer Relations Lead

Pro Tip

Pro tip

Keep the package and build layers for version bumps and test selection. Use the cross-repo layer for API, data and pipeline contracts, where the costly breaks live.

Summary

Every team already has dependency graphs, and each one stops at a boundary, while blast radius lives in the APIs, shared data and pipelines between repositories. Read a dependency graph backwards to find the dependents, weigh each edge by type, and let review effort follow blast radius rather than diff size. Qodo builds the cross-repo dependency graph from code, keeps it current on every PR and reviews each change against it, so high-velocity teams and enterprise engineering teams both merge sooner with fewer rollbacks.

FAQs

What is a dependency graph in software?

A dependency graph is a directed graph where each node is a unit of software, such as a package, service or function, and each edge points to something the unit needs. Direct dependencies are one edge away, and transitive dependencies sit at the end of longer paths. Read backwards, the graph gives you blast radius.

What tool can identify cross-repository dependencies and blast radius before a code change?

Qodo discovers relationships between repositories automatically, classifies them as code, service, data or pipeline links, and shows downstream dependents on the Software Map. On each pull request, Qodo traces the impact in both directions and raises a Cross-repo conflict finding linked to the affected lines in the related repository.

How do I check blast radius before my coding agent makes changes?

Let the coding agent query the cross-repo graph before it edits. With the Qodo Agentic Toolbox installed, the agent asks Codebase Wisdom which repositories depend on the code it is about to change. Qodo then reviews the pull request against the same graph and the team’s rules.

What is the difference between a dependency graph and a code graph?

A code graph is one kind of dependency graph, with functions, classes and files as nodes and calls and imports as edges. A dependency graph is the broader “needs” relation, and can sit at the package, build target, service or repository level. The code graph glossary entry covers ASTs and call graphs in depth.

Is GitHub’s dependency graph enough to see blast radius?

GitHub’s dependency graph shows package dependencies, versions, licenses and known vulnerabilities, and lists dependents for public repositories. The package graph does not show API, data or pipeline consumers in other repositories, where most breaking changes land. Use the package graph for supply chain checks and a cross-repo graph for blast radius.

We already have a service catalog or knowledge graph. Why add another?

Keep the catalog for ownership and declared links. A catalog shows what people registered, while a code-derived, cross-repo dependency graph shows what a change actually reaches and stays current as pull requests land. The value comes from wiring the graph into review, so every change is checked against its real dependents.

Does a cross-repo dependency graph catch third-party dependency conflicts?

Version clashes between third-party libraries live in the package graph and in software composition analysis tools that read it. Qodo’s cross-repository review focuses on the code, service, data and pipeline relationships between your own repositories. Run both, because each catches a different kind of break.