Dependency Blast Radius: which call sites actually break

Changing a shared function is easy. Knowing what that change does to every caller is the hard part. The diff shows the function you edited, but not the twelve files that call it, and a reviewer approving the pull request usually has no quick way to see them. Dependency Blast Radius is the part of bugweg's review that fills that gap: when a PR changes a function's signature, it finds the places that call that function and flags each one as safe, at-risk or breaking.

What triggers it

Blast Radius runs on pull requests that reach bugweg's deeper review tier (medium risk and above) and change a function's parameters or return type. Lower-risk PRs still get bugweg's regular review, just not this step. bugweg parses each changed file at the base and head commits, compares function signatures, and keeps the functions whose signature actually changed. Edits inside a function body that leave the signature alone do not trigger it; the regular review still covers those. It works on TypeScript, Python, Go, Java and Ruby files.

This check runs on the Team and Enterprise plans and during the free trial; it is not included in the Developer plan.

Finding the call sites

For each changed function, bugweg reads the repository's file tree at the PR's head commit and scans files in the same language for calls to that function by name. It then takes a few lines of context around each call. It does this from a fresh read of the repository on every PR rather than from a stored call graph, so the results reflect the code as it is in that PR.

Safe, at-risk or breaking

All the call sites for one changed function go to Claude Sonnet in a single request, together with the old and new signatures. Each call site comes back with one of three labels. Safe means the call still matches the new signature. At-risk means it might not, or the snippet is too ambiguous to tell. Breaking means it no longer fits the new signature. When the context is unclear, bugweg picks at-risk rather than guessing safe.

The results appear in the pull request's bugweg review, next to the other findings, before anyone merges. A reviewer can start from the breaking call sites and use the at-risk ones to focus their own review.

A concrete example

Say a team changes a shared TypeScript helper, parseDate(input: string): Date, so that it returns Date | null for bad input instead of throwing. The return type changed, so Blast Radius picks it up. A caller that already checks for null before using the result would come back safe. A caller whose next line calls a method on the result, such as parseDate(raw).getTime(), no longer fits the new type, and that is visible in the snippet itself, so it would come back breaking. A caller that hands the result to another function without a visible null check can't be judged from a few lines alone, so it would come back at-risk rather than safe. A caller wrapped in a try/catch that was written for the old throwing behavior still compiles if nothing downstream needs a Date, but it may now let bad input through silently, which is the kind of case at-risk is for.

Where it stops

The call-site search is a text match on the function's name, not a full parse of the program. It can miss calls that go through a re-export or a renamed import, and it can pick up an unrelated function that happens to share the name. The verdict step leans toward at-risk for ambiguous snippets, which helps with the second problem but not the first.

The scan also has limits that keep review time and cost predictable: up to five changed functions per PR, up to 40 files and 15 call sites per function, and 120 files in total. In a very large repository, some callers may fall outside those limits. Blast Radius is a review aid that points at the call sites most likely to need attention. It does not replace tests, and a PR with no breaking call sites listed is not proof that nothing downstream will fail.

Where Blast Radius fits in a review

Blast Radius is one of several checks bugweg runs on a pull request. Bug Genealogy looks at whether a new bug matches one the repository has seen before, and the Recurrence Firewall stops fixed bugs from coming back. Blast Radius covers a different question: who depends on the code that just changed. The features page lists each check and what it does today.

Blast Radius shows what a change can break; the Test Coverage Gap Localizer shows whether the changed lines are tested at all.

To see it on your own code, open a pull request that changes the signature of a function other files call, and compare bugweg's call-site list with the callers you would have checked by hand.