impact_analysis

The Question Before Every Deploy

Every time you push code, you are implicitly answering: “What could break?” Usually, the answer is a gut feeling based on which files you changed. impact_analysis replaces that gut feeling with data.

Given a git ref (a commit, a branch, or a range like HEAD~3), it identifies exactly what changed at the symbol level, traces which other symbols depend on those changes, determines which tests cover the affected code, and assigns risk scores.

impact_analysis(repo="local/my-project", since="HEAD~3")

What It Identifies

Changed Symbols

Not just which files changed, but which functions, classes, and exports changed. A file with 50 functions where you modified one has a very different risk profile than a file with 50 functions where you modified all of them.

Blast Radius

For each changed symbol, the tool traces its callers to identify every symbol that depends on it. If you changed the return type of calculateDiscount, every function that calls calculateDiscount is in the blast radius. This uses the same call graph that powers trace_call_chain, applied automatically to every changed symbol.

Affected Tests

The tool cross-references the blast radius with test files to answer: “Which tests exercise the code I changed?” This is the affected_tests field in the response. It tells you the minimum set of tests that should pass before you ship.

Risk Scores

Each changed symbol receives a risk score based on its connectivity in the call graph, the nature of the change (signature change vs body-only change), and whether test coverage exists. High-connectivity symbols with signature changes and no tests score highest.

Benchmark

Approach	Tokens	Calls	What You Get
git diff + grep for each symbol	4,560	10	Changed files, manual tracing
impact_analysis	1,409	1	Changed symbols, blast radius, affected tests, risk scores

The native approach requires running git diff to find changed files, then grepping for each changed function to find its callers, then searching for test files that reference those callers. Each step requires parsing the output and feeding it into the next step. Ten calls is a conservative estimate for a change that touches three files.

Pre-Deploy Safety

The most valuable use of impact_analysis is as a pre-deploy gate. Before pushing or merging:

1. Run impact_analysis(since="main..HEAD") to see the full impact of your branch
2. Check affected_tests to know which tests to run
3. Review high-risk symbols, those with signature changes and many callers
4. Verify that no high-risk symbol lacks test coverage

Integration With Other Tools

impact_analysis combines the capabilities of several other tools into a single workflow:

• changed_symbols identifies what changed at the AST level
• trace_call_chain (callers direction) computes the blast radius
• find_references cross-references with test files

Running these separately would require understanding the output of each and feeding it into the next. impact_analysis chains them automatically and presents a unified risk assessment.

Common Patterns

• PR review: Run on the PR branch to understand full impact before approving
• Hotfix triage: Run on a single commit to quickly assess what a production fix might affect
• Release planning: Run on a range of commits to see accumulated risk across a sprint
• Post-incident: Run on recent deploys to identify which change could have caused an issue