The Revolt of the Reader: Review AI Writing Before Posting

A public draft can be helped by AI without being handed over to it. The useful line is simple: keep the thinking, evidence, and final decisions with the person whose name is on the work. The current backlash is not really about whether a sentence has perfect grammar. It is about whether the reader can still find a person behind it.

Why this became a live argument

On September 5, Bryan Cantrill published "The revolt of the reader," arguing that readers are walking away from public prose that feels LLM-authored.[1] The piece reached the Hacker News front page, where it had 455 points and 209 comments when checked on September 6.[3] That does not settle the argument, but it is a clear signal that technical readers are arguing about this now, not treating it as a distant style guide issue.

Cantrill's sharpest point is about the reader's workload. If someone asks you to spend ten minutes following an argument, you assume they did the work of forming it. When a draft feels auto-assembled, that assumption breaks. The reader starts asking a more basic question: did the author test any of these claims, or did they mostly approve a plausible-looking answer?

That reaction is easy to understand in work writing. A product brief, incident update, proposal, or technical post does more than pass information along. It also tells the reader what the author noticed, what they chose to leave out, and where they are willing to take responsibility. Smooth generic prose hides those signals.

The survey is a warning, not a universal law

Cantrill cites a June survey by Cynthia Dunlop. It collected 668 anonymous responses after being shared with people who read and write technical blogs, so it is not a representative census of every reader.[2] Still, the responses show why the topic has teeth in technical communities: 78% said they would leave immediately when they suspected AI-assisted or AI-authored prose, and 71% said they would avoid that author in the future.[2]

The number worth sitting with is not the detector angle. It is that survey respondents said they preferred an author's imperfect writing to a polished version that erased the author's voice.[2] Readers can forgive a clumsy sentence when the idea is specific. They have less patience for a neat article that keeps restating a point without adding evidence, judgment, or a useful example.

That does not mean every reader can reliably identify how a document was made. They cannot, and AI detectors should not be treated as proof of authorship. It does mean a reader can notice when a page has stopped feeling worth their attention. That is the commercial problem for anyone publishing under a real name or brand.

The better use of AI is late in the process

Oxide's public policy makes a distinction worth borrowing. It describes language models as helpful for reading, research, and late-stage editing, while warning that using them as writers can erase the human responsibility behind the finished work.[1] You do not need to adopt Oxide's exact policy to use the same working rule.

Write the raw argument first. Include the awkward sentence that shows what you are really trying to say. Add the primary sources before asking a model to make anything cleaner. Then use a tool to identify repetition, flag a paragraph that does not follow, or propose a shorter sentence. Review every change. Reject the ones that make the work sound like it came from somebody else.

That sequence matters because a model is strongest at producing fluent general language. It is weaker at knowing which detail from your meeting, customer call, lab note, code review, or source document deserves the page. If you start with a blank prompt, you often get a competent shape with no reason for it to exist. Start with your notes and the tool becomes an editor instead of a ghostwriter.

Voice dictation gives writers a useful first draft

Voice input can help here because it lowers the cost of getting the real first version out. Speak the explanation as you would give it to a colleague. Keep the pauses, the qualification, and the stubborn detail that makes the point yours. Then edit it on screen.

DictaFlow is built around that sequence: hold a key, speak, release, and get editable text where the cursor is. It can be useful for a rough product note, support reply, research observation, or a first pass at a proposal. Its job is to make the first draft easier to capture, not to manufacture a point of view or certify that a page is human.

This is also a safer way to use AI cleanup. Ask for transcription cleanup, punctuation, or repeated-word removal. Do not ask a model to turn a few bullet points into a confident article. The more the system invents connective tissue, examples, and conclusions, the more you lose the thing a reader came for.

A short review before you publish

Before a public post, send, or documentation update, run a plain review:

Can I point to the source, observation, or decision behind each strong claim?
Does each section add something new, or does it restate the previous section in fresher words?
Would I say this sentence out loud to the person most likely to challenge it?
Did an editing tool change the claim, the level of certainty, or the speaker's intent?
Could a busy reader tell what I recommend after the first few paragraphs?

If the answer to the first question is no, the fix is not a better prompt. It is more reporting, more thinking, or a narrower claim. If the draft is accurate but flat, add the missing decision, example, or caveat from your own work. Do not decorate it.

The reader is the test

The current argument about AI prose can get noisy fast. One camp treats every rough sentence as proof that the author did the work. The other treats every polished sentence as suspicious. Both are bad tests.

A better test is whether the writing lets a reader understand what you know, why you think it, and where the limits are. AI can help clean up the route. It should not replace the person walking it.