The rule
Know the callers before you change the callee. Any edit to code more than one place depends on gets a dependency check before the diff, not a review comment after it. Silent breakage in a shared module costs more than the fix was ever worth.
When to run it
Before touching anything that looks like a hub, not a leaf — shared services, core routing, a library imported from three or more places. If you're not sure whether a file is a hub, that uncertainty is the answer: check first.
The play
- Identify the exact symbol you're about to change, not just the file — a function called from three sites is a different risk than the file that happens to contain it.
- Run impact analysis on that symbol and get the real caller list, not a guess from memory or a stale mental model.
- Read the actual call sites, don't trust a one-line summary — grep-level context misses type coercion, ordering assumptions, and error-handling contracts the summary can't see.
- Classify the risk honestly: LOW (one caller, isolated), MEDIUM (a few callers, same layer), HIGH or CRITICAL (cross-cutting, many callers, or anything touching auth, money, or data integrity).
- On HIGH or CRITICAL, stop and say so before proceeding — narrate the blast radius to whoever is waiting on the change, then get a clear go-ahead to continue.
- After the edit, re-run the same query. The caller list you audited going in should still be the caller list that exists coming out.
Where it breaks
"It's just one function" said about a function nine call sites depend on. And trusting an index that's gone stale — a dependency graph built before today's commits lies with total confidence, which is worse than admitting it doesn't know.