If a default is the choice most people end up living with, it follows that a mistake in the default is a mistake multiplied by however many people never touched the setting. This is easy to say and easy to underweight in practice, because the moment of deciding a default doesn’t feel any weightier than deciding any other value in a config file — it’s one line, reviewed like any other line, shipped like any other line. But its blast radius is structurally different from almost everything else in the system: a bug in an option only 2% of users ever enable affects that 2%; a bug in the default affects the other 98%, silently, often for a long time before anyone notices, because there’s no one actively watching a setting they never chose to touch.

This asymmetry is why default-related incidents have a particular shape when they surface: not “user X reported this,” but “we just realized this has been wrong for everyone since we shipped it.” The rarely-used option gets exercised by people who are paying attention to it, so it tends to get feedback fast when something’s off. The default gets exercised by people who aren’t looking, so a subtle wrongness in it can survive for a very long time completely unreported. This isn’t because the default is more likely to be wrong — it’s because problems in it are far more likely to go silent. Silence gets mistaken for correctness, when it’s often just the absence of anyone positioned to notice.

The practical upshot is that defaults deserve a different level of scrutiny before they ship, proportional to how many people will experience them without ever making an active choice. A change to a rarely-touched option can reasonably go out with lighter review, because the population who’ll hit it is small, self-selecting, and attentive by definition — they went looking for the option. A change to a default deserves the review budget of something used by nearly everyone, because that’s exactly what it is, regardless of how it’s tucked away in the code. Teams that review code by how much it changes, rather than by how many users experience the result, systematically under-scrutinize the highest-blast-radius lines in the system.

There’s a related trap worth naming: reasoning about a default from your own vantage point instead of the silent majority’s. The person shipping a default usually is the kind of user who reads documentation, notices settings, and would change the default if it didn’t suit them — which means their intuition about “is this default fine” is trained on exactly the population least affected by getting it wrong. The people actually exposed to a bad default are, by construction, the ones who wouldn’t have gone looking to fix it. Designing defaults well requires deliberately reasoning about users unlike yourself — the ones who’ll never open the settings screen, never file the issue, never notice anything except that something felt subtly off, if they notice at all.

None of this means treating every default with paralytic caution — most default choices are genuinely fine and the system should keep moving. It means recognizing that the review effort you spend on a default should scale with its reach, not its visibility in the diff, and that “nobody’s complained” is not evidence a default is right — it may just be evidence that the people affected never had a way to complain. When something in a system quietly touches everyone, it has earned scrutiny in proportion to that reach, whether or not it looks like a big change.