BlastRadius

About BlastRadius

What inspired us

A small code change can have a much larger impact than the changed lines suggest.

A developer may modify one function, but that function can be used by multiple callers, classes, or workflows. Even worse, the function itself may have a unit test while one of its important callers has no meaningful test coverage.

We wanted to answer a simple question:

“If I change this code, what can actually break?”

That idea became BlastRadius — a lightweight developer tool focused specifically on understanding the impact of code changes before they become regressions.

How we built it

BlastRadius takes a unified diff together with the corresponding Python project and analyzes the change locally.

We use Python's AST capabilities to identify changed functions and methods, resolve their callers, build a lightweight call graph, and determine which affected paths have identifiable test coverage.

The results are combined into a risk score from 0 to 100 and presented through a web interface showing the changed code, affected call sites, coverage signals, and risky paths.

For high-risk uncovered paths, BlastRadius can generate focused pytest checks that exercise the real production caller instead of testing the changed function in isolation.

The architecture is intentionally lightweight: FastAPI for the application layer, Python AST for static analysis, and pytest for validation.

Challenges we faced

The hardest part was not finding a changed function — it was understanding what depends on it.

Real Python projects contain imports, classes, methods, aliases, nested calls, and different ways of reaching the same function. A simple text search is not enough to reliably understand these relationships.

Another challenge was distinguishing between “this function has a test” and “this affected execution path is actually covered by a test.” Those are not the same thing.

We also had to make the system useful when the analysis is uncertain instead of pretending that every dependency can be proven.

What we learned

We learned that code impact analysis is fundamentally about relationships rather than individual lines.

A changed function is only the starting point. The more useful question is what calls it, which paths can reach it, and whether those paths are protected by tests.

We also learned that AI is most useful when combined with deterministic tooling. Static analysis can provide concrete evidence about the codebase, while AI can help interpret context and generate useful tests.

What’s next

Add a selectable Local AI engine powered by GGUF models alongside the deterministic AST engine.
Improve call-graph resolution for more complex Python projects.
Make generated tests more context-aware.
Add stronger pytest validation and automatic correction of generated tests.
Extend BlastRadius toward CI and pull-request workflows.
Explore support for additional languages beyond Python.