You read the response and decide it is about 80% right. So you fix the last 20% yourself, ship it, and move on.
That is a reasonable way to work. It is also the point where two very different second moves are available, and most people never notice there was a choice.
🔍 The two second moves
Say you asked for a retry policy for a pipeline step. What came back retries three times on any failure, with no backoff.
You can see two problems. There is no exponential backoff, so a struggling downstream service gets hit three times in quick succession. And it retries on every error type, including the ones that will never succeed on a retry, such as a malformed record.
Move one, the patch. You add backoff yourself and filter the error types. Fifteen minutes. It works.
Move two, the follow-up. You say what is wrong and ask again.
Most people take move one, and the reason is not laziness. Patching feels like ownership. You read the code, you found the problems, you fixed them. That is what an engineer does. Asking again feels like handing back a piece of work you already understand.
But your patch fixed the two problems you spotted. It did not touch the third one, which is that a retry on a partially written record can produce duplicates, because the step is not idempotent. You did not miss that through carelessness. You were checking the retry logic, and idempotency is a different question.
🧠 Why this lands on intermediates
Beginners do not usually reach the 80% judgment. They accept or they get stuck.
Seniors have usually been through the version of this where their own patch was the thing that broke, so asking again is already a habit.
Intermediates are at the exact point where the judgment to spot problems has arrived, and the habit of using it well has not. You now have enough skill to improve the answer yourself, so you do, every time. The skill that arrived first is the one that gets used.
There is a second reason, and it is about the shape of the work. Intermediates are usually building components rather than single queries. A component has more surface area than you can check in one read, so the gap between "the problems I found" and "the problems that exist" is wider than it was earlier in your career, at exactly the moment you have started trusting your own read.
✅ Take the second turn, but restate rather than append
Here is where the common advice is wrong, and where the research is genuinely useful.
The obvious way to take a second turn is to append. You say "add exponential backoff and only retry transient errors" and send it. This is what almost everyone does, and it is the weaker option.
A large study presented at ICLR in 2026 tested 15 models across more than 200,000 simulated conversations and found that performance dropped by an average of 39% when a task was spread across turns rather than stated once. The mechanism is specific and worth knowing. Models commit to assumptions early, produce a solution before they have enough information, and then hold on to that solution. As the paper puts it, once a model takes a wrong turn, it does not recover. It layers corrections on top of the mistake instead of starting again. The study also found that middle turns get very little attention, and that larger models were no better at avoiding any of this.
So appending sits directly on the failure mode. You are asking the model to fix an answer it is already committed to, and it will patch rather than reconsider, which is exactly the thing you were trying to avoid doing yourself.
Restating works differently. Instead of "add backoff," you send the whole problem again with the correction included:
Retry policy for a pipeline step calling a third-party API. Around 40,000 calls per run. Needs exponential backoff. Only retry transient errors, not malformed records. The step writes partial records, so retries must be safe to repeat. What breaks?
That is one turn, fully specified, with what you learned from the first answer folded in. The study's own suggested mitigation is the same idea: consolidate the context before asking again, rather than relying on the conversation history.
The first answer was not a deliverable. It was a way of finding out what you had failed to specify.
⚖️ The objection worth taking seriously
The weak version is "sometimes the first answer is genuinely fine." True, and it costs one turn to find out.
The strong version comes from the same research I just used: multi-turn measurably makes things worse, by 39% on average. If a second turn degrades quality, the honest advice is to ask better once and stop.
I think that is largely right, and it is why the recommendation here is not "iterate more." The study measured conversations where requirements arrived piece by piece, and that is a real description of how most people use these tools. If your second turn is "no, add backoff," you are inside the pattern the study measured, and you should expect the result to get worse rather than better.
The evidence for iteration helping is narrower and has conditions attached. One study found that conversations with human feedback improved results by roughly 16 to 18 percentage points over single-shot prompting. Another found multi-turn prompting produced better fault detection, at 187% more compute. Both involved a person supplying real information the model did not have, rather than nudging it toward a fix.
So the honest version of this advice is conditional. Take a second turn when the first answer taught you something you had not specified. Restate the whole problem rather than appending to it. If you are only nudging, ask better once and take the single-turn answer instead.
🎯 The takeaway
The second turn is worth taking only if you restate.
1. Treat the first answer as a specification test. What it got wrong tells you what you failed to say.
2. Restate the whole problem with that correction included. Do not append "also add backoff" to a conversation. Send the full thing again.
3. If you have nothing new to add, stop. Nudging a committed answer makes it worse, and the research is clear about that.
Your patch fixes the problems you found. A restated question finds the ones you did not.
