Why AI Revisions Get Worse After a Few Rounds
A project lead needs a one-page briefing note on a delayed initiative: what caused the delay, the revised timeline, and a clear recommendation for what happens next. The first draft comes back close but not quite right. The tone reads too neutral for a room of senior managers who want a straight answer, so she asks for more directness. The next version lands better on tone, but it has picked up extra context nobody requested, so she asks for that to be trimmed. Trimming it costs some of the clarity around the revised timeline, so she asks for that section to be expanded again. The expansion pulls a paragraph of risk language into the middle of the note, which quietly shifts the emphasis away from the recommendation, so she adjusts once more.
By round six, the note is accurate, covers every topic it should, and reads smoothly sentence by sentence. It has also stopped fitting on one page, buried the recommendation under two paragraphs of hedged risk commentary, and lost the directness she specifically asked for four rounds earlier. She sends it anyway, because she has already spent forty minutes on it and starting again feels worse than living with the result.
Nothing in that sequence looks like a mistake in isolation. Every single request was reasonable. That is exactly what makes the pattern so easy to fall into, and so hard to notice while it is happening.
Local improvement is not the same as overall improvement
Each round of revision in that example solved a real problem with the version in front of her. The tone genuinely was too neutral. The extra context genuinely was unnecessary. The trimmed section genuinely had lost some clarity. Judged one change at a time, every decision was sound. What went missing was any check on what all six changes did to the document together, because nothing in the process asked that question. The note was evaluated against the version immediately before it, over and over, and never once against the brief that started the whole exercise.
This is the mechanism behind revisions that get worse the longer they continue. Individual edits can each be correct while the document as a whole drifts away from its purpose, because drift is a property of the sequence, not of any single step within it. A prompt that says "make the tone more direct" or "tighten this paragraph" is answered faithfully. Nobody is asking the model whether the fourth change undoes something the second change achieved. That comparison has to come from the person doing the revising, and it only happens if they build it into how they iterate rather than assuming it will happen on its own.
The person causing the drift is usually the last one to see it, simply because they were present for every step and each one felt like an improvement at the time. Six small, defensible decisions can add up to a document that serves its purpose worse than the one three rounds earlier, and there is rarely a single moment where that becomes obvious.
Two kinds of requests, and only one of them narrows the target
There is a useful distinction hiding inside most revision sequences, and it is worth learning to notice it as you go rather than reconstructing it afterwards. Some requests narrow the output towards the original brief: tighten the opening so it leads with the recommendation, remove a background paragraph the reader already knows, cut a section that has drifted off the point. These tend to be specific, and they move the document closer to a defined target.
Other requests are additive and open-ended: make it more comprehensive, can you also cover the timeline risk, could this sound a bit warmer. These are not wrong to ask for. Sometimes the audience genuinely has shifted, or a constraint really has changed, and updating the brief mid-process is a legitimate thing to do. The trouble is that this kind of request quietly moves the target itself rather than moving the document towards a fixed one, and it is easy to make that request without registering that a shift has happened at all. Treating a scope change as though it were a correction is one of the fastest routes to drift, because the output ends up trying to satisfy two different versions of the brief without anyone deciding which one is current.
The fix is not to stop asking for additive changes. It is to notice which kind of request you are making, and to update your reference point deliberately when the scope genuinely has moved, rather than letting the target drift underneath you a sentence at a time.
Hold the brief steady and test every change against it
Before any round of revision, it helps to return to the task as it was originally defined: what the output is for, who is reading it, what it has to achieve, and what it must never do. When a requested change would serve that brief, make it. When it would not, set it aside. When you are genuinely unsure which category it falls into, that uncertainty is itself useful information. It usually means the request is a preference rather than a requirement, and preferences are where drift tends to begin.
This only works if the brief exists somewhere you can actually see it while you are working, rather than somewhere you are reconstructing from memory each time. It does not need to be formal. A few bullet points at the top of the working file, or a sticky note beside the screen, is enough, provided it stays visible across rounds instead of fading into the background after the first one.
Keeping earlier versions visible matters just as much. This is not about version numbers or a formal change log. It is closer to the ordinary discipline any experienced professional applies to a complex piece of work: an awareness of what the last good version actually looked like, held alongside whatever is currently on screen, so a comparison is possible at any point rather than only in hindsight. Without that awareness, every edit is judged only against the version immediately before it, and a document can travel a long way from where it started without a single round ever looking like a step backward.
Knowing when to stop is a skill, not a shortcut
The more useful question, once a few rounds have gone by, is rarely "what else can be improved." It is closer to: is this version still better than the one before it, measured against the original brief, and not just different from it. When that answer feels uncertain, that is usually the moment to stop inspecting individual sentences and read the whole document again as one piece.
It is common to find, on that kind of read-through, that a version from two rounds earlier was actually stronger overall, even though every change since then made some local detail better in isolation. Recognising that inflection point, the moment where further editing starts to subtract more than it adds, is not a failure of diligence. It is a form of judgement that improves with attention, and it is what separates someone who reacts to whatever feels slightly off in the latest draft from someone who is protecting a piece of finished work from being quietly undone by their own good intentions.
Anthony Velland
Interested in going further?
AI Without Guesswork develops this idea of anchored revision as part of a wider method for building AI work you can actually rely on, round after round.
Ad · Amazon affiliate link.
