Why LLM-Generated Text Is Hard to Read: A Practical Guide to Controlling Information Density

Many developers have encountered the same problem: a model produces text with correct grammar and familiar technical terms, yet the result still feels difficult to read. The issue is often not vocabulary complexity. Instead, individual sentences carry too much semantic information. A single sentence may introduce several new concepts, contain multiple logical shifts, and rely on unstated assumptions. This quickly overloads the reader’s working memory and forces frequent interruptions in comprehension.

Some research teams have conducted fine-grained psycholinguistic comparisons showing that, even when vocabulary difficulty is controlled, certain model-generated texts remain harder to read than human writing. One explanation can be linked to a classic principle: the Uniform Information Density hypothesis. Rather than focusing on a specific product, this article treats “making models speak like humans” as a reusable technical problem: how to control the information-density curve of generated text so that technical content remains complete while becoming easier to read.

1. The Root Cause: Semantic Compression Overloads Cognitive Bandwidth

Human working memory is like a pipe with a fixed capacity. There is a limit to how much semantic information a reader can process in a given amount of time. Reading requires more than recognizing word meanings. Readers must also resolve references, reconstruct logical relationships, and maintain context. When a sentence presents several high-information propositions in succession, the resulting cognitive load creates a series of sharp peaks.

When explaining complex concepts, human writers instinctively add what might be called “buffering.” They use function words, explicit connectors, subordinate-clause markers, repeated references, and transition sentences to give readers time to process the material. In English, for example, a writer may retain a conjunction that is grammatically optional when the following subject is complex. Writers may also use phrases such as “in other words,” “it is important to note that,” or “from an implementation perspective.” These expressions carry relatively little information themselves, but they reduce the burden of syntactic parsing.

Model-generated text often has the opposite problem. It compresses several propositions into one sentence and removes much of this buffering, causing information density to fluctuate sharply. Just as readers finish processing one concept, they are presented with another. The result is a series of density spikes.

For this reason, readability optimization should not be limited to synonym replacement. It should focus on smoothing information density.

2. Why Models Tend to Produce Density Spikes

From a generation perspective, at least three factors contribute to this problem:

1. Training objectives favor efficient compression. Models learn to predict the next content from the surrounding context, which encourages compact phrasing. When a prompt asks for writing that is “concise, professional, and direct,” this compression tendency can become even stronger.

2. Local coherence takes priority over reader load. A model may ensure that adjacent sentences are semantically related, but it does not necessarily estimate how much new information a human reader can absorb at that point.

3. Models lack an explicit reading model. Human writers anticipate where readers may become confused. Models generally do not maintain a stable representation of the reader’s current knowledge or cognitive state, so they may treat background information as already known.

Therefore, “speaking like a human” is not simply a matter of adding conversational words. The generation process should be divided into four stages:

• Proposition planning
• Syntactic buffering
• Density evaluation
• Iterative rewriting

3. Four Engineering Strategies for Controlling Information Density

1. Prompting: Define the Audience and the Sentence Budget

A prompt should specify the reader’s task and impose a sentence budget rather than merely asking for text that is “easy to understand.”

Useful constraints may include:

• Write for developers with basic domain knowledge.
• Limit each sentence to one primary proposition.
• Explain a technical term when it first appears.
• Break complex causal relationships into two steps.
• Begin each paragraph with a topic sentence.

A sentence budget is more actionable than a general instruction such as “be professional but easy to understand.” As a result, it tends to produce more consistent output.

2. Planning: List Propositions Before Generating Sentences

Avoid asking the model to generate an entire paragraph in one step. First extract the propositions that need to be expressed, then order them according to a structure such as:

Background → Problem → Mechanism → Solution → Constraints

Each sentence should be tied to one primary proposition. A complex proposition can be divided into:

1. A conclusion sentence
2. An explanation sentence
3. An example sentence

This step reduces nested clauses and hidden assumptions at the source.

3. Decoding and Rewriting: Control Syntax and Buffering

In controllable-generation scenarios, candidate outputs can be reranked or rewritten. Possible constraints include:

• Limit the number of new entities introduced in one sentence.
• Limit the level of clause nesting.
• Prefer explicit logical connectors.

Mechanical insertion of filler words should be avoided. Buffering should be based on syntactic structure and actual discourse needs. For example, the following sentence is overly compressed:

Because A causes B, and B under condition C then causes D.

It can be rewritten as:

A causes B. If condition C is satisfied, B may also cause D.

The rewritten version makes the causal sequence explicit without adding meaningless content.

4. Evaluation: Use a Density Curve Instead of a Single Score

Readability evaluation should consider several dimensions at once:

• Vocabulary difficulty
• Syntactic complexity
• Average information density
• Variance in information density

The key metric is not simply average sentence length. The more important issue is whether individual sentences contain density spikes.

One practical acceptance test is reproduction accuracy. Ask another model or a human reader to restate the main point of each paragraph. If the reader omits important relationships, the text may be too dense or may lack sufficient logical connections.

4. An Illustrative Pipeline and Pseudocode

The following interface-independent pseudocode demonstrates a density-smoothing pipeline:

function make_readable(text, audience, max_new_terms_per_sentence):
    propositions = extract_propositions(text)
    ordered = order_by_logic(propositions)
    sentences = []
    for p in ordered:
        if count_new_terms(p) > max_new_terms_per_sentence:
            parts = split_proposition(p)
            sentences.append(emit_topic_sentence(parts))
            sentences.append(emit_explanation_sentence(parts))
        else:
            sentences.append(emit_sentence(p, explicit_connector=true))
    density_curve = estimate_density(sentences)
    if variance(density_curve) > threshold:
        sentences = insert_buffer_or_split(sentences)
    return join_with_paragraphs(sentences)

The key components are:

• extract_propositions: Breaks a compressed block of meaning into separate propositions.
• insert_buffer_or_split: Acts only on density spikes instead of adding filler throughout the entire text.

Buffering elements should serve a real discourse function, such as expressing contrast, introducing an example, adding a qualification, or summarizing a point. They should not be inserted as meaningless padding.

5. Implementation Guidance and Boundaries

First, treat readability as an independent stage in the generation pipeline rather than relying on a single prompt. Second, build a small manually annotated dataset containing confusing sentences, hidden assumptions, and logical jumps. Use it for regression testing.

Third, distinguish between use cases. Technical documentation can retain relatively high information density, but it should provide clear topic sentences and examples. Summaries for executives or other non-specialist audiences should reduce density further.

Finally, do not use “conversational style” as a substitute for structure. Excessive informality can reduce precision.

The essence of “speaking like a human” is to align the information-density curve with the reader’s cognitive bandwidth. A model does not need to become less intelligent. It needs to learn how to place buffers between complex concepts:

• State the conclusion before the conditions.
• Present the main clause before the explanation.
• Split sentences at density spikes.
• Make logical transitions explicit.

With these techniques, generated text can preserve technical accuracy while following a reading rhythm that is closer to human writing.