Run Impact Analysis Before a Change with vg impact

Before you refactor, you want to know: what breaks if I change this? vg impact answers that deterministically using reverse reachability and decay confidence. With --tests, it also surfaces exactly the tests to run before shipping.

Prerequisites

• A built code graph from vg build
• A node (function, class, or module) you plan to change

Steps

1. Build the graph

vg build

2. Run impact on a node

vg impact

Pass the node you intend to change. vg impact walks the graph in reverse to find everything that could be affected.

3. Read the blast radius

The result is a structural blast radius — the set of nodes reachable backward from your target. Each result carries a decay confidence: the further a node is from the change, the lower the confidence it is truly affected. Focus your review on high-confidence, close-in nodes first.

4. Surface the tests to run

Add --tests to turn the blast radius into a test plan:

vg impact --tests

This surfaces exactly the tests that exercise the impacted nodes, so you run the right tests instead of the whole suite.

5. Decide before shipping

Use the impacted set and its confidence to scope your change, your review, and your test run. A small, high-confidence radius means a safe change; a large radius signals a risky one.

Verification

Confirm vg impact lists affected nodes and that vg impact --tests returns a concrete set of tests. If the radius looks empty, rebuild with vg build and verify the node resolves with vg show.

Next Steps

• Map node-to-test coverage with vg tests
• Explain an impacted node with vg show
• Trace how two nodes connect with vg path