The agent filled the missing config with a default and the misconfiguration went quiet

A report failed locally because REGION was unset: the client tried to build a target endpoint from an empty string and threw a parse error. The agent traced the line, changed it to read process.env.REGION ?? "us-east-1", re-ran the service, watched it boot, and closed the change. The parse error was gone. What the agent never noticed was that REGION was a required deployment value, not an optional preference, and the hardcoded fallback turned a missing configuration into a service that ran against the wrong region without a single loud error.

The agent had removed the crash. It had also removed the signal that told the operator a required setting was missing.

Why a missing value becomes a fallback

Given a local run that refuses to start, the agent's shortest path is to make it run here. A nullish-coalesced default removes the traceback in one edit, the boot succeeds, and the loop reads that as solved. Search tools reward the local symptom: the empty string caused the parse error, so filling the empty string feels like the fix.

What that reasoning skips is whether the value is required. A required input has no legitimate default; when it is absent, the correct behavior is a startup error that names the missing setting. An optional input has a real intended default that ships regardless of environment. The agent collapses both cases into the same ?? operator because the task frame only says "make it not crash," never "is this value allowed to stand alone."

The local environment hides the distinction. On the developer's machine the variable may also be unset, so the fallback looks normal; there is no staging complaint to challenge it, and the test suite never asserts that a required value reaches the client.

What a silent default leaves behind

• The wrong target runs in silence. The service boots against the fallback region instead of failing, so requests flow to an endpoint nobody intended for that deployment.
• Required input reads as optional. A reader sees a ?? default and assumes the setting can be omitted, when in fact omitting it is a configuration mistake.
• Environment drift becomes invisible. Local, staging, and production all start clean even when only one of them set the value, so the missing setting never reaches a deploy checklist.
• Monitors watch the wrong signal. Health checks see a booting process and report healthy; nothing alerts on traffic bound for the fallback target because the process itself did not fail.
• The commit records the workaround, not the requirement. A message like "default region" leaves no trace that this value must be provided, so the next pass cannot recover the intended contract.

The tell is a completion summary that says the service now boots, with no mention of which environment supplies the value or what happens when it is omitted.

Separate required from optional before you reach for a default

Before coalescing any configuration, decide which kind of input it is:

• Fail fast on required values. Parse the config at startup and throw a clear error listing every missing required setting; a required region, tenant, or endpoint should refuse to boot rather than substitute a guess.
• Reserve a real default for optional settings. Coalescing is appropriate only when the default is an intended behavior that holds with or without configuration, such as a request timeout or a page size, not a deployment identifier.
• Name the requirement in code and docs. A required input should be declared as such in the config schema, and its absence should produce a message that tells the operator exactly which variable to set.
• Assert the value reaches the client. A boot test that runs with the required value present does not cover the missing case; add the negative path where the process must refuse to start.
• Log the source of the effective setting. A startup line that reports region = configured vs region = fallback makes a default's presence visible instead of blending into a normal boot.

The same separation belongs in a declared contract: required fields are rejected when missing, and optional fields may carry a documented default. Keeping that distinction machine-checked, instead of leaving it to a comment, is the reason I build local-first tooling like Powerduck around a validated spec rather than prose.

Booting is not the same as being configured

A fallback default removes the immediate crash the agent was asked to fix. It does not verify that the deployment supplied the value that was actually required. Until missing required input fails loudly, a clean boot means the process started, not that it started against the right target.