Bryan Cantrill published The revolt of the reader and within hours the piece had racked up 489 points and 227 comments on Hacker News. The title alone lays out the thesis: the one revolting isn't the writer, it's the reader.
What follows isn't a summary of the article — that's what the link above is for — but my read on why that title hit a nerve with an audience of engineers who two years ago were celebrating being able to generate documentation in fifteen seconds.
Why it matters
The signal hiding in that title is an economic asymmetry. The marginal cost of producing text collapsed. The cost of reading it hasn't moved a millimeter: it's still a human, with finite attention, processing sentences at the same old speed.
For decades, a long document worked as indirect proof of effort. If someone sent you four pages, you knew they'd spent an afternoon on it, and you paid attention in proportion. That contract is broken. Today four pages prove nothing, and the reader senses it before finishing the first paragraph.
That's the real problem: when you generate text without reviewing it, you didn't eliminate work, you transferred it. Every reader pays the part you skipped, and they all pay it, one by one. Text stopped being evidence that someone thought, and what broke isn't the style: it's the implicit signature that said "I read this, I thought about it, I stand behind it."
What changes in practice
For anyone working with a team every day, this isn't philosophy. It's the reason your PRs started taking longer to get reviewed.
| Artifact | Written by you | Generated and unreviewed |
|---|---|---|
| PR description | The reviewer knows where to look first | The reviewer re-reads the whole diff to figure out what changed |
| Architecture document | The discarded options and the reasoning are explicit | You get a list of best practices with no decision inside |
| Issue or bug report | The reproduction steps are real | Someone loses an afternoon reproducing a case that never existed |
| Changelog | The user spots in one line whether it affects them | The user opens the diff anyway, because they don't trust it |
The rule I use is simple: if more people will read the artifact than wrote it, the cost of doing it badly multiplies per reader. A draft for myself can ship generated and raw. A PR description three people will read, no.
Concretely, I changed three things in my workflow:
- The model summarizes what changed in the diff. The why I write myself, always, even if it's two ugly sentences.
- If a document doesn't let me defend every paragraph on a call, that paragraph gets deleted before I send it.
- In ADRs, the part I care most about is the discarded alternatives. It's exactly the part that comes out empty when you generate it without having had the discussion.
The metric I watch isn't how many words I produced, but how many back-and-forth questions what I sent generates. If the team has to ask follow-ups, the document didn't save time: it just moved it somewhere else.
When NOT to use it
Here's the honest part, because this stance has a big soft spot and it's worth saying so.
First: there's a huge band where generating text is perfectly fine and going purist is pure theater. Translations, API references derived from types, mechanical commit messages, documentation skeletons, notes to self. If nobody is going to make a decision reading that, the artisanal ritual buys you nothing.
Second, and more uncomfortable: the reader can't audit the process, only the result. Rejecting a text because it "smells like AI" is a heuristic with expensive false positives. It lands on people writing in their second language, on formal people, on people who structure with bullets because that's how it comes out. If your team starts using that sense of smell as a quality filter, you're not rewarding thinking: you're rewarding a dialect. That's how this revolt turns into process snobbery.
Third: don't confuse rejecting ownerless text with rejecting the tool. A document thought through by a human and polished by a model violates no contract. The one violating it is the person who didn't read it before sending it.
Fourth, about this very post: I only have the headline and the signal from the Hacker News discussion, not the full text of the article. So I'm not attributing any specific position to Cantrill. If your conclusion depends on the exact argument, go read it at the source.
What I'd do today
If tomorrow I had to turn this into a team practice, it'd be a single rule: every artifact another human has to read goes through an editing pass where I delete more than I add. Not as a stylistic pose, but because that pass is the only remaining proof that someone took ownership.
And in PR templates I'd leave three questions, none of them generatable: what breaks if this goes wrong, what alternative did I discard, what would you look at first. The day the answers to those three start sounding all alike, you know the document no longer has an author.