The most expensive bugs aren't the ones caught in code review. They're the ones that pass code review because the reviewer didn't know about a dependency three layers deep.
This isn't a code quality problem. The change to Function A was correct. The code review was thorough. The bug exists in the gap between what the reviewer can see (the diff) and what the system actually does (the full call graph).
A call graph maps every function-to-function relationship in your codebase:
authMiddleware.validateToken()
→ sessionService.getSession()
→ redisClient.get()
→ sessionStore.validate()
→ cryptoUtils.verifySignature()
→ userService.getPermissions()
→ permissionsCache.get()
→ database.query()
This isn't just "what imports what." It's the runtime execution path — what actually gets called when this code runs.
Before any code change, you should know:
The union of these is the "blast radius" — everything that could potentially be affected by your change.
The difference: 10 minutes of call graph analysis vs. 4 hours of production incident response.
The Session Timeout Bug: An engineer changed the session TTL from 30 minutes to 60 minutes. Seemed harmless. But the WebSocket service had a hardcoded 30-minute reconnection timer that assumed sessions would expire at 30 minutes. After 30 minutes, WebSocket connections would reconnect but find a valid session, creating duplicate connections. Memory usage climbed until the service OOMed.
Call graph would have shown: sessionConfig.TTL → read by sessionService.createSession() AND websocketService.reconnectTimer(). The dependency is visible.
The API Response Change: An engineer added a field to an API response. Non-breaking change, right? Except a downstream consumer parsed the response and had a strict size check for caching. The larger response exceeded the cache size limit and started bypassing the cache. API latency increased 300%.
Call graph shows: apiController.getUser() → consumed by mobileApp.userProfile() AND cacheProxy.intercept(). The cache dependency is visible.
Not all call graphs are equal. Useful ones need:
This is what Glue builds during codebase indexing. Every function call, every dependency, every transitive path — mapped and queryable. So when you're about to change a function, you know exactly what you're affecting before you deploy.
Call graph blindness is one of the costliest forms of the Understanding Tax. Engineers can't protect against dependencies they don't know exist.
For a proactive approach to using code intelligence for reliability, read Incident Prevention Using Code Intelligence.
Glue builds full call graphs during codebase indexing, making blast radius analysis a pre-code intelligence query — not a post-incident discovery.