Why AI-Generated Text Is Getting Harder to Read and What It Means for Enterprise Deployments

Enterprise teams deploying frontier LLMs in customer-facing products are optimising hard for the wrong signal. Benchmark scores improve, task accuracy climbs, and then adoption stalls because the people who are supposed to use the output find it genuinely difficult to read. This is not a UX problem that can be solved with better interface design. It is a structural consequence of how modern LLMs are trained, and it has direct implications for every deployment decision from model selection through to output post-processing.

The Psycholinguistic Problem Hiding in Your Outputs

Recent research from NYU gives this phenomenon a precise technical shape. Clark et al. (arXiv 2026) examined nine frontier and near-frontier models against human writing and found systematic differences across multiple psycholinguistic features known to increase processing difficulty. All nine models produced more inanimate subjects paired with animate verbs, more low-frequency n-gram sequences, and longer syntactic dependencies than comparable human text. Most also stacked noun phrases more aggressively and used reduced object relative clauses more frequently in conversational contexts.

These are not stylistic quirks. Each of these features corresponds to a measurable increase in cognitive load for human readers. When your customer support bot or internal knowledge assistant produces output dense with these constructions, comprehension drops before the user even registers why.

The practical consequence is that users disengage or escalate to human agents, not because the answer is wrong, but because the answer is hard to parse under normal working conditions.

Why Training for Reasoning Degrades Readability

Clark et al. (arXiv 2026) propose a mechanism that deserves serious attention from anyone involved in model selection or fine-tuning. Human language evolved under pressure to communicate successfully across varied cognitive states and attention levels. LLM training, particularly the reinforcement learning and fine-tuning stages that drive reasoning performance, applies pressure toward information density rather than communicative clarity.

The evidence for this is not just correlational. The authors fine-tuned a model under a length penalty and observed measurable divergence from human-like linguistic behaviour. Compressing output to be shorter pushed the model toward exactly the high-density, low-frequency constructions that make text harder to process.

This matters because length penalties and token efficiency targets are common in enterprise fine-tuning pipelines. Teams applying them to reduce API costs or latency may be inadvertently degrading the readability of every response their users receive.

Selection Bias Compounds the Problem in Structured Deployments

A separate line of research from Tencent introduces a second failure mode that is particularly relevant for deployments using structured decision models. Song et al. (arXiv 2026) tested whether Jev-style System One models, which predict probabilities directly over supplied candidates rather than generating free text, reduce selection bias compared to generative LLMs. The results are instructive.

Across two Jev versions, twelve reproductions, and six generative LLMs, stable accuracy across repeated presentations masked a different and more serious problem. When option order was shuffled while keeping question and candidate content fixed, the cumulative failure set expanded by 27 to 29 percent relative to the original order. Models that appeared highly reliable under fixed-order repetition lost between 23 and 64 percent of their initially correct answers when presentation order changed.

For enterprise deployments using LLMs to rank outputs, classify documents, or evaluate candidates, this means that apparent consistency is not the same as correctness under equivalent conditions. A model that gives the same wrong answer repeatedly looks stable in evaluation but fails users in production when input ordering varies.

What Engineering Leaders Should Actually Be Measuring

The gap between benchmark performance and deployment quality is not new, but the readability and selection bias dimensions are underrepresented in most enterprise evaluation frameworks. Teams running model selection processes typically assess accuracy, latency, and cost. Readability as a measurable output property rarely appears in evaluation rubrics, and order-sensitivity testing is almost never part of structured model procurement.

The remedies are tractable. Readability scoring using established psycholinguistic metrics can be added to automated evaluation pipelines alongside task accuracy. Post-processing layers that rewrite high-complexity outputs before delivery to end users are implementable today without retraining. For structured decision tasks, systematic option shuffling during evaluation exposes order sensitivity before it reaches production.

None of these interventions require waiting for model providers to address the underlying training dynamics. They require treating output quality for human readers as a first-class engineering concern rather than an assumption.

Model Variation Means Selection Decisions Are Consequential

One finding from Clark et al. (arXiv 2026) that should not be buried is the observation of substantial variation in these features across model families. Not all frontier models produce equally difficult output. This means that readability is a differentiating factor that can and should inform model selection decisions, alongside the accuracy and cost metrics that already dominate procurement conversations.

The implication for CTOs and heads of ML engineering is that the right model for a reasoning-intensive internal tool may be the wrong model for a customer-facing assistant where comprehension under low-attention conditions matters. Treating model selection as a single decision applied uniformly across deployment contexts is a structural error.

Segmenting model choice by use case, and evaluating readability explicitly within each context, is a more defensible procurement posture than optimising for a single benchmark score across the board.