A code request came back close but wrong — do you amend it in the same thread, or start clean?

## What the thread is still doing to the next answer A follow-up is not a fresh question. The near-miss, your correction, and everything you said before them are all still present when the next answer is produced, and they carry weight. That is exactly why amending works when it works: you do not have to restate the format, the record type, or the constraint you already gave, and you do not risk losing a part of the result you were happy with. It is also why amending fails when it fails. **A correction applied to an approach tends to be absorbed by that approach rather than to replace it.** You asked for a parser; it came back reading the whole line into a map of column names first, then assembling a record from the map — a shape you do not want. You say "do not build an intermediate map". What often comes back is the same structure with the map made local, or renamed, or built lazily. Nothing there is disobedient; the answer is doing what a correction invites, which is to adjust the thing in front of it. ## Shape wrong or decision wrong — the question that decides it | What the near-miss got wrong | What it looks like | The cheaper move | |---|---|---| | One decision inside a structure you accept | Right shape, wrong unit, wrong edge case, wrong field | **Amend** — name the decision, keep everything else | | A convention or a naming choice | Compiles, composes, reads wrong for the house | **Amend** — cheapest case of all | | The approach itself | The structure is not the one you would have written | **Restate** — corrections here become patches | | What the request left ambiguous | Both readings satisfy your words | **Restate**, with the ambiguity closed | | The task, not the request | No wording produces something usable | Neither — split the task or do it yourself | The last row is the honest one. Not every near-miss is a defect in the request. Sometimes the unit is genuinely too large, or the decision genuinely requires something the request cannot carry — and there is no phrasing that fixes it. Recognising that early is worth more than another two turns. ## The signs you are patching rather than correcting - **The fix is exact and local.** You named one thing, exactly that thing changed, and nothing adjacent moved — on a structural objection that usually means the structure survived. - **You have said the same thing twice** in different words. The second phrasing rarely carries new information, and a third almost never does. - **The result is getting longer** with each turn rather than simpler — accommodation being added around a shape rather than the shape being replaced. - **You cannot say what the current request is** without reading back through the thread. That is a reliable sign there is no longer one coherent request, only a stack of amendments. ## What a clean restatement costs, and what it is not 1. **It costs whatever the near-miss got right that you never wrote down.** Before discarding, take the parts you liked — the error handling, the field boundaries you agreed with — and put them into the new request as constraints. Otherwise you will spend a turn re-deriving them. 2. **It costs a turn.** On a bounded request that is small, which is the whole reason this decision is easier here than on a long session. 3. **It is not starting over.** The near-miss is the most useful thing you have: it is evidence about which sentence in your request permitted the wrong reading. A clean restatement is the first request written by someone who has seen a wrong answer. Whether to repair the produced code by hand instead of asking again is a different decision with its own answer, and it is not this one; this is about where the next *request* goes. ## What neither move fixes Neither amending nor restating helps if the problem was never in the wording. If two implementations genuinely satisfy everything you can say about the task, no amount of restating narrows it — you have to add a fact, decide the ambiguity yourself, or make the unit smaller. And neither move removes the reading: a corrected answer is a new answer, and the correction you asked for being present does not mean the parts you already accepted came back unchanged. ## Answering this in an interview Give the criterion, not a preference. *Was the structure right and one decision wrong, or was the structure wrong?* That single question decides it, and it is answerable from the result you are holding. Then name the mechanism — what is already in the thread shapes what comes next, which helps you when you accept the shape and hurts you when you do not — and the tell, which is a correction that lands exactly where you pointed and nowhere near the structure. Close with the limit: some near-misses are not about the request at all.