Why AI Can't Losslessly Rewrite Your Docs — And What That Means for Vibecoding

Simon Willison flagged a short piece by Sophie Alpert, an engineer at Clay, that's worth reading twice: her internal policy on when engineers can and can't lean on AI for writing. The title is the thesis: there are no lossless transformations of natural-language text. Any time something rewrites your sentence — a human editor, an LLM, doesn't matter — information about what you actually meant can get dropped, because the rewriter doesn't have your full context.

That's not a new idea for translation or compression. Alpert's contribution is applying it directly to the workflow a lot of engineers have quietly adopted: paste a rough note into an LLM, get back something fluent, ship it as your own words.

The rule that matters

Alpert's central line, quoted by Willison: "You must stand behind every idea and every sentence in your docs." If a reviewer asks what a line means, "the AI wrote it" isn't an acceptable answer. You're the author of record, so you own the content — including the parts a model generated.

She backs this with two supporting points that are easy to skip past. First, writing is thinking — the act of composing a sentence forces you to actually resolve an idea, and outsourcing that step means you skip the resolution, not just the typing. Second, respect for the reader: if a document takes a reader ten minutes to read, the author owes it more than ten minutes of real attention. LLMs tend toward verbose, hedge-everything prose — more words, not more clarity — which quietly shifts cost from writer to reader. Her conclusion is narrow on purpose: brainstorming, drafting, and proofreading with AI are fine; shipping unreviewed AI output as your own thinking is not.

Same argument, applied to code

None of this is really about prose. Swap "docs" for "pull request" and the policy reads like a review checklist for AI-assisted development. A generated diff has the same lossy-transformation problem as a generated paragraph: the model doesn't have your full mental model of the system, so it fills gaps with plausible-looking code that may not match your actual intent — a race condition handled the wrong way, an edge case silently dropped, an error path that looks reasonable but isn't what you'd have written.

"Vibecoding" gets used loosely, but the useful version of it isn't hitting accept on every suggestion — it's the same posture Alpert describes for writing: use the model to draft, explore, and unstick yourself, then read the output closely enough that you could defend any line of it in review. If you can't explain why a function is structured the way it is, you don't own that code yet, regardless of who typed it.

Why this is worth internalizing now

As AI-assisted writing and coding both get faster and more fluent, the bottleneck stops being output speed and becomes review discipline — on both sides. A policy like Alpert's is a cheap, concrete way to keep that discipline from eroding: not a ban on AI tools, just a hard line on unreviewed AI output passing as your own judgment. It scales down to a single engineer's personal rule just as well as it scales up to a team's PR standard.