Rhythm and structural tells: why AI writing sounds robotic

Chapter 3 of 7. Prerequisite: Chapter 2. You can grep a draft for hedges and filler now. This chapter is about the layer a grep cannot reach: the shape and pace of the prose itself.

A reader who closes your page muttering that it reads like AI usually cannot quote you a single guilty word. The vocabulary was clean. What they felt was structure: six paragraphs of near-identical mass, the whole page moving at one steady trot. Rhythm is the tell that survives a vocabulary scrub. It is also the hardest one to fix, because no find-and-replace touches it.

Why AI writing sounds robotic

The robotic feel has a mechanical cause. A language model produces the next sentence from the context in front of it; it does not track a running plan or budget for the paragraph as it goes. It does not slow down for a hard idea or speed past an easy one. Every local decision is plausible. The global result is uniform.

Part of that uniformity is measured, not folklore. A 2026 preprint from UC Berkeley's D-Lab (van Nuenen, arXiv:2604.22142) ran 300 personal narratives through three frontier LLMs under three prompt conditions and tracked 13 linguistic markers, including word length, punctuation, contractions, and pronouns. Its central finding: "Across models and prompt conditions, LLM rewriting produces a consistent pattern of stylistic normalization." Two scope notes before leaning on it. It is a rewriting study, measuring what a model does when it revises existing prose, while this chapter also applies the lesson to drafting. And it measures normalisation at the marker level, not at the paragraph level. The prompt condition built to protect voice was only a partial shield. Voice-preserving prompts "reduce the magnitude of the changes but do not eliminate their direction." Prompting shrinks the drift by about a third; the residual effect (|d| = 0.76) still approaches the conventional threshold for large effects. The direction of the drift stays.

The structural tells this chapter works through sit one level up from those markers: paragraphs converging on the same mass, section openers reaching for the same glue. No study in this course's citation pool measures those directly.

That result still sets the terms for the rest of this chapter. If normalisation is the model's default direction under every prompt condition tested, you will not instruct your way to rhythm. You diagnose it in the output and you edit it there. Three structural tells carry most of the signal, and each one has a concrete check.

Tell one: uniform paragraph length

Human paragraphs breathe. A point that needs eighty words gets eighty; the point that lands hardest gets nine and a line of its own. Generated drafts, in this site's experience, converge instead: paragraph after paragraph of near-identical mass, each within a few words of its neighbours, page after page.

You do not need to trust your eye on this. Word-count every paragraph:

awk 'BEGIN{RS=""} {print NF}' draft.md

One number per paragraph. Run it on a generated draft, then on something you wrote yourself before autocomplete existed, and compare the spread. The columns below are an illustration of the shape, not the output of a specific run:

generated draft        edited human piece
58                     12
61                     84
57                     31
62                     9
59                     58
60                     22

The left column is the tell. Nobody writes six consecutive paragraphs inside a five-word band by intent.

The fix is not padding or trimming toward random targets. Merge the two paragraphs that make one point. Split the paragraph that makes two. When a single sentence carries the argument of the whole section, promote it to a paragraph of its own. A one-line paragraph reads loud. Use that deliberately, and rarely.

Tell two: repeated transitions

Read only the first sentence of every paragraph in a generated draft. A pattern like this appears:

One key factor is caching. Caching reduces load on the origin server...
Another important consideration is bundle size. Large bundles delay...
It's also worth noting that fonts can block rendering. Font files...
Finally, third-party scripts deserve careful attention. Each script...

Every opener is glue. None of them argues. "Another important consideration" tells the reader nothing about why bundle size follows caching; it only concedes that a list is being walked. Human structure orders ideas by consequence: the bundle got big because of the fonts, so fonts come first and the transition writes itself.

The test is deletion. Strip each opener and reread the seam. When the paragraph still follows from the one before it, the transition was decoration and stays cut. When it no longer follows, the connector was papering over an ordering problem, and the fix is to reorder the ideas rather than polish the glue.

Tell three: flat pacing

The sentence-level version of the same defect. A generated paragraph paces every sentence between fifteen and twenty words, with the subject up front:

The build step compiles the templates before the server starts, so errors
surface early. The cache layer stores rendered pages for repeat visitors,
so response times stay low. The deploy script uploads only changed files,
so releases finish quickly.

Each sentence is fine. The paragraph is a metronome.

