Main idea

Some defects come not from the code but from what preceded it: an incomplete specification, an ambiguous product decision, an edge case never considered, a poorly understood flow. The observation is usually used to exonerate — "it's not a bug, the spec was vague". It actually leads somewhere else.

If the framing is not clear enough to ship something correct, whoever has to ship it can say so and stop. Refusing does not mean blocking: it means sending the request back for clarification — the expected behavior, the edge cases, the acceptance criteria, the data, the dependencies, the risks. Asking before coding costs one discussion; coding in the vague costs a shaky feature, then defects, support, rework and trade-offs to be made all over again.

The foundation is simple: you cannot guarantee the quality of what you do not understand. A developer who executes an ambiguous request settles the ambiguities on their own, without saying so, and often without knowing it.

Why it matters

This turns a recurring complaint into a right that comes with a duty. As long as the vague specification is only a grievance, it produces defects that are then blamed on whoever failed to ask the question.

It also pinpoints where product responsibility and technical responsibility meet: product has to clarify its choice, engineering has to refuse to turn a strong ambiguity into fragile code.

Nuances and limits

The right to refuse is quickly corrupted. Used to obtain an exhaustive specification before any code, it rebuilds a waterfall cycle and denies the share of uncertainty the team is supposed to absorb.

The line is not "everything is written" but "I know which behavior I have to make true" — a boundary that depends on the team's shared context, and that no template fixes in its place.

Open questions

• Who arbitrates when product judges the request clear enough and the development team judges the opposite?