Anti-repetition is the discipline I had to invent the moment I let a model help write more than a few posts. An AI writer’s worst habit isn’t inaccuracy or bad grammar — it’s sounding exactly like itself, post after post. The same opening move, the same tidy three-part rhythm, the same little anecdote wheeled out again. Individually each post reads fine. Stacked up across a site, the sameness becomes a signal, and not a good one. So I keep a log that records what’s already been used and forces the next post to be different. Here’s what it tracks and how it runs.
The habit that makes AI writing recognizable
Read enough machine-drafted articles from one site and you start to feel the template underneath. It’s rarely any single sentence. It’s the recurring shape: an opening that reaches for the same kind of hook, a middle that always resolves into three neat points, a close that lands on the same reflective note. The model isn’t copying itself word for word. It’s returning to its favorite moves, because those moves are what a probability engine gravitates toward.
The trouble is that a human editor doesn’t catch this from inside a single post. Each draft looks varied enough on its own. You only notice the repetition when you line up ten posts and see the same skeleton in all of them. By then it’s baked into the archive, and fixing it means rewriting history rather than preventing a habit.
That’s the specific failure this is aimed at: not one bad post, but a whole site that reads like it was written by the same tireless voice on a loop. The reader may not name it, but they feel it, and a search engine that samples across your pages has an even clearer view of it.
This is about originality, not dodging detection
It’s worth being blunt about the goal, because it’s easy to mistake. The point of anti-repetition is not to make AI writing harder to detect. It’s to make the writing genuinely more original, which is a different target that happens to look similar from a distance. I’m not trying to sneak content past a classifier; I’m trying to make sure two posts on my site don’t share a spine.
This matters because Google has said plainly that it doesn’t police whether content is AI-assisted. What it acts against is content produced at scale to manipulate rankings — the scaled-abuse pattern, of which mechanical repetition is a tell. A site where every post opens the same way and reuses the same three anecdotes reads as produced-to-fill, regardless of who or what wrote it. Variety isn’t a trick to hide the machine; it’s evidence that a person shaped each piece.
Framed that way, the log isn’t a cloaking device. It’s a quality tool. It pushes each post to earn its own opening, its own comparison, its own ending, which is exactly what people-first content is supposed to do anyway.

The anti-repetition log I keep for every post
The tool itself is unglamorous: a single running file, one entry per published post. Each entry records the reusable moves that post spent — its intro hook, its central anecdote, the axis of its comparison, the pattern of its title, and any turn of phrase distinctive enough to notice twice. It’s a ledger of what’s been used, not a style guide of what to do.
Because it’s part of the content pipeline I run, the log has a fixed place in the process rather than being something I consult when I remember to. Before a new post is drafted, the log is read, so the writing steers away from anything already spent. After the post is done, its moves are appended, so the next post has to avoid them in turn. The file grows by one entry each time and the constraint tightens gently as the site does.
What makes it work is that it’s specific. A vague instruction to “be original” is useless to a model and to me. “The last post already opened with a red-graph scene and already used the pretty-versus-minified comparison, so this one can’t” is a constraint concrete enough to actually change the draft.
What the log actually tracks
Not everything is worth tracking, and logging the wrong things would make the file noise. I track the handful of elements that carry a post’s fingerprint — the parts a reader would recognize as “oh, this again” if they saw them repeat. Five of them earn an entry every time.
The intro hook type, because openings are where sameness is most visible. The central anecdote, so a good story gets told once and not diluted across five posts. The comparison axis, since reusing the same framing makes different topics blur together. The title-hook pattern, to keep the archive’s headlines from rhyming. And any sealed phrase — a line I liked enough that I’d be tempted to reuse it, which is precisely why it gets retired after one outing.
| Element logged | Why it’s tracked | Rule for the next post |
|---|---|---|
| Intro hook type | Openings show sameness first | Rotate to a different hook style |
| Central anecdote | A story loses force if reused | Tell it once; find a new angle |
| Comparison axis | Same framing blurs topics together | Compare on a fresh axis |
| Title-hook pattern | Headlines start to rhyme | Vary the pattern within a cluster |
| Sealed phrase | Favorite lines beg to be reused | Retire it after one appearance |
The list is deliberately short. Five elements are enough to keep posts feeling distinct without turning every draft into a compliance exercise. If a category stops earning its place, it comes out; the log is a working tool, not a monument.
How it runs: check before, record after
The whole discipline is two steps bolted to the start and end of writing. Before drafting, I read the log and pull out what’s off-limits for this post — the hooks, anecdotes, and phrasings already spent. That reading directly shapes the draft: the model is told, in effect, “these moves are taken, use others.” The constraint arrives before a single sentence is written, which is the only time it can actually prevent repetition rather than diagnose it.
After the post is finished, I append its entry: the hook it used, the anecdote it spent, the axis it compared on, the title pattern, and any phrase worth retiring. This is the step that’s easy to skip and fatal to skip, because a move that isn’t recorded is a move that will quietly come back. The recording is what makes the next check meaningful. Miss it once and the log starts lying about what’s been used.
Tying both steps to the pipeline rather than to my memory is the point. Check-before and record-after aren’t things I try to remember; they’re positions in the process, the same way a lint gate is. Originality, it turns out, is less about inspiration than about bookkeeping.

What’s safe to repeat and what isn’t
A fair worry about all this is that it sounds exhausting — must every single thing be different every time? No, and drawing that line correctly is what keeps the log usable. Structure is meant to repeat. Readers benefit from a consistent shape: a table of contents in the same place, an FAQ near the end, a comparison table where it helps, a closing reflection. Predictable scaffolding is a courtesy, not a crime, and copying it across posts is fine.
What must not repeat is the prose and the voice on top of that scaffold. Same skeleton, different flesh. The intro can sit in the same slot every time, but it can’t reach for the same hook. The FAQ can always be there, but the anecdote inside it can’t be the one from last week. Once you separate “structure” from “voice,” the anxiety drops: you’re not reinventing the article, you’re just refusing to reuse the parts a reader would recognize.
That distinction is the whole reason the log is short. It only guards the elements that carry a fingerprint. Everything structural is allowed to be as repetitive as it wants, because sameness in scaffolding reads as reliability, while sameness in voice reads as a machine on a loop.
FAQ
What is anti-repetition in AI writing?
It’s the practice of tracking the distinctive moves each post uses — its hook, anecdote, comparison, and phrasing — so later posts don’t reuse them. The goal is a site where posts feel genuinely different from each other, rather than variations on one template the model keeps returning to.
Is an anti-repetition log about hiding that content is AI-written?
No. It’s about originality, not evasion. Google doesn’t penalize AI assistance; it penalizes content produced at scale to game search, and mechanical repetition is a symptom of that. Varying each post makes it genuinely better, which is the opposite of trying to cloak it.
What should the log actually track?
The elements that carry a post’s fingerprint: the intro hook type, the central anecdote, the comparison axis, the title-hook pattern, and any distinctive phrase worth retiring. Keep the list short — five elements is enough to keep posts distinct without turning writing into a compliance checklist.
How do I actually use a log like this?
Two steps: before drafting, read the log and steer away from anything already used; after finishing, append the moves this post spent. The before-step prevents repetition; the after-step keeps the record honest. Skip the recording and the next check is checking against an out-of-date ledger.
Isn’t it fine for my posts to share the same structure?
Yes. Structure is supposed to repeat — a consistent table of contents, FAQ, and closing help readers. What shouldn’t repeat is the prose and voice on top of that structure. Same skeleton, different flesh: predictable scaffolding reads as reliable, repeated phrasing reads as a machine on a loop.
My Thoughts
I used to think originality was a matter of talent or mood, something you either had on a given day or didn’t. Keeping this log convinced me it’s mostly a matter of records. The model will happily reuse its best trick forever, and left to memory, so will I. What actually keeps the writing fresh is a boring file that remembers what I’ve already spent, consulted before I start and updated after I finish. Talent writes the sentence; the ledger makes sure I haven’t written it before.
