Your AI-drafted SOP is harder to read than the one a human wrote, and now there’s data to prove it. In an October 2026 arXiv paper, Thomas Hikaru Clark, Matias B. Martin and Kyle Mahowald tested nine frontier and near-frontier models against human writing. All nine used more low-frequency word combinations and more inanimate subjects paired with animate verbs. Most also produced longer syntactic dependencies, more stacked nouns, and more reduced object relative clauses. These are the exact features psycholinguists use to measure processing difficulty.

On a shop floor, that cost is real. Operators misread work instructions, auditors flag ambiguous records, and new hires take longer to get productive. Below, we break down why models drift this way, how to spot it in your own documentation, and what to change in your prompts and review process.

The SOP Nobody On The Floor Can Actually Parse

You know the document. A work instruction that passes technical review, survives the approval chain, and still gets read three times by the operator trying to follow step four. Nothing in it is wrong. It just takes effort to decode. Same story with CAPA summaries that bury the corrective action inside a sentence nobody can hold in their head, and audit responses that sound authoritative without being clear.

Teams brought in LLMs to cut drafting time, and it worked. The cost moved rather than disappeared. It now sits with every operator, auditor, and new hire who has to read the output.

The Clark, Martin and Mahowald paper (arXiv:2610.29162) is the first solid evidence that AI-generated text readability is a measurable property of these models, not a complaint about style.

What The Study Measured Across Nine Frontier Models

The researchers built a new corpus of AI-generated text spanning diverse domains, then scored it against features psycholinguists already know slow human readers down. This is not a survey of opinions about writing quality. It is measurement against established markers of processing cost.

The control matters as much as the result. They compared model output to paraphrases produced by round-trip translation, text pushed through one language and back. Round-trip paraphrase is machine-mangled by definition, and the models still used the difficult features more often. So the problem is not generic machine processing. It is something specific to how these models write.

The specific linguistic features that make text expensive to read

Three categories drove the findings. Low-frequency n-grams are word combinations your brain has not seen often, so it cannot predict what comes next. Long syntactic dependencies force you to hold a subject in working memory across a dozen words before the verb arrives. Object relative clauses, especially reduced ones, strip out the connecting words that tell you where a clause begins.

Add stacked nouns and inanimate subjects attached to animate verbs (“the deviation observed”, “the tolerance requires”) and you get sentences that parse correctly and still cost effort. Every one of the nine frontier and near-frontier models produced more inanimate-subject constructions and more low-frequency n-grams than human writers. Most also produced longer dependencies, more stacked nouns, and more reduced object relatives in conversational contexts.

Why model family matters: the study found substantial variation

Clark, Martin and Mahowald also report substantial variation across model families. The direction was consistent across all nine, but the magnitude was not. Some families drift further from human-like phrasing than others.

That has a practical consequence. If you have standardised on one model for work instructions, audit narratives, and training material, you have inherited that family’s specific habits across every document it touches. Model choice is a readability decision, not only a cost or latency decision, and almost nobody evaluates it that way.

Information Density Is The Root Cause, Not A Style Glitch

Clark, Martin and Mahowald do not stop at describing the problem. They propose a cause, and it explains why prompt tweaks keep failing. Human language, they argue, is optimized for successful communication. AI-generated text is increasingly optimized for other goals like math, code, and reasoning, where the pressure is toward information density rather than being understood on the first pass.

That distinction matters. In a math proof or a block of code, packing more meaning into fewer tokens is a virtue. Nothing is lost when a reader has to stop and re-parse, because the reader is usually the model itself, or a developer who can scroll back. On a production line, re-parsing costs a shift.

The authors back the hypothesis with a proof of concept rather than speculation. They fine-tuned a language model under a length penalty, rewarding it for saying more in less space. The model drifted away from human-like linguistic behavior. One training pressure, applied deliberately, reproduced the same divergence they measured across the frontier models.

Read that as an engineering result, not a curiosity. Compression and comprehension pull in opposite directions, and the model has no way to know which one you wanted. The paper frames this as “axes of misalignment between linguistic processing demands in humans and LLMs.”

Here is the practical consequence for anyone running operations. The training objectives that make a model genuinely good at reasoning through a quality deviation, tracing a cause chain, weighing competing failure modes, holding multiple variables in play, are the same objectives that make its written explanation harder for a line supervisor to act on. You are not choosing between a smart model and a clear one. You are getting a smart model whose default output format was tuned for a different audience.

Which means this is not a style glitch you fix by asking for simpler words. It is a structural mismatch, and it has to be handled at the output stage, deliberately, every time.

Where Dense AI Writing Actually Costs You Money

Processing difficulty is not an abstract linguistics metric. It converts directly into rework, delay, and error whenever a document is the thing that triggers an action. The question is not whether your AI output is dense. The study says it is. The question is which documents can absorb that density and which ones cannot.

High-risk: anything a human must read once and act on

A work instruction gets read at the machine, under time pressure, often by someone whose first language is not the one the document was written in. If a sentence requires a second pass, you have built a defect path into the procedure. Deviation reports and CAPA write-ups carry the same exposure: an auditor who has to re-read your corrective action will ask for clarification, and that clarification cycle is days, not minutes.

Training material is the slow bleed. Dense phrasing does not block comprehension, it just stretches it, and onboarding time quietly expands. Supplier-facing documents sit in the same bucket. Every ambiguous spec clause comes back as an email thread.

Low-risk: machine-to-machine and analyst-facing output

Where the reader is a parser, a pipeline, or a specialist with time to sit with the text, density costs you nothing. Clark, Martin and Mahowald point out that AI text is optimized for goals like math, code, and reasoning, where there is pressure toward information density. That is exactly the environment where packing meaning tight is an advantage.

Code generation, structured data extraction, internal analysis memos, draft risk assessments that an engineer will rework anyway: let the model be dense. Triage is straightforward. Ask two questions about any AI-assisted document. Does one person read it once and then do something physical or regulatory as a result? Does that person have no easy way to ask a follow-up question? Two yeses puts it in the high-risk pile, and that pile needs a readability control before it goes near a controlled document system.

Building A Readability Gate Into Your AI Workflows

The paper ends by pointing toward “possible remedies.” The operational version of that is a gate: a defined readability target per document type, enforced before publication, not reviewed after a complaint.

Set the target first. A training module and an engineering change note do not need the same reading difficulty, and pretending they do is why blanket style guides fail.

A three-step readability check you can run this quarter

1. Benchmark your own corpus: Take twenty real documents, run them through two or three model families, and score the output. The study found substantial variation across model families, so assuming they write alike is a mistake you can test your way out of in an afternoon.
2. Prompt against the named features: Instruct explicitly: no stacked noun phrases, one clause per instruction, subject before verb, common words over precise-sounding rare ones. Generic “write clearly” prompts do nothing, because the model already thinks it is clear.
3. Add a comprehension check: Hand the draft to someone who has not seen the source material and ask them to state the required action. If they hesitate, the document fails, regardless of how good it looks in review.

Run all three on one document family before scaling. Work instructions are the usual starting point because failure there is visible fastest.

What to measure: rework cycles, not word count

Drafting speed was never the constraint. Most teams already cut that and then watched the savings reappear as clarification emails, repeated floor questions, and revision rounds on documents that were technically correct.

Track time-to-action instead: how long between a document being published and the work it describes being done correctly the first time. Then track rework cycles per document and the volume of questions each one generates. Those numbers move when readability improves, and they are already sitting in your quality system.

Expect the gap to widen through 2026. Models are being tuned harder for reasoning benchmarks, and comprehension is not on those scoreboards. If you do not measure it, nobody will.

Source: arxiv.org