How To Write With An LLM, by Thomas and Erin Ptacek, has a rule that sounds too strict at first.
“You may not use a single word an LLM suggests to you.”
Not a single word? Then what is the model for?
I read the post, and the Hacker News comments on it. There were about 170 on September 18, 2026. The comments answer that question better than the post does.
This page puts the useful parts of both in one place.
Here is the short version. Write the piece yourself. Then use a model as a copyeditor. Don’t keep any wording it suggests. Don’t let it praise you.
The comments add four things the post leaves out.
- The system prompt Thomas Ptacek uses for copyediting.
- How many of the model’s suggestions he takes.
- An objection to one of his steps. Nobody settled it.
- Uses he didn’t write about, such as fact-checking.
One more thing. The rules are for writing that people read to hear from you. Documentation is a different case. So are the files you write for agents. I cover that near the end.
What are Ptacek’s two rules for writing with an LLM?
The post starts with readers.
“Readers can detect LLM words in the parts per trillion.”
You can rough up a paragraph a model wrote. Many readers will still see it as output. They stop paying attention.
So you write the piece yourself. Then you give it to a good model to find flaws.
Two rules keep the model out of your writing.
(1) You may not use a single word an LLM suggests to you.
Models are very good at picking a pleasing phrase. That is the problem.
The post compares the result to an article made of magazine headlines. Each one is fine. Dozens in a row feel wrong.
You won’t notice every place this happens. So the rule has no exceptions. It applies even when you like the model’s words better than your own.
(2) Avoid encouragement.
Give a model any draft, and it tells you the draft is great.
But a first draft is usually bad. The paragraphs are weak. The order is muddled. There are hundreds of words it doesn’t need.
If the model praises all of it, you keep your first choices. Normally you would have rethought them. The post argues that those rethinks are part of your voice.
Ptacek tried a workaround for a couple of years. He told the model he was an editor screening someone else’s piece. It helped. But then the model judged the draft against the goals of an imaginary publication.
His advice now: forbid praise outright, and stay alert for it.
So what is left for the model? Flagging problems.
That work is tedious for a person. A model doesn’t get tired of it. It can find:
- Passive voice, verbs turned into nouns, and the same phrase or word used again and again.
- Filler such as “very,” “really,” “actually” and “unfortunately.”
- Two or three paragraphs that would be clearer somewhere else in the piece.
Where do you get a list of things to check? The post recommends a book, Style: Lessons in Clarity and Grace by Joseph Williams.
Read it and take notes. Turn the notes into a list of prompts. Run them over your draft, one pass at a time.
The working loop has three steps.
- Ask the model to spot problems.
- Rewrite each flagged sentence or paragraph yourself.
- Show the old and new versions to a model and ask which is better.
Use a fresh session for the last step. A model that watched you rewrite knows which answer you want.
The post ends with a caution. Don’t take all the advice.
GPT-5 told Ptacek the piece was 20% too long. He thought it was probably right. He left the piece as it was.
What system prompt does Ptacek use?
The post doesn’t include it.
He posted it in a reply on Hacker News. Someone had asked how his tool keeps the model from praising him.
The prompt applies to every editing pass. These are the main lines.
NO ENCOURAGEMENT. Encouragement is useless; the only useful things are suggested corrections.
DO NOT WRITE COPY FOR ME. Any words you provide will be disqualified […] Tell me ABOUT what should change.
The rest gives three more instructions. Assume he knows his audience well. Keep suggestions to the current pass. Note typos and move on. The full text is in the linked comment.
“Tell me about what should change” is what makes rule one workable.
Suppose the model answers with a replacement sentence. Now you have a good phrase, and you have banned yourself from using it.
When the model describes the problem, the wording stays with you.
Each pass is also a narrow question, like passive voice or filler words. That leaves the model little room to comment on the piece as a whole.
Here is a shorter version for a single chat.
Help me copyedit this draft. Don't praise it and don't write
replacement text; I won't use wording you suggest. Tell me what
should change and quote the sentence you mean. One pass at a time.
This pass: [filler words].The “quote the sentence” line comes from another commenter. Without it, they found, a model gives vague advice.
How much of the model’s advice does he take?
In the same comment, Ptacek gave rough numbers.
- He runs 8 to 12 passes on a piece.
- He responds to about 60% of the suggestions.
- He dismisses the other 40%. He wanted the sentence to sound that way.
- When he responds, about half the time he rewrites the whole paragraph. That makes the original suggestion irrelevant.
- The other half, he does roughly what was suggested. He removes “just” or “very,” or changes the subject of a sentence.
He removed seven instances of “just” from the post itself.
One reply called this erasing yourself.
Ptacek answered that he would have removed those words by hand before models existed. It would only have taken longer.
He also said you can skip copyediting altogether. “Rough edges are a signifier of authenticity.” The method is for people who already revise their drafts. It makes that work go faster.
How do you know when the model has run out of useful things to say? A commenter with a similar process described two signs.
First, it keeps offering the same “trim 10-15%.”
Second, give it a published short story by someone else. It gives much the same advice it gave you.
Can an LLM judge which version is better?
This step drew the strongest objection in the thread. Nobody settled it.
(1) The objection: models prefer prose shaped like their own.
Retr0id argued that if you keep whichever version the model picks, your writing drifts toward LLM style. That happens even though the model never wrote a word of it.
They suggested a test. Take a paragraph you like. Have a model rewrite it. Then ask a fresh session which is better. In their experience, it almost always picks its own.
(2) Ptacek’s reply: you write both versions.
In his method, the model never competes with its own text.
Another commenter added that LLM style isn’t the opposite of good writing. A model can still be a competent editor who doesn’t share your blind spots.
(3) Nobody posted results.
I haven’t run the test either.
And the test doesn’t quite match. It compares a model’s rewrite with a human paragraph. Ptacek’s step compares two paragraphs you wrote yourself.
Until someone measures that, I’d treat the model’s pick as one opinion.
For pieces that matter, Retr0id asks friends to read the draft. They mark anything unclear or hard to follow.
What else is an LLM good for if it can’t write your words?
The thread named four uses.
(1) Fact-checking.
This came up more than any other use.
One technical blogger asks a model to check each post for factual accuracy. Once it pointed to documentation that undermined the whole post. The version they wrote a week later was much better.
Simon Willison replied that current models with a search tool are “genuinely excellent” at this. They can open the articles you link to, and check that you aren’t misrepresenting them.
Someone objected that a model had been confidently wrong about their code. Willison’s answer: you don’t trust the check blindly. You check the things it points out.
On his own blog, Willison says he doesn’t let LLMs write his posts. He uses them for fact-checking, spelling and grammar, and as an occasional thesaurus.
(2) A thesaurus.
This is where Bruce Lewis’s response post disagrees with rule one.
With a thesaurus, you have to come up with a synonym first. With a model, you can describe the word you’re looking for.
(3) An outline, before you write.
One commenter talks a topic through with a model. They have it produce a bulleted outline of their points. Then they rearrange the outline and write the text themselves.
(4) A reader who argues back.
Another commenter has the model play a specific kind of reader. It raises the counterarguments that reader would make.
After a few rounds, the gaps are closed, or the argument turns out to be weak.
The last two are close to the interview step in How to Write with AI Without Losing Your Voice.
When do Ptacek’s rules apply?
I think it depends on what the reader comes for.
The comment at the top of the thread when I read it made a split. LLMs are fine for manuals and specifications. They are “poison” for anything a human mind reads for meaning.
Others pushed back. People read manuals too.
This reply settled it for me.
“I don’t ‘read’ manuals so much as I look stuff up in them.”
So there are three kinds of reader.
| Who reads it | Examples | What AI does | What you do |
|---|---|---|---|
| An agent that follows it | CLAUDE.md, AGENTS.md, skills, prompts | Writes the wording | Decide what goes in, and test that it helps |
| A person looking something up | Documentation, manuals, how-to guides | Drafts from your code and notes | Check every fact and example, and cut |
| A person reading for your view | Essays, opinion pieces, newsletters | Interviews you and outlines before you write; flags problems and checks facts after | Write every sentence |
(1) An agent that follows the file.
The wording matters least here. I let the agent write it. What goes in is still my decision.
A study from ETH Zurich tested context files such as AGENTS.md on real coding tasks.
The files didn’t generally improve success rates. That held whether an LLM had generated them or developers had committed them. They also raised inference cost by over 20%.
Agents did follow the instructions in the files. The repository overviews were the part that didn’t help.
So I keep these files to the specific instructions I’ve decided on. Then I check whether a change helps.
(2) A person looking something up.
A model can draft from your code and notes. You check that every example runs, and every instruction matches the product.
Some people still write this kind of text themselves, for their own benefit.
One commenter went back to writing all their commit messages and pull request descriptions by hand. An agent checks the facts and leaves the wording alone. They found they understood the agent-written code much better.
(3) A person reading for your view.
Ptacek’s rules fit here. The model can help before you write, and after you’ve written. The sentences are yours.
Many blog posts both inform and argue. For those, the method in our main article is a middle route. Give the agent your views first and let it draft. Then rewrite until it says what you mean.
This page is mostly the second kind. It reports what the post and the thread say. So I drafted it with Claude Code from those two sources, and checked each claim against the linked text. The view in this section is mine.
What if English isn’t your first language?
One commenter’s advice is for people who write in their mother tongue. Talk to the model in English.
Its suggestions arrive in a different language from your draft. None of its wording can end up in your text. Rule one takes care of itself.
The harder case is writing in English as a second language. The thread has a warning about it.
A Debian contributor argued that they needed an LLM to be understood in English. The commenter telling the story couldn’t get through their long email. It ended with a note that an LLM had helped write it.
The same trick could run the other way. I haven’t tested it enough to recommend it.
Discuss the ideas and the outline with the model in your first language. That is where you judge an argument best. Write the English sentences yourself. Then run flagging passes for grammar and unclear sentences. Fix each one in your own words.
How do you set this up with Claude Code or Codex?
Ptacek built his own tool, with Python, HTMX and SQLite. It has highlighting, sidebar comments matched to the highlights, and revision tracking. It runs his list of editing prompts through the Codex, Claude or Antigravity CLI.
He expects yours to be different. “Whatever anybody comes up with on their own is better, for themselves, than someone else’s.”
If you don’t want to build one, you need three things.
- The draft as a file the agent can read.
- A place for the standing rules.
- A fresh session for the comparison step.
Claude Code reads standing instructions from CLAUDE.md. Codex reads them from AGENTS.md.
Since version 2.1.277, Claude Code also reads AGENTS.md when the folder has no CLAUDE.md. So one AGENTS.md can serve both.
Put the no-praise and no-replacement-text rules there. Add a line telling the agent not to edit the draft file. Keep your list of passes in a file too. Ask for one pass at a time.
We make StashBase, a local writing app that runs Claude Code or Codex beside your documents. So read this part as coming from its developers.
The draft stays open next to the chat. You can read a flagged sentence and fix it in the same window.
Agent Instructions in the Chat toolbar holds the rules for that folder. You don’t need to add a CLAUDE.md or AGENTS.md to it. See the agent setup guide.
Use a separate chat for the comparison step, so the model hasn’t seen your edits.