>
Software

Why every AI rewrite of your docs loses something you meant to keep


Simon Willison linked this week to a short post by Sophie Alpert on what she calls her internal policy on acceptable use of AI writing by engineers. The post makes one claim, then expands on it: every rewrite and rephrase of natural-language text changes its meaning, and if the rewrite is done by anything other than the writer’s own hand, information will be lost. The original quote is in the post; the framing is “you must stand behind every idea and every sentence in your docs.”

This is a useful claim to think about because the same problem applies in reverse. AI-assisted rewrites of human text lose meaning the human meant to keep. AI rewrites of AI text lose meaning that no one ever meant, because the original text did not have a writer behind it. Most “lossy” rewrites in 2026 are rewriting text that started out lossy to begin with, and the second-pass loss compounds rather than recovering.

The core claim, restated without the slogan

The slogan “no lossless transformations of natural-language text” sounds technical, but the underlying point is small enough to restate plainly. Text written by a person carries that person’s mental model. The sentences are not arbitrary. The order is not arbitrary. The word choices are not arbitrary. When something else rewrites the text, that something else does not have access to the original mental model. It only has the surface text. So when it produces a new version, the new version will preserve the surface and lose the model.

This is true for AI rewriting human text. It is also true for a human rewriting another human’s text without context. It is true for translation. It is true for summarization. It is true for transcription. Every transformation between two pieces of text loses information unless the transformation itself is lossless in the same way a CSV-to-CSV round trip is lossless. For natural language, no such round trip exists.

The reason is structural. Natural language is not a format. It is a compressed encoding of a speaker’s mental model, with redundancy, ambiguity, and intentional vagueness all serving as part of the meaning. A rewrite by anything other than the speaker can preserve the surface text and still lose the meaning, because the meaning was never in the surface text to begin with.

What the policy looks like in practice

Sophie Alpert’s rule is short enough to fit on a sticky note: you must stand behind every idea and every sentence in your docs. If a reviewer asks what you meant by a line, “AI wrote that, just ignore it” is not an acceptable answer. The rule is a discipline. It asks the writer to take responsibility for the final text even if the drafting was assisted.

This has obvious applications for engineering documentation, where the cost of a wrong sentence is high. A line that says “the cache will refresh every five minutes” is a contract with the reader. If the cache actually refreshes every thirty seconds, the reader built an incorrect mental model. The line was technically true (it did refresh every five minutes, eventually) but the reader’s model was wrong. AI-assisted rewrites tend to produce this kind of technically-true-but-misleading text because the AI does not know what model the reader is building.

The same rule applies in less obvious places. Pull request descriptions. Incident postmortems. Onboarding documents. Architecture decision records. Anywhere the text becomes a reference for future work, the writer has to stand behind every line. If the writer cannot stand behind it, the line should be cut, not paraphrased.

Why AI-assisted rewrites lose more than they add

The standard pitch for AI-assisted writing tools is that they make text clearer, fix grammar, and tighten the prose. This is true for the surface. It is not true for the meaning.

A clearer sentence is not always a more accurate sentence. The original might have been hedged deliberately (“in most cases the cache will refresh”) because the writer knew edge cases existed. The AI rewrite might drop the hedge (“the cache will refresh”) because the hedge looks like weakness. The reader, who did not know about the edge cases, builds a stronger model on weaker information. The text reads better. The mental model is worse.

Tightening the prose can also drop the part that mattered. The original might have said “we could not reproduce this on the staging cluster, but the production logs show a clear pattern.” The AI rewrite might say “the production logs show a clear pattern.” The dropped clause was the actual finding. The kept clause was the supporting evidence. The reader walks away thinking the production pattern is the only finding, when the original was trying to flag that the reproduction failure was the more interesting part.

Even a grammar fix can shift voice. If a junior engineer writes a sentence in the passive voice because the active voice feels presumptuous (“mistakes were made” rather than “I made mistakes”), the AI rewrite that flips to active voice strips the original humility. The sentence reads more confidently. The writer’s voice is gone.

None of these are the AI’s fault. They are properties of the rewriting process. The AI does not have the writer’s mental model. The AI cannot recover what was not in the surface text. The rewrite is lossy by definition.

What good AI-assisted writing actually looks like

The useful version of AI-assisted writing is not “let the AI rewrite my text.” It is “let the AI suggest alternatives I will then choose from.” The choice has to stay with the writer. The writer has to be able to explain every line. The AI’s role is to offer candidates, not to ship final text.

A few patterns that work:

  • Drafting from an outline. The writer produces the outline. The AI fills in the sentences. The writer rewrites the sentences. The AI’s draft is scaffolding, not the final version.
  • Alternative phrasings. The writer writes a sentence. The AI proposes three alternatives. The writer picks one, modifies it, or rejects all three. The original sentence survives in the writer’s head as the reference.
  • Mechanical cleanup. Spelling, grammar, punctuation. These are the surface properties of text. AI is good at them and the loss is small.
  • Reorganizing without rewriting. The writer has a draft. The AI suggests a different section ordering. The sentences themselves are unchanged. The reorganization is a structural choice the writer can defend.

The bad version is the one most tools are sold on. “Let the AI write it for you.” This is lossy in the original post’s sense. The text is no longer the writer’s. The mental model behind the text is no longer present. The reader builds a model on text that was written by no one.

What this changes about tooling

If you take the no-lossless-transformations claim seriously, the natural conclusion is that any tool that sells “rewrite your text with AI” is selling a loss-leader. The tool improves the surface. It degrades the substance. The user only notices the degradation later, when a reader misreads a sentence or makes a decision based on a line the writer cannot defend.

Tools that hold to the constraint will look different. They will offer draft assistance, not draft replacement. They will offer phrasings, not rewrites. They will offer reorganization, not regeneration. The shift is small in the UI but large in the underlying promise.

The constraint also clarifies why AI-generated summaries of meetings, AI-generated incident reports, and AI-generated status updates tend to age poorly. Each one is a transformation that drops the parts the original writer thought mattered. Two passes of AI summarization can reduce a meeting to a list of action items and lose the reasoning behind them. Three passes lose the action items.

Trade-offs

The no-lossless-transformations claim is true, but it is also true that most engineering documentation does not need to be lossless. A line in an onboarding doc that paraphrases an internal concept does not need to preserve every nuance of the original. The cost of the loss is small. The cost of forcing every line to be defensible by a single writer is high.

Whether the discipline applies is per-document. A high-stakes document (architecture decision record, public API contract, incident postmortem for a customer-visible outage) earns the no-loss discipline. A low-stakes document (an internal wiki note, a draft blog post, a meeting summary) can tolerate more loss in exchange for faster drafting.

Treating all text under the same AI-default settings, regardless of stakes, is the obvious mistake. Refusing to use AI in any setting because the loss is real is the other mistake. Both are common.

Loss is real. Loss is also small in most places. Know which kind of text you are writing. That is the entire discipline.

What this looks like when you sit down to write

The practical discipline is short. Write the first draft yourself. Use AI for mechanical cleanup and alternative phrasings, not for the structural pass. Before you commit any line, ask yourself whether you can defend it. If you cannot, cut it or rewrite it by hand. If you can, ship it.

None of this requires more time than the default “let the AI do it” workflow. It requires more attention. The attention is the part the AI cannot replace. The attention is the part that makes the text the writer’s. The attention is what survives the transformation.

Leave a comment