The standard advice is to vary your sentence length, and as a prompt instruction it does not survive contact with the tool. Told to vary, the model produces mechanical alternation, long short long short, a new uniformity one level up. Pacing has to follow attention instead. Slow down where the reader must not skim. Land a short sentence after two long ones at the exact spot where the idea turns, because that full stop is a hand on the reader's shoulder. Placed at random it is just noise with better statistics.

The cadence survives re-punctuation

Chapter 2 ended on the warning that tells migrate. Rhythm is where they migrate to.

During a later course build on this site, one chapter came back from drafting with an em-dash density of 0.00 per 1,000 words. Perfect, by the metric the audit script counts. The audit pass then found 14 trailing which-clauses in the same chapter, a density of 6.6 per 1,000 words. The documented pattern was the ", which is X" appositive. The shape, reconstructed:

The check runs at build time, which is the cheapest place to fail.
The token lives in the keychain, which is outside the repo.
The cron fires every three hours, which is often enough.

Look at the shape, not the punctuation. Statement, then a pivot into a small addendum. That is the em-dash cadence with the dash removed. Ban the glyph and the model re-punctuates the same rhythm through a relative clause, so the counter reads clean while the tell sits in plain sight.

The diagnostic that survives this is structural: count the sentences in a section that end on an appended afterthought, whatever glyph carries it. More than one per paragraph is cadence, not choice. Rewrite the afterthought as the main clause of its own sentence, or cut it.

The blind test that settled it

The clearest rhythm failure in this site's history involved no em-dashes at all.

The setting was drafting voice for a UK personal-finance calculator site, versioned like software. v1.0.0 was the original voice and it was working for single-page jobs. v2.0.0 made it more analytical and more precise about rates and thresholds, on the assumption that UK personal-finance readers want authority over warmth. The Cash ISA draft it produced "came out as a rate sheet". Everything in it was accurate. The register had shifted from useful guide to technical specification, and no vocabulary list would ever have flagged it.

v2.1.0 over-corrected. New framing cues told the drafter to acknowledge the reader's decision context, and the result was named empathy:

Whether you're opening your first Cash ISA or reviewing an existing one, ...

By the time that opener ends, "the reader who wanted the rate has already scrolled past". The draft landed as a fintech chatbot.

The decider was a blind test: three drafts of the same Cash ISA page, built from the same data, version labels stripped before reading. The selection came back v1.0.0. The original. Test id SC-010, and the second failure in two attempts at improving that voice. Both iteration assumptions had "felt reasonable during development. Neither survived contact with the blind test."

The reason this story lives in a rhythm chapter: register is rhythm at the scale of a whole page, and register regressions are invisible mid-iteration. Each new version was compared against the last and looked like progress. Only a blind read of the alternatives side by side exposed the slide against the baseline. The full arc, including what shipped afterwards, is in the Cash ISA write-up.

How to fix AI writing that sounds robotic

The repair routine, in the order this site runs it on every draft.

1. Histogram the paragraphs

   Run the awk one-liner above. If your longest paragraph is not at least double your shortest, the draft is machine-shaped. Merge duplicated points and split overloaded ones. Promote the load-bearing sentence to a paragraph of its own.

2. Audit the section openers

   Read only the first sentence of every paragraph, top to bottom. Interchangeable glue gets deleted. Where deleting an opener breaks the flow, reorder the ideas until each paragraph follows from the last without a connector.

3. Read one section aloud

   Aloud, not in your head. A metronome paragraph announces itself to the ear inside ten seconds. Mark every sentence where your voice went flat and break one of them with a full stop.

4. Count the pivots

   Count sentences ending in an appended afterthought, whether a dash or a trailing clause carries it. Over one per paragraph, rewrite the afterthoughts as main clauses or cut them. This is the check that catches a tell after it migrates.

None of this is cosmetic polish for its own sake. Google's helpful-content guidance defines people-first content as "content that's created primarily for people, and not to manipulate search engine rankings", and Search Essentials carries the same instruction as its content baseline: create "people-first content". A machine-paced page loses the reader whether or not any ranking system ever notices, and the reader it loses first is the one who arrived wanting exactly what the page says.

One honest limit before moving on. Everything in this chapter is diagnosis you run on output that already exists. On this site, three articles once cleared every automated gate and still shipped with a structural tell, and the miss was in the pipeline rather than in any single paragraph. Chapter 4 is that story: why the model's output is not the draft, and why the draft starts later than you think.