Dashboard

How to Get AI to Edit a Document, Not Rewrite It

Ask for a fix to one sentence and you get a different document. Constrain the output format instead of asking for restraint, and the edit stays where you put it.

Cecilia Iona
Cecilia Iona
Senior Editor, AI & Product
15 September 20261 min read

How to Get AI to Edit a Document, Not Rewrite It

To get AI to edit instead of rewrite, stop asking it to improve the document and start asking it to return only the parts it changed. The rewrite habit is a scope problem, not a politeness problem, and no amount of asking nicely for a light touch fixes it reliably. Constrain the output format and the behaviour follows.

The failure is familiar. You paste in a page you are happy with, ask for a fix to one awkward sentence in the third paragraph, and receive a fluent, competent, entirely different document. Your jokes are gone, your specific numbers have become approximations, and the one sentence you asked about reads fine now, along with forty others you never wanted touched.

Why it rewrites

Three things are happening at once.

The model is completing a document, not patching one. Given a document and an instruction, the highest probability continuation is another document. Returning eleven words is a statistically unusual response to a request that included two thousand.

Improve is not a scope. It is an open licence, and a model given an open licence will apply it everywhere, because applying it in one place and not the other places would be inconsistent, and consistency is rewarded.

And regression to the middle is the default. Absent a reason to keep your specific choices, the model reaches for the more common phrasing. That is what makes rewrites feel flattened even when each individual sentence is defensible.

The pattern that works

Change what you ask for, not how you ask for it. Instead of the whole document back, ask for the changes as a list:

Here is a document. Do not return the document.

Return only the edits you propose, as a numbered list. For each one:
- the exact original text, quoted
- the replacement text
- one short sentence on why

Only propose edits that fix a factual error, an unclear sentence,
or a grammatical mistake. Do not propose edits for style, tone,
word choice or length. If a sentence is merely not how you would
have written it, leave it alone.

<document>
...
</document>

This works for a structural reason rather than a persuasive one. There is no longer a slot in the output where a full document could go. The model cannot rewrite everything, because the format it has been given has room only for discrete changes, each of which must be justified individually. Marginal edits do not survive having to write a reason next to them.

Quoting the original text exactly is the part people drop, and it is the part that makes the whole thing auditable. You can find each edit in your own file, apply the ones you want, and ignore the rest. The separation of instruction from material using tags is the same technique described in using XML tags in AI prompts, and it is the first thing Anthropic's guidance on structuring prompts with XML tags recommends for exactly this reason: the model needs to know which part is the thing and which part is the request about the thing.

One variation is worth knowing. If you want a sense of how invasive the model thinks the edit should be before you commit to a format, ask for the list twice: once restricted to errors only, and once with style included, as two separate lists. Comparing them tells you quickly whether the document has a real problem or whether you were about to accept a preference dressed up as a correction. Most of the time the errors-only list is four items long and the style list is forty, which settles the question.

Naming what is off limits

A short protected list prevents most of the damage, and it should name the things you know a model likes to normalise:

  • Do not change any number, date, name or quoted figure.

  • Do not change headings.

  • Do not merge or split paragraphs.

  • Do not replace a contraction with its expansion, or the reverse.

  • Keep every sentence that is already correct, even if you would have phrased it differently.

That last line is doing the most work. Without it, correct-but-not-my-phrasing is the single largest category of unwanted change, and it is the one that quietly removes whatever made the document sound like a person.

Scoping the edit to a region

When you genuinely only care about one section, mark it and say so. Supply the surrounding text as context that must not change:

Edit ONLY the text inside <target>. The text in <context> is
provided so you understand what comes before and after. Do not
return the context and do not propose changes to it.

<context-before>
[two paragraphs]
</context-before>

<target>
[the paragraph you actually want fixed]
</target>

<context-after>
[one paragraph]
</context-after>

Supplying the surrounding paragraphs matters. Edit a paragraph in isolation and you get something that no longer connects to the sentence before it, which forces a second edit, which reopens the whole document. Giving context without giving permission to change it is the combination that keeps the edit local.

Reviewing what comes back

Even a well scoped edit list needs a pass, and there are two specific things to check.

Check that quoted originals are real. A model reconstructing your sentence from memory rather than copying it will produce a near-match, and if you apply that edit by search and replace you will silently alter a sentence you never read. If the quote does not match your file exactly, reject the edit.

This is easy to automate and worth automating if you do it often. Take the quoted originals, search for each one in your source file, and report any that are not found character for character. A ten line script catches the near-matches that a human eye slides straight past, because a near-match reads as correct. Anything it flags is either a hallucinated quote or a sign the model has been given a different version of the document from the one you are editing, and both are worth knowing before you apply anything.

Check for changed meaning dressed as changed wording. Roughly and approximately are not the same as a number. Usually is not always. These slip through because the sentence still reads well. Asking the model to flag any edit that changes meaning, as a separate list, catches most of them, and it is the same discipline as prompting AI to check its own work.

When a rewrite is the right answer

Sometimes the document genuinely is the problem and protecting it is misplaced effort. A first draft you do not like, a section whose structure is wrong, or text written by someone else that you have no attachment to are all better served by a rewrite than by an edit list. The distinction is whether you are protecting something, not how bad the text is. If you are not protecting anything, ask for the rewrite and give it a clear target, which is the ordinary craft covered in the prompt engineering fundamentals.

A related but separate task is removing information rather than improving text, where the constraint is about what must disappear rather than what must survive. That has its own pattern, in how to prompt AI to redact a document.

Frequently asked questions

Why does it still rewrite after I asked it not to?

Almost always because the output format still allows it. If your prompt says do not rewrite but then says return the improved document, the format wins. Remove the slot where a document could go and the instruction becomes unnecessary.

Can I get a proper diff instead of a list?

You can ask for unified diff format and models will produce it, but line numbers and context lines are frequently wrong for prose, because prose is not line-oriented the way code is. Quoted original plus replacement is less elegant and much more reliable for documents.

Does this work for long documents?

Up to a point. Past roughly ten pages the edits get sparser toward the end, because the middle of a long context gets less attention than the start. Split long documents into sections and run the same prompt per section rather than hoping for even coverage.

Should I keep the edit list?

It is worth keeping for anything reviewed by someone else, since it is a record of what changed and why. For a document that goes through several passes it also stops you re-litigating the same sentence in every round.

What if I want tone changes but not content changes?

Invert the protected list. Name the content elements that must survive unchanged, the numbers, names, claims and structure, and give explicit permission on phrasing. The mechanism is identical, you are just moving the boundary.

How did this land?

About the author

Cecilia Iona
Cecilia Iona

Senior Editor, AI & Product

Cecilia leads the Swarmz editorial desk. She has spent a decade turning complex AI and product topics into writing people actually finish, and she owns the blog's quality bar.

Share

Get the next post in your inbox

One email a month. Product updates, engineering posts, and the best of Built with Swarmz.

I agree to receive emails about AI building tips and Swarmz product news. Unsubscribe any time.