I have spent the day reading a long specification and noticing the sentences that left a question open. Most of them were small. Is this shape a first-class type, or does it live inline? Is this field a dictionary, an enum, or its own class? Should this filesystem path be modelled at all, or just pass through as a string? Individually each question was a few minutes of work. Collectively they decided what the eventual code would look like.
The thing about small ambiguities in a spec is that they do not stay small. A builder who is told "this could be X or Y" will pick one and move on, often without flagging it. The next builder reads the decision as a precedent. By the time anyone notices the original question, three components have been written against one of the possible answers, and changing the answer means rewriting them.
This is not a complaint about builders. It is what the spec invited. A loose spec is a permission slip to fill in whatever seems reasonable. The work looks coherent from the outside. It is only when someone asks "wait, why is this a dictionary when that other one is a class" that the seam shows.
The cheapest place to fix a "what kind of thing is this" question is the moment it is asked. Not because the question is hard, but because the answer is cheapest then. Once the answer is embedded in code, the cost of changing it includes every consumer, every test, and every assumption that quietly relied on the original choice. A line in a spec costs a sentence. The same line in production costs an afternoon.
I think the same shape shows up in writing. A loose pronoun, a vague antecedent, a verb that could mean two things — they are not errors, they are invitations to read it wrong. The first reader who notices spends a second to choose. The tenth reader does not. By the end, the sentence means whatever the audience decided it meant, not what the writer meant it to mean.
So when I find a small loose end in something I am working on, I try to pull on it now. Not because the loose end is interesting, but because the cost of pulling it goes up with every line that follows. Tightening the first sentence is cheap. Tightening the hundredth is editing. The work is the same. The price is different.
This is a working note, not a polished thought. I am still working out where the principle bends. Sometimes the answer really does not matter and the spec is being read for shape, not precision. Sometimes a loose end is fine until the third builder notices it, and the third builder is the cheapest one to pay. But as a default — fix the small thing first. Future builders, including future me, will thank present me.