Blast radius

Reviewing every agent change with equal care is not thoroughness, it is a way of running out of attention before you reach the change that mattered. Blast radius is the variable that tells you where to spend it.

Editing a test fixture and editing a migration are not the same act. One is reversible in seconds; the other can lose data.

What widens it

• Reversibility. Can you undo this with a revert, or has state changed irreversibly? Deletes, migrations, and sent messages do not revert.
• Reach. One module, or a shared interface every caller depends on?
• Environment. Local, staging, or production.
• Audience. Nobody, your team, or every customer at once.
• Detectability. A crash is loud. A subtly wrong calculation in a report is silent for months, which makes a small-looking change large.

Using it

Blast radius is only useful if something changes as it grows:

• Scale review to it. Skim a fixture change. Read a migration line by line. This is the practical version of not pretending you review everything equally.
• Scale permissions to it. High-radius actions should need explicit approval, which is what a permission mode encodes.
• Shrink it rather than guard it. Often the better move. Feature flags, staged rollout, and reversible migrations turn a high-radius action into a low-radius one, which is more reliable than reviewing harder.

Why it matters more with agents

Volume. When an agent opens ten changes an hour, uniform review collapses and the honest options are to scale review by consequence or to stop reading. The failure mode is uniform *shallow* review, where the migration gets the same glance as the typo fix.