A writing-voice guide for your AI assistants

I stopped giving my AI assistants style guides. I started giving them examples of my own writing and a single rule: if it sounds like a consultant, rewrite it.

The shift is from instruction to artifact. A style guide is a list of things the model has been told. An artifact is a thing the model has read. The first one rarely transfers. The second one transfers reliably, because prediction is what the model is built to do, and what you put in front of it shapes what it predicts.

Two things keep the artifact honest: a small set of signals, and one regex I run before anything ships.

#The em-dash signal

Em dashes (—) are the most reliable formatting-level AI tell in written English. They feel natural to a system that has never typed one but has read a billion of them. Every editorial style guide ever published has been ingested with em dashes in place. Every literary novel. Every New Yorker piece. To a model, the em dash is what writing looks like.

Native human writers, especially engineers writing fast in chat windows and pull-request descriptions, reach for either a tight dash (word-) glued to the preceding word, or a double dash (--) with spaces on both sides. Watch your thumbs the next time you type something quickly. That’s the test. ¹

The signal is Bayesian. An em dash in a draft raises the probability the text is AI-generated. It doesn’t confirm it. Plenty of human writers — particularly people who learned typography from books rather than chat clients — use em dashes deliberately. The regex below works for my drafts because my own writing doesn’t use them, so any em dash that shows up is drift. The test calibrates to a baseline you have to know.

I have a one-line check that runs before any public publish:

grep -RIn "—" src/

If the result is non-empty, something AI-generated has drifted in. The check also catches my own drift on the rare occasions a Mac autocorrect substitutes an em dash for a double dash. The rule applies to me too, which is the point.

Em dashes feel natural to a system that has never typed one but has read a billion of them. Native writers, especially engineers, reach for word- or — instead. One regex catches the difference.

#Words I flag (not words I ban)

A short list of words that overuse has hollowed out:

leverage, robust, comprehensive, seamless, synergy, holistic, utilize, facilitate, learnings, bandwidth, circle back, stakeholders, deliverables, ecosystem, journey, value add, paradigm shift, innovative, transformative, disrupt, thought leadership, best-in-class, world-class, cutting-edge, next-generation, turnkey, empower, ideate, solution.

Zero of these appear in my writing, because flagging a word forces the sentence underneath it to get specific:

AI default	The rewrite
Leverage our existing infrastructure	Reuse the read replica we stood up last quarter
Align on next steps	Decide who owns the migration by Friday
A robust, scalable solution	Handles 10K events a minute on three nodes

The list isn’t a banned-word list. It’s a flag list. I don’t tell the assistant “don’t use these.” I share the list and ask it to highlight any that appear, because every highlight is a place it reached for corporate abstraction instead of specificity. Forbidding words pushes the model to find synonyms, which produces laundered slop. Flagging them asks for sharper sentences.

#The four tests

I run drafts through four quality tests before they ship.

1. Teammate Test. Would a smart teammate find it clear, or roll their eyes? Write for the eye-roll.
2. CTO Test. Would a serious CTO find it impressive, or embarrassing? Serious CTOs read source code and inspect network tabs. They know when something was written to sound impressive rather than to be clear.
3. Action Test. Could a reader act on this without asking a follow-up question? If not, the post isn’t specific enough.
4. Attribution Test. If I removed my name, could AI have written this?

The fourth is the gate. The first three catch quality problems any competent writer catches. The fourth catches the failure mode that makes a draft sound generated.

I run the Attribution Test by scrolling to a random paragraph and reading it as if a stranger wrote it. If the paragraph could be on any consultant’s Medium account, it fails. If it names a tool, a number, a proper noun, or a specific anecdote that nobody else would have written in exactly that shape, it passes. The test is fast. It catches most drift in five minutes.

#Artifact, not instruction

The move that matters: I stopped writing style guides for AI assistants and started curating their reading material.

Two paths. Telling the model the rules — instruction — leads to the model being told, which rarely transfers. Giving the model a folder of your writing — artifact — leads to the model reading examples, which transfers reliably.

I keep a folder of my own past writing — emails, PRs, docs, code-review comments, READMEs — organized by register. When I start a writing task with an assistant, I drop the closest two or three examples into the prompt context. The pattern transfers. I never describe the labels.

The same posture works for code review. Three of my own past reviews beat any prose description of what good code review looks like. The asset isn’t a guide. The asset is the folder.

For voice specifically, I keep one file at ~/.config/writing-voice.md and pull it into every Claude Code session with a one-line include:

# ~/.claude/CLAUDE.md
@~/.config/writing-voice.md

Cursor and the SDK clients reach the same file through their own global configs. It loads as artifact, not instructions, the same way a human writer absorbs a style by reading the writer, not by being told the writer’s rules. ²

The em-dash signal has a half-life. It works in 2024-2026. By 2028 the models will be better at mimicking specific human voices from a folder of examples, and the artifact approach will need sharper inputs to keep its edge. The current discipline holds for now. The general principle — show the model the corpus, don’t lecture the model on the rules — outlasts any individual regex.

Notes

1. Mark Liberman's Language Log has decades of empirical observation on English punctuation usage across registers. The em-dash-as-AI-tell observation is a specific application of a more general truth: machines learn punctuation from text; humans learn it from keyboards. ↩
2. Anthropic's Prompt engineering docs put "use examples" at the top of every "how to get better outputs" list. The DetectGPT (Stanford 2023) and GPTZero literature converges on the same pattern from the detection side: AI-generated text has consistent fingerprints, but single-signal detection is unreliable. Ensembles work. ↩