Three of the most-read essays on Hacker News this week were about the same thing: writing with a model makes you sound like everyone else who writes with a model, and everyone can tell. Here is the mechanism, the list of tells, and the one way to use the tool that does not cost you your voice.
The week the readers pushed back
Three essays, three very different writers, one complaint, all in the top of Hacker News inside four
days. Thomas Ptacek, who is not a sentimental man about tools, wrote that readers can detect LLM
words in the parts per trillion, and that however much you scuff up a model's paragraph it registers
to your audience not as writing but as output. Martin Fowler wrote that models talk to him in a
grating LLM-voice, an uncanny valley of talking to a real human. Erich Grunewald argued you should
almost never use one to write at all, and the best comment under him added a rule worth keeping:
only ever use AI to make yourself think harder, and more.
And Jan Schaumann, in the angriest of the four, described people's emails now reading like
LinkedIn-influencer posts with punchy single-sentence paragraphs, and half the people you interact
with having turned into meat proxies for a model. That phrase went round because everyone has
received that email.
We want to take this out of the essayist's study and put it where it costs money. If you are
applying for a job, writing a proposal, answering a customer, or posting anything under your own
name, the person on the other end has now read several thousand model-drafted documents this year
and has developed, without trying, a detector. When it fires, it does not think "AI". It thinks
"this person did not bother", and then it thinks it about everything else you sent.
Why it is detectable at all
The mechanism is worth understanding because it explains why "humanising" prompts do not work.
Ptacek's description is the most precise we have seen: frontier models are wedged in a mode where
everything they write is a magazine headline. Every sentence is pleasing. Every phrase is the
turn of phrase a good editor might have suggested. The problem is density. A human writer produces
one such sentence per paragraph, if that, surrounded by ordinary load-bearing sentences that just
carry information. A model produces nothing but the good ones, and the effect on a reader is the
effect of a meal that is all garnish.
There is a second layer, which Grunewald's piece names. Model prose is vague and wrong in
hard-to-notice ways. It converges on the median expression of an idea. A specific claim becomes a
general one; a number becomes "significant"; a mechanism becomes "a range of factors". The reader
cannot always say what is missing but can feel that nothing is being risked, and prose that risks
nothing reads as prose that knows nothing.
The third layer is the one that catches people who think they have edited carefully. Models write
in a small set of structural tics that humans almost never use spontaneously and that stick out the
moment you know to look. We keep a list. It is the list our own linter runs against everything on
this site before it publishes, and it is worth reproducing because most people have never seen it
written down.
The tells, grouped by how they get into a document. The linter that gates this site checks for every item in the first two groups.
The first two columns can be caught mechanically and we catch them. The third column cannot, and it
is the one that matters, because it is the column that describes what a document is missing rather
than what it contains. A model-written cover letter is not detected by its vocabulary. It is
detected by the absence of the one specific sentence that only this applicant, about this company,
could have written.
Where this costs the most
We spend a lot of our time on the receiving end of documents, and there are three places where the
detector fires and the cost is immediate.
Applications. A hiring manager reading forty cover letters for one role has, by letter fifteen,
stopped reading for content and started reading for whether a person is present. The model-drafted
letter is fluent, well-structured, mentions the company's mission, and could have been sent to any of
the other thirty-nine companies with the name changed. It usually was. The reader is not offended.
They just move on, and they do it in about four seconds, which is less than the eight seconds we
usually talk about because there is nothing to evaluate.
Proposals and outreach. The cold email that reads like a person, with one observation only that
sender could have made and one offer only that sender could make, is answered. The one that reads
like output is filtered, by a human or by the recipient's own model, which has been trained on the
same tells. There is a grim symmetry in a model-drafted email being triaged into the bin by a model.
Posts and essays under your name. This is the one that quietly damages careers, because it
happens in public and it is permanent. A person who publishes model prose for a year has, at the
end of it, a body of work that establishes nothing about how they think. Everyone who read it
knows. Nobody says so.
What the reader on the other side actually does
It is worth describing the receiving end concretely, because most people writing applications have
never sat on it.
A hiring manager with forty applications and a Friday afternoon does not read them. They sort
them. The first pass is under ten seconds per letter and it is looking for one thing: is there a
sentence in here that could only have been written by this person, to us. A specific thing about
the company that is not on the About page. A specific thing the applicant did, with a number or a
name attached, that connects to the role in a way the applicant had to think about. One sentence is
enough to move the letter to the second pile.
The model-drafted letter almost never has that sentence, for a structural reason rather than a
lazy one. The model does not know the specific thing, because the specific thing lives in the
applicant's head, and the applicant did not put it in the prompt because the whole point of using
the model was not to have to think. What comes out is fluent, complete, warm, and generic, and it
lands in the first pile with the other thirty-one that read the same way.
The second pass, on the eight that survived, is where fluency starts to count against you. The
manager is now reading properly, and the tells in the first two columns of the figure above start
to register: the punch paragraphs, the tricolons, the perfectly even rhythm. They do not think
"this was written by a model". They think "I have read this letter before", which is true, and
they start to wonder whether the specific sentence that got the letter into this pile was also
borrowed. That doubt is expensive and the applicant never learns it was there.
The way through is the method below, applied to a document that is three paragraphs long and
therefore has nowhere to hide. Write it yourself, badly. Have the model tell you what is vague and
what repeats. Fix it yourself. Then read it once and ask whether the person on the other end could
tell it was written to them. If the answer is no, the model cannot help, and you should go and find
out one more thing about the company.
The one way to use the tool
None of the four essays says do not use models, and neither do we. Ptacek's method is the right one
and it has two rules that are easy to state and hard to follow.
First, write the thing yourself. All of it. The first draft is where the thinking happens, and the
draft you did not write contains thinking you did not do, which is exactly what the reader detects.
This is the point Grunewald makes with the philosopher's line about the difference between nodding
along while reading and productively generating a text. Generating is the work. Everything else is
formatting.
Second, use the model as a copyeditor, never as a ghostwriter, and never accept a single word it
suggests. Ptacek is strict about this and he is right to be. Ask it what is wrong: where the
passive voice piles up, which phrase you have used four times, where the argument skips a step,
which paragraph a hostile reader would attack first, which sentences you could cut. Then fix every
one of those yourself, in your own words. The moment you paste in its rewrite, the tell is in the
document, and you will not see it because it is, sentence by sentence, better than what you had.
The copyeditor loop. The model touches the draft only to point at it; every change is made by the writer in the writer's own words.
Ptacek's second rule, the one people skip, is to forbid the model from encouragement and then be
vigilant about praise anyway. A model told "this is good, tighten it" will tell you it is good.
Your first draft is not good. Its structure is wrong and it has seven hundred words you do not
need. The rewrites you do in response to that discovery are, in his phrase, load-bearing parts of
your voice, and a tool that talks you out of them has made your writing worse while feeling helpful.
The limit of the claim
There are documents where none of this matters. A status update, a changelog, a meeting summary, a
form. Nobody is reading those for a person and a model should write them. The claim is narrower and
sharper than "never use AI to write". It is that any document whose purpose is to establish that
you, specifically, think something, cannot be delegated without defeating its purpose, and that the
reader will know.
The tools are extraordinary at finding what is wrong with your writing. They are useless at being
you. Hire them for the first job and do the second one yourself, and the parts-per-trillion
detector on the other end of the wire will pass you, for the plain reason that there will be
someone there to detect.
Sources
- How To Write With An LLM (Thomas Ptacek, sockpuppet.org) (HN, 641 points and 380 comments, 17 Sep 2026)
- I think you should almost never use AI to write (Erich Grunewald) (HN, 262 points, 19 Sep 2026)
- I Don't Like LLMs (Martin Fowler) (HN, 237 points, 17 Sep 2026)
- Everybody's Lost Their Minds (Jan Schaumann) (HN, 365 points, 17 Sep 2026; the "meat proxies" line)
Originally published on the Levelbrook playbook. Levelbrook is a principal-led Rails and AI-systems consultancy; the playbook is where we write down what we see.
Top comments (0)