Read Your Codebase's Warning Signs Before the Incident, Not After

Post-mortems are useful. They establish what went wrong, build institutional knowledge, and produce action items. They also happen after the outage, after the pager has fired, after the customer has seen the error, after the engineer has spent three hours debugging production.

The code graph doesn't prevent every incident. But it surfaces the structural signature of most of them before deploy.

The incident pattern

Across post-mortems at teams of all sizes, one pattern appears repeatedly:

1. An engineer modified a high-blast-radius node
2. Some callers of that node lacked test coverage
3. The change broke those callers in production

The variation is in the details, which node, which callers, which production surface. The structure is almost always the same. High blast radius + coverage gap = latent incident.

Surfacing the pattern pre-merge

A code graph can compute both halves of this equation for any PR:

Blast radius: traverse the import graph from the changed nodes outward. Count the reachable modules. Flag PRs where the count exceeds your threshold.

Coverage gap: cross-reference the reachable modules with your test coverage report. Identify callers that are reachable but have zero or low coverage.

The intersection, high-blast-radius change, callers with coverage gaps, is your incident risk surface. Surface it in the PR review, before merge.

The deploy gate pattern

The most operationally useful form of this is a deploy gate:

if blast_radius(changed_nodes) > 25
  AND uncovered_callers(changed_nodes).count > 3
  then require_senior_review()

This gate does not block the deploy. It escalates the review. Engineers with high-blast-radius, high-gap PRs get a senior reviewer automatically, and that reviewer knows specifically which callers need attention.

This is better than blanket "require two reviewers on any PR" rules because it is targeted. Low-blast-radius, well-covered changes sail through quickly. The gate activates when it matters.

Vibration: structural churn as a risk signal

Another pre-incident signal: structural churn. A file that is modified in every sprint, whose callers keep changing, whose community membership shifts frequently, this file is "vibrating." High-vibration files are statistically more likely to be the source of future incidents.

Spiderbrain tracks vibration as a graph metric: the change frequency of a node and its immediate neighbourhood over the commit history. High vibration + high blast radius is a compound risk flag.

What the post-mortem becomes

When your team deploys the blast-radius gate and starts surfacing structural risk pre-merge, the nature of your post-mortems changes. Instead of "we didn't know this change would affect that service," the action item becomes "the gate flagged this but was overridden; review the override process."

That is a much better post-mortem to write. It means the signal was there, and you can improve the process for acting on it, rather than improve your ability to guess structural risk in code review.

Starting small

You do not need to deploy a full gate on day one. Start with informational annotations on PRs: "This change has a blast radius of N modules. Here are the top 5 callers." Let engineers see the number. Build intuition. The gate comes later, once the team trusts the metric.

The structural data is available the moment you build the brain. What you do with it is up to you.