Writing with LLMs: A practical guide to better AI-assisted composition
A comprehensive guide on effective writing techniques when using large language models, covering strategies to improve output quality and maintain authentic voice in AI-assisted writing.
September 18, 2026

The people getting good writing out of a large language model are not the ones with clever prompts. They are the ones who stopped asking it to write and started asking it to argue with them. That distinction, buried in a guide that quietly made the rounds on Hacker News this week, is the difference between a tool that produces filler and one that actually improves a piece of prose.
The post in question is not a prompt-engineering cheat sheet. It is closer to a set of habits, the kind you'd pick up from an editor rather than a manual. And the habit it keeps returning to is this: the model is bad at generating your voice from nothing, and quite good at telling you where your own draft goes soft. Treat it like the first kind of tool and you get sludge. Treat it like the second and you get something worth keeping.
The draft nobody asked for
Here is the failure mode, and anyone who has spent time in a marketing Slack channel has seen it: someone pastes a rough outline into ChatGPT or Claude, asks for "a blog post about X," and gets back 800 words that are grammatically flawless and say nothing. Every sentence is complete. Every paragraph has a topic sentence. And the whole thing reads like it was written by a committee that had never met the reader.
This is not a bug specific to one model. It shows up in Jasper output, in Copy.ai drafts, in Writesonic templates and in Rytr shortcuts, because it is not a tooling problem. It is what happens when you ask a system trained to predict the statistically likely next sentence to generate an entire piece with no anchor. Without a real draft, a real argument, or real examples to react against, the model falls back on the median version of whatever genre you asked for. Blog posts about productivity default to three tips and a call to action. Cover letters default to "I am excited to apply." The words are correct. The writing has no position.
The tell is usually structural before it's semantic: paragraphs of near-identical length, transitions that restate rather than build, and a total absence of anything a human editor would call a claim. You can compare this to what happens when you ask a room of strangers to each guess a number independently. No single guess is wrong, but the average of all of them tends toward the boring middle. An LLM producing a first draft from a bare prompt is doing something structurally similar: sampling from a huge distribution of "posts like this" and landing near the center of it.
Why the model keeps landing on the same sentence
This is worth explaining plainly because it changes what you ask the model to do. A large language model does not have an opinion about your topic sitting in memory somewhere, waiting to be retrieved. What it has is a probability distribution over next tokens, shaped by everything it was trained on. When you give it almost no constraint, that distribution collapses toward whatever pattern shows up most often for the type of text you requested. That's not a flaw in a particular product, it's math: more common patterns get more probability mass, and more probability mass wins more often at generation time.
The concept that explains this best is regression toward the mean. An unconstrained request pulls the output toward the statistical center of everything similar in the training data. A specific, opinionated request narrows that distribution before generation even starts. This is why "write about remote work" produces boilerplate, while "argue that hybrid schedules are a compromise nobody actually wanted, using the fact that most companies still can't agree on which three days" produces something with an actual edge. You are not making the model smarter. You are narrowing the range it's allowed to sample from.
This is also why the editing-first approach works better than the drafting-first approach. Feeding the model your own rough, opinionated, uneven draft and asking it to tighten specific paragraphs gives it a much narrower target than a blank prompt does. You've already done the part a model is structurally bad at, which is deciding what the piece is actually for.
What the guide gets right that most advice does not
The post's argument, stripped down, comes to something like this: write the ugly version yourself first, then hand it to the model in pieces and ask specific, narrow questions about each piece rather than one broad "make this better." Not a request for a rewrite of the whole thing, but a question about one paragraph, one transition, one claim that isn't earning its place.
That framing matters because it reverses the order most writers default to. The instinct when a tool can generate 800 words in ten seconds is to let it generate the 800 words. The guide's point is that the ten seconds should come after the thinking, not instead of it. Ask the model to restate your own draft back to you and see what it thinks the argument is. If its summary doesn't match what you meant, you've found the actual problem before a reader does.
A version of this workflow, in practice
Write the rough draft with no help. Paste it in and ask what the argument is, not what's wrong with it. Fix the paragraphs where the model's summary and your intent diverge. Only then ask for line-level tightening, one section at a time.
Tools built around dictation and low-friction capture, like Codictate or Mutter AI Dictation, actually fit this pattern well, since they're built for getting the ugly first draft out fast rather than polishing it. Editors like Tiptap AI Toolkit and Mercury Edit sit closer to the second half of the workflow, the paragraph-level pass rather than the generation. The tools aren't interchangeable, even when the marketing makes them sound like they are, and readers picking between something like Jasper and Writesonic or Copy.ai and Jasper are usually asking the wrong comparison question if what they actually need is an editing pass, not a generator.
None of this is really a workaround for weak writing skill. If anything it demands more of it, since you now need a clear enough sense of your own point to notice when the model's summary drifts from it. That connects to a broader question this site has been circling for a while about what taste means when generation is cheap, and it's related to the gap between what these tools promise and what they deliver, which we've written about elsewhere.
Whether this scales past one careful writer
The workflow the guide describes works for someone who already knows what good prose looks like and is disciplined enough to write the bad draft before reaching for the model. It's less clear it works for a newsroom, a marketing team of twelve, or anyone whose incentive is volume over voice. Editing-first advice assumes the editor has time and judgment to spend. Most production pipelines are built to remove exactly those two things. The open question is whether "write with it, don't let it write for you" survives contact with a deadline, or whether it quietly turns back into the blank-prompt workflow the moment nobody's watching.
Tools mentioned in this article
Some links in this article are affiliate links. Learn more.