There is a wrong way to use an LLM for writing, and a right one. The wrong way is to let the model generate your prose. The right way is to write everything yourself, then hand the draft to a model and let it find the problems you cannot see. The difference matters because readers can tell the difference. LLM-generated text registers as output, not writing, even after heavy editing. But the same models, used as copyeditors, catch mechanical issues faster than any human can.
The Problem With Letting Models Choose Words
Frontier language models are exceptionally good at selecting phrases that sound good. That is, in a sense, their entire capability. The problem is that what sounds good in isolation often does not fit a writer's voice. The model gravitates toward magazine-headline prose, turns of phrase that are pleasing but generic. A paragraph full of these reads like a style guide written itself, not like a person thinking on the page.
The issue is subtle enough that writers cannot reliably spot it in their own work. You read a suggested phrase and think it sounds better than what you had. It probably does sound better, in the abstract. But "sounds better" and "sounds like you" are different things, and the second matters more for maintaining a distinctive voice. The model's suggestions are optimized for broad appeal, which is exactly the wrong signal for a writer trying to sound like a specific person rather than a trained average.
Why Encouragement Is the More Dangerous Trap
The second failure mode is harder to detect because it feels good. Hand a first draft to any language model and it responds with praise. The structure is solid. The argument is compelling. The prose is engaging. This is almost never true of a first draft. Most first drafts have incoherent topic flow, redundant paragraphs, and at least several hundred words that need to be cut.
The model does not lie about this deliberately. It is trained to be helpful, and praise feels helpful. But the effect is that writers double down on their first-draft instincts instead of rethinking them. Those rethinks, the decision to reorder paragraphs, cut a section entirely, or rewrite an argument from scratch, are where a writer's voice develops. Skipping them produces prose that is technically competent but reads as artificially flavored. The reader cannot pinpoint what is wrong, but something feels off.
This dynamic compounds across a writing session. The model encourages your overall structure, then your paragraphs, then your word choices, then your metaphors. At each stage you accept more of your initial impulses because an authoritative source validated them. The result is a draft that is polished but inert, shaped by the model's preferences rather than the writer's judgment.
What Models Actually Do Well
Language models are strong at mechanical copyediting. They do not get tired, they do not miss patterns, and they process text faster than any human editor. The specific problems they catch reliably include overuse of passive voice, nominalized verbs that bury action, repetitive phrasing, and filler words like "very," "unfortunately," "really," and "actually" scattered through a draft.
They also catch structural issues that are tedious to find by reading. There are almost always two or three paragraphs in a piece that improve clarity when moved to a different position. The model can identify these moves quickly. A human could do the same work, but the process is slow enough that most writers skip it.
The practical method that works is straightforward. Write the piece yourself. Then run editing passes with a model, asking it to flag specific categories of problems. For each problem it identifies, rewrite the affected section. Then present both versions to a model without context about which is original and which is the rewrite, and ask which is better. This avoids the incentive problem where the model knows you just rewrote something and defaults to praising your effort.
A Reference for Systematic Copyediting
Programmers who want a structured approach to prose editing have a useful resource in "Style: Lessons in Clarity and Grace" by Joseph Williams and Joseph Bizup. The book treats prose editing as a set of mechanical rules, not a subjective art. It identifies specific patterns that make writing unclear and provides concrete fixes for each one. For developers accustomed to thinking in terms of code quality and refactoring, the book turns copyediting into a systematic process rather than an intuitive one.
Reading the book and extracting a set of editing prompts creates a reusable workflow. Each prompt targets a specific category of problem: passive voice, weak verbs, excessive nominalization, redundant phrases, unclear pronoun references. Running these prompts in sequence over a draft produces incremental improvements without changing the writer's voice, because each edit addresses a mechanical issue rather than suggesting new language.
Building a Tooling Layer Around the Process
The author of this method eventually built a custom tool to manage the workflow. The tool, built with Python, HTMX, SQLite, and Tailwind, functions as a prose editor with revision tracking. It supports highlighting for editing passes and sidebar commentary tied to specific passages. The key feature is that each editing prompt runs against a model instance that does not have the context of the writer's revision history, preventing the model from defaulting to praise.
The specific implementation matters less than the principle. Any writer using LLMs for copyediting benefits from separating the model instances that flag problems from the model instances that compare original and revised versions. When the comparison model knows which text is the rewrite, it tends to favor the new version regardless of quality. Stripping that context produces more honest evaluations.
The broader point is that tooling around LLMs matters as much as the models themselves. A well-designed workflow that keeps the writer in control of language choices while offloading mechanical checking produces better results than either pure human editing or pure model generation.
The Rule That Holds Everything Together
The single most important constraint is that no word or phrase suggested by the model makes it into the final text. This is not about the quality of the suggestions. It is about the pattern of reliance. Once a writer starts accepting model-suggested phrasing, the line between human voice and model voice blurs, and the reader can tell. The strict rule eliminates the problem entirely. The model flags issues and suggests where to look. The writer decides what the fix sounds like.
This approach produces writing that is faster to produce, mechanically cleaner, and still recognizably human. The model handles the tedious work. The writer handles everything that matters.