Over 2024 and 2025, the internet collectively decided that the em dash (this thing: —) was a fingerprint of AI writing. Post a paragraph with a few of them and someone will reply "ChatGPT wrote this." It's common enough that, on shipping GPT-5.1 in late 2025, Sam Altman called it a "small but happy win" that ChatGPT would finally honor a "no em dashes" instruction. (@sama)
We need to say up front that this reputation is a little unfair to the em dash. It's a wonderful, very human piece of punctuation. Plenty of excellent writers have leaned on it for centuries, and The Ringer went so far as to call it "the most human punctuation." The em dash didn't do anything wrong. But for a product like alfred_, perception is the entire game. alfred_ drafts email as you. If a message alfred_ drafts carries the one mark that's come to mean "a machine wrote this," we've failed at the only job that matters: sounding like you, not like an AI.
This is the story of why one user's drafts came out full of em dashes, why the cause was not what you'd guess (and not the model alone), and why we stopped trying to ask the model nicely and started enforcing it in code.
First, this is not a story about users writing badly
It's worth being precise about where em dashes actually come from, because the lazy version of this post blames the user, and that version is wrong.
Em dashes get into ordinary people's text through tooling, not deliberate choice:
- Word processors auto-convert them. Microsoft Word's AutoFormat turns a double hyphen into a dash as you type. macOS and iOS "smart punctuation" is on by default and "double hyphens to em dashes (—)" is literally one of its advertised conversions, system-wide. Apple Pages has the same feature. Most people have never opted into this; it's just on.
- Copy-paste carries them. Paste text from a webpage, a formatted doc, or an AI tool, and the smart/typographic characters come along for the ride, and they are not auto-normalized back to plain ASCII on paste, even if your own smart-punctuation is off.
So when we see em dashes in text associated with a user, the honest default assumption is "their keyboard or some upstream tool produced that," not "this person writes like a robot." Keep that framing, because it changes how you fix the problem.
Why LLMs reach for the em dash
The other source is the model itself, and there's real research on why. Two complementary explanations, both well-supported:
- Training data. Models trained heavily on older printed books, where em dashes are far more common than in modern prose. One engineer's analysis notes that GPT-3.5 did not overuse em dashes, but GPT-4o used roughly 10x more, a shift that lines up with changes in training corpora. (Sean Goedecke)
- Reinforcement from human feedback. RLHF rewards clear, confident, well-structured prose, and an em dash is an efficient way to slip in a clarifying aside without a run-on sentence. So the habit gets reinforced. One 2026 analysis clocks GPT-4.1 at 3.28 times the human rate, and finds the marks "resist prompt manipulations and user restrictions."
That resistance is easing, though. By late 2025 newer models could be steered off em dashes on request: with GPT-5.1, a custom instruction to avoid them finally stuck. The pull is still real, and still varies sharply by model, so "a model can't stop using em dashes" is no longer strictly true, and it's part of why we never leaned on the prompt.
That tendency is the one that bit us. Hold onto it.
(Worth a caveat for honesty: the em dash is a heuristic, not a detector. Removing them makes writing read as human; it doesn't fool a real statistical AI-detector, and it certainly doesn't "prove" anything about who wrote a given sentence. We strip them to sound like you, not to evade anything.)
Where the em dashes actually came from
A power user flagged that their alfred_ drafts were full of em dashes, so we looked at 30 days of them. On the web app, 85 of 139 draft email cards (61%) contained em dashes, and 53 had already been sent. Over SMS it was milder: 5 of 42. Clearly real, clearly their account, clearly something systematic.
The obvious theory was "the model just likes em dashes." But the actual root cause was more interesting, and a little embarrassing.
To write as you, alfred_ learns your voice from the emails you have already sent in your own connected account. A background voice-summary model (in this case a Gemini model) condenses that into a short style note, fed back into the drafting prompt so a draft sounds like you wrote it. And that style-summary model wrote em dashes into its own descriptions. It produced lines like:
"...appending your full signature—'<Name>...'—to every email."
Now look at the drafting prompt's rule at the time. It asked the model not to use em dashes, but with an escape hatch: "only use them if the learned voice clearly shows the user writes that way." The drafting model dutifully read the learned-voice note, saw em dashes sitting right there in it, and concluded the user must write with em dashes. So it granted itself permission.
None of this happened in isolation. As the research above shows, the model already leaned toward em dashes on its own. The escape hatch removed the one instruction telling it not to, and the poisoned note handed it a justification. A baseline tendency, a missing guardrail, and a bad signal all had to line up.
The user never typed an em dash. Our own AI wrote em dashes into its description of them, then a second model read that as evidence and reproduced the habit. (The loop only fully closes once those drafts get sent and re-learned, but the first and worst step is the voice model planting the tell in the note.) Either way, the system had begun feeding its own quirk back to itself. That's the part worth remembering far beyond email: any pipeline that learns from its own generations can carry its quirks forward.
The fix: stop asking, start enforcing
We did two things, and the second is the one that actually matters.
1. We made the prompt rule absolute. The escape hatch is gone. The drafting prompt now says, in effect: never use em dashes; this is a hard rule with no exceptions; and this holds even if the learned voice below appears to contain em dashes; do not treat that as permission. We did not expect the rule alone to hold (a prompt is a request, not a guarantee, and how well it's honored varies by model), but it removes the specific excuse.
2. We added a deterministic strip, the part we actually trust. Prompt text is advisory. Even with a perfect rule, a model slips, or a stale style profile sneaks one through. So every email body alfred_ drafts now passes through a tiny, deterministic normalizer before it's previewed, stored, or sent:
// Replace the em dash (and its HTML entity forms) with a comma + space.
// [^\S\r\n]* = surrounding spaces/tabs only, never newlines, so it
// can't collapse a bullet list onto one line.
const EM_DASH_RE = /[^\S\r\n]*(?:—|—|—|—)[^\S\r\n]*/gi;
function stripEmDashes(body) {
if (!body) return body ?? "";
return body.replace(EM_DASH_RE, ", ");
}This is the last-mile guarantee. The model can do whatever it wants; the text that ships is clean.
In practice it's invisible: Wait — really? becomes Wait, really?. Real hyphens and en dashes, like well-known or 9am–5pm, are left alone.
The craft is in what we don't touch
The hard part of a rule like this isn't removing em dashes. It's removing only em dashes. Punctuation that looks similar means completely different things, and a sloppy strip corrupts real content:
| Mark | Unicode | Job | Strip it? |
|---|---|---|---|
| Hyphen | - U+002D |
compounds, flags, phone numbers | No |
| En dash | – U+2013 |
ranges: 2024–2025, 9am–5pm |
No |
| Em dash | — U+2014 |
sentence-level asides — this | Yes |
(Reference: Chicago Manual of Style, Grammarly.)
So the strip targets the em dash and its family exclusively. It deliberately preserves the en dash (turning 2024–2025 into 2024, 2025 would be a real bug), ASCII hyphens, and the -- signature delimiter that email clients use to mark a signature block. We also got bitten by greedy whitespace: an early version matched across newlines, so an em dash next to a line break collapsed entire bullet lists into one comma-spliced line. The fix was to consume only horizontal whitespace, never newlines. (The snippet above is the essence; the production version also avoids a dangling comma when a dash sits at the edge of a line.) Strip the tell; keep the typography.
And we closed the loop at the source. The style-summary model now normalizes its own output before storing it, so it stops writing em dashes into voice profiles in the first place. We also backfilled the existing profiles that had already been poisoned. Defense in depth: fix the generator, fix the storage, and still strip at the last mile, because you should never trust a single layer for an invariant you actually care about.
The one habit we override
Underneath all of it, the no-em-dash rule stays deliberately narrow. It's the one habit we override, while alfred_ keeps learning the rest of your voice from what you actually write: every rewrite or improvement you make to a draft (on email, web, or SMS) is stored to memory and shapes how it writes as you.
That still cuts one way against you. If you genuinely write with em dashes, alfred_ will not reproduce that habit, and for you it's a real loss. The trouble is we can almost never tell that you mean it. A sent em dash is ambiguous evidence: most come from autocorrect turning a typed -- into one, from pasted text, or from another AI tool, not from a deliberate choice. With the signal that noisy, and a false "they mean it" shipping the tell to everyone, we default to stripping.
The one signal we'd trust runs the other way: you editing a draft to put the em dashes back, a deliberate correction, not an ambient artifact. Today we don't act on even that, the strip is unconditional, and that's the right call while the tell is this loud. If it ever fades, gating the strip on a clear, repeated correction is a one-line change. Better, for now, that a draft reads as unmistakably yours than as unmistakably a machine's.
The takeaway
Three things generalize past punctuation:
- You can't reliably prompt your way to a hard invariant. If a property must always hold in user-facing output, enforce it deterministically in code and treat the prompt as a hint, not a guarantee.
- Watch for AI learning from AI. Any pipeline where one model's output becomes another model's input can amplify the first model's quirks. We taught ourselves the exact tell we were trying to remove.
- Don't blame the user for the tooling. The em dashes weren't a character flaw. They came from autocorrect, from copy-paste, and, in our case, from our own system. Fixing it well started with getting that diagnosis right.
alfred_ is an AI executive assistant that triages your inbox, drafts replies in your voice, and manages your calendar. This post is one small piece of making it sound like you. Try it at get-alfred.ai, or read the full story of building it.