AI Writing Isn't a Style Problem Anymore. A New Study Found the Grammar Behind It
Every sentence is correct. You still read it twice. Researchers just measured why, and the cause sits in how models are trained.
You know the feeling. An agent hands back a pull request description, a design doc, a summary of a long thread. Nothing in it is wrong. And yet you read the second paragraph three times, and by the end you could not say what it told you.
Most of us blame vague things for this: "AI voice," too many buzzwords, the em-dash. A paper posted to arXiv on October 21 says the problem is more specific than that, and more stubborn. It is grammar. Certain sentence shapes that slow human readers down show up more often in AI output than in human writing, across every frontier model the researchers tested.
The part that should interest anyone building with agents is the explanation. The authors think the training that makes models better at math and code is the same training that makes their prose harder to follow. If they are right, readability does not come for free as models improve. You have to ask for it, and you have to check. The good news: the study names six specific sentence shapes, which gives you a checklist instead of a vibe.
What the study measured
The paper is "Why is AI-generated language so hard to understand?" by Thomas Hikaru Clark, Matias B. Martin and Kyle Mahowald. Instead of asking people whether text "sounds like AI," they counted grammatical features that psycholinguists already link to slower, harder reading.
They looked at nine frontier and near-frontier models (the most capable models from the big labs, plus a couple just behind them): Claude Sonnet 5, Opus 5, Opus 5.5 and Fable 5, three GPT-5.6 tiers, Kimi K2.5 and GLM 5. They collected three kinds of text from each:
- Chat, from simulated multi-turn conversations, compared against movie and TV subtitles as a stand-in for natural talk.
- Coding sessions, from agents working in five real repositories, compared against StackExchange answers.
- Essays, written to the same prompts used in a large set of student essays.
They also built a second comparison: each model-written sentence translated into Japanese and back by a translation system. That round trip keeps the meaning but swaps in ordinary wording, which lets the authors ask whether the model's own phrasing is stranger than a plain rewording of the same content.
The six sentence shapes that slow readers down
Here are the features, in plain terms, with examples like the ones in the paper.
Inanimate things doing living-thing verbs. A function that "swallows" an error. A config that "wants" a value. A test suite that "complains." Each one makes you pause and translate the metaphor back into what the code does.
Rare word combinations. Phrases that are grammatical but almost never appear together in ordinary text. Your brain predicts the next word as you read, and rare pairings break that prediction.
Long gaps between connected words. The subject at the start of the sentence, the verb it belongs to twelve words later. You hold the first part in memory until the second arrives. Linguists call this dependency length.
Stacked nouns. "Agent session token budget overflow handler." Three or more nouns in a row, each modifying the next, and the reader has to work out the bracketing alone.
Nouns turned into verbs. "Calendar it." "Ticket that." Efficient for the writer, a small decoding step for the reader.
Dropped "that." "The house the contractors built" instead of "the house that the contractors built." The short version is grammatical. It also removes the signpost that tells you a new clause has started.
None of these is a mistake. That is exactly why they survive editing. A grammar checker will pass every one of them.
What they found
All nine models used more inanimate subjects with animate verbs, and more rare word combinations, than the human text they were compared against. Most also used longer dependencies, more stacked nouns and more dropped "that" clauses in conversation. Against the round-trip paraphrases, the frontier models leaned harder on rare word combinations, noun-verbs, inanimate subjects and dropped "that" clauses, and used fewer of the "that" clauses that make structure visible. The authors read that as a preference for cutting optional words.
The effect was strongest in chat and coding and weaker in essays. That detail matters for builders, because chat and coding are where most of us read model output every day. The essay setting, the one that gets the most public attention, is the mildest case.
Smaller open models behaved differently. Llama and the base and instruction-tuned versions of Olmo changed the least. The interesting one is Olmo's "think" variant, the version trained for step-by-step reasoning. It looked like the frontier models. Within the Olmo family, the effects grew from base to instruct to think.
That ordering is the clue the whole paper turns on.
The explanation: correct gets rewarded, clear does not
Human language, the authors argue, is shaped by two pressures at once. Speakers want to be brief, and listeners need to understand. Over generations, the shapes that survive are the ones that balance both.
A model in post-training, the stage after it learns language where it gets rewarded for good answers, feels only one of those pressures. In reinforcement learning on math, code and reasoning, the reward is "did you get the right answer?" Nobody scores whether a human could follow the explanation on the way there. Add limits on context and, sometimes, explicit penalties for long answers, and the authors suspect the model drifts toward density. They treat this as a possible mechanism, not a proven cause.
To test whether that mechanism is even plausible, the authors ran a small experiment. They fine-tuned a 1.5-billion-parameter model to turn structured event data into English sentences, where each item had a short and a long phrasing and both were correct. Then they added a penalty for length. Without a constraint keeping the model close to its starting behavior, every training run converged on the short form, more than 98% of the time for the "that" choices it was trained on. People do not do that. People pick the long or short version depending on what makes the sentence easier to read in context.
The shift also leaked a little. It carried over to similar "that" constructions the model was never trained on, and to one of four unrelated grammar choices.
The authors are careful about the limits. They could not inspect how the frontier models were actually post-trained, so the link is inferred from proxies. They tested English only, used a small number of conversation seeds, and ran the training experiment on a small model because of compute. It is also a v1 preprint that has not been through peer review. This is a strong hypothesis with a clean demonstration, not a proof.
The detail that cuts against doom
One result in the paper should change how you read the rest. Claude Opus 5.5 scored lower than Opus 5 on 19 of 21 difficulty measures, with 8 of those gaps large enough to rule out chance (outside the statistical error bars).
So the drift is not a law of nature. A lab can push against it. The authors say as much: reward signals could include effective communication, not just verifiable correctness.
For anyone choosing models, that turns readability into something you can compare, the same way you compare cost or accuracy. It also means the next model upgrade could make your agent's writing better or worse, and nothing in a benchmark table will tell you which.
Why builders should care more than anyone
Most writing about AI prose is about style and taste. This study points at something with a cost attached.
Every agent workflow ends with a person reading something. A pull request description. A summary of a failed deploy. A plan you are about to approve. If that text takes twice as long to understand, the time the agent saved you gets spent again at review. Worse, dense text is easier to skim past. A sentence you did not fully parse is a sentence you approved without checking.
The authors make a related point about what they call monitorability: output that humans can follow is output humans can actually supervise. That matters more as agents run longer and report back less often.
Put this into practice
None of the following comes from the paper. These are the moves I would make after reading it, built around the six features it measured.
1. Read one agent output out loud. Pick a PR description or summary your agent wrote this week. Read it aloud at normal speed. Every place you stumble is probably one of the six shapes above. This takes two minutes and tells you whether you have a problem.
2. Give the agent a short readability rule. Most coding agents let you keep standing instructions in a file the agent reads every session (Claude Code uses CLAUDE.md, Codex and several others use AGENTS.md). Add a few lines written against the specific features:
When writing prose for humans (PR descriptions, summaries, docs):
- Keep "that" and "which" where they mark a new clause.
- Never stack three or more nouns; rewrite as a phrase with "of" or "for".
- Code and systems do not "want", "swallow", or "complain". Say what happens.
- Put the verb close to its subject. Split sentences over 25 words.
- Prefer common words to rare phrasings.
Expect partial results. Instructions compete with everything the model learned in training, and the paper's training experiment suggests the pull toward short forms is strong. Check a few outputs after you add the rule rather than assuming it worked.
3. Spot-check with a cheap script. You do not need a parser to catch the worst cases. A rough check that flags sentences over 30 words and runs of three capitalized or technical nouns will catch a surprising amount. Treat it as a smoke alarm, not a grade.
4. Compare models on your own text. If you are choosing between two models for a writing-heavy agent, give both the same five tasks and read the results side by side. The Opus 5 versus Opus 5.5 result says real differences exist between versions of the same family.
5. Measure review time, not just token cost. If your team tracks what agents cost, add one number: how long a human spends reading what the agent produced. That is where density shows up on the bill.
Honest limitations
The paper measures features linked to reading difficulty. It does not time human readers on this specific text, so "harder to read" rests on decades of earlier psycholinguistics rather than a new reading study.
It covers English only. The conversation set is small, ten chat topics and five repositories.
And my practical steps above are untested suggestions. A readability rule in CLAUDE.md might help a lot or a little depending on the model. I would rather you measure it on your own output than take my word for it.
The choice in front of you
You can treat dense AI prose as a matter of taste and live with it. Or you can treat it like any other quality problem in a pipeline: name the failure, write a check, and compare tools on it.
The study makes the second option easier, because it turns a vague complaint into six things you can look for. Start with the out-loud read. If you trip, your reviewers are tripping too, and now you know where.
Sources: Clark, Martin and Mahowald, "Why is AI-generated language so hard to understand?" (arXiv 2610.29162, v1, October 21, 2026) · full paper HTML. Practical steps are the author's suggestions, not findings from the paper.