Production Incidents: Why Small Changes Cause Big Outages

The Pattern

You've seen this movie before:

• Developer makes a small, reasonable change
• Code review approves it—looks fine
• Tests pass
• Deploy to production
• Something unrelated breaks catastrophically

The postmortem reveals: the changed code had hidden consumers. Something depended on behavior that wasn't documented, tested, or obvious.

Why Tests Don't Catch It

Unit tests verify the changed code works correctly in isolation. Integration tests cover known integration points. But neither catches:

• Services that call your code through indirect paths
• Consumers that rely on undocumented side effects
• Systems that depend on timing or ordering
• Code that reads from databases your change affects

You can't test what you don't know exists.

The Blast Radius Problem

Every change has a blast radius—the set of things that could break. The problem is visibility. Without a complete map of dependencies, you're estimating blast radius by intuition and tribal knowledge.

Sometimes intuition is wrong. Sometimes the person with tribal knowledge is on vacation. Sometimes the dependency was added last week and nobody knows about it yet. This is why security auditing requires more than just code review.

Seeing Before Changing

What if, before any change, you could see:

• Every function that calls this code
• Every service that depends on this data
• Every path through which this change propagates
• The complete blast radius, visualized

This is what code intelligence provides. Not guessing. Not hoping tests catch it. Actually seeing what your change affects.