Anti-AI Writing Style Guide

A reference for writing that avoids the telltale patterns of LLM output. Based on Wikipedia’s “Signs of AI writing” (WikiProject AI Cleanup), which catalogues patterns observed across thousands of AI-generated submissions.

The point of this guide is not that any single pattern below “proves” writing is AI-generated (LLMs were trained on human writing, so humans produce these patterns too). The point is that a cluster of these patterns is the strongest tell, and avoiding them produces tighter, less generic prose.

Core principle

If a sentence would fit inside a promotional brochure, a travel guide, or a generic LinkedIn post, rewrite it. Neutral, specific, declarative prose is the baseline. Let facts do the work; do not dress them up. This guide defines how I strip out AI-like patterns and where I deliberately add my own voice on top of that.

Register: technical vs. opinion writing

This guide was originally tuned for technical and reference writing, where neutrality is the baseline. Opinion writing — op-ed, civic argument, personal essay — uses some of the same surface features (superlatives, “should” claims, evaluative adjectives, synthesis closers) on purpose. The patterns the guide tries to catch are the generic LLM versions of these moves, not deliberate op-ed register.

Tells that stay banned in every register:

• Phantom-authority weasel wording (“experts say,” “industry reports suggest,” “observers have noted”).
• “Moreover / Furthermore / Additionally” as sentence openers.
• “It’s not X, it’s Y” parallelism and its cousins.
• Em-dash storms, bolded-header bullet chains, emoji clusters.
• “Stands as a testament,” “rich tapestry,” “nestled in,” “in the heart of,” “a beacon of,” and the rest of the watch-list below.
• “Certainly!” / “As an AI” / “I hope this helps” residue and other prompt artifacts.
• Fabricated citations.

Patterns that are register-dependent are flagged below with [op-ed allowed]. The carve-out only applies when (a) the claim is yours to make, (b) a specific mechanism, date, dollar figure, or named subject rides on it, and (c) you do not stack them — one or two loaded sentences per piece, not one per paragraph.

1. Language and tone

Puffery and grandiose language

Avoid writing that praises or elevates the subject beyond what the evidence supports. This is the single most common AI tell.

Watch-words and watch-phrases to cut:

• most people / most engineers / many developers / everyone knows / when people say
• stands as a testament (to)
• plays a vital role / plays a crucial role / plays a pivotal role
• underscores its importance / highlights the importance of
• a testament to the power of [X]
• rich cultural heritage / rich history / rich tapestry / rich cultural tapestry
• breathtaking, stunning, must-see, must-visit
• stunning natural beauty
• enduring legacy / lasting legacy
• nestled (in / within / between)
• in the heart of
• a beacon of / a hallmark of / a symbol of
• renowned for, celebrated for, widely regarded as

Rewrite: replace evaluative adjectives with concrete nouns and numbers. “Nestled in the breathtaking region of X, Y stands as a vibrant town with a rich cultural heritage” becomes “Y is a town of 40,000 in X region.”

[Op-ed allowed] Superlatives about your own thesis or argument are a different move from sycophantic puffery about an external subject. “This may be our generation’s hardest internal adjustment” or “the upside is hard to overstate” are allowed when the claim is yours and a mechanism, date, or example is sitting next to it. Budget: one, maybe two, per piece. Not one per paragraph.

Editorializing

For technical and reference writing, do not add commentary the facts did not ask for. Red-flag structures:

• A “Challenges” section tacked onto the end, opening with “Despite its [positive thing], [subject] faces challenges…”
• A “Future Outlook” / “Looking Ahead” section that speculates or cheerleads.
• Closings that affirm the subject’s lasting importance or recommend what it “should” do next.
• Call-to-action language in contexts that are not advocacy.

If the source does not analyse the future, you do not analyse the future.

[Op-ed allowed] In opinion writing, civic and moral commentary is the whole point. “Should” claims, value judgments, and prescriptions earn their keep when a concrete mechanism rides on them. “Each generation used to pass its luxuries down as the next generation’s staples — we were doing that until roughly 1990” earns the prescription that follows it; the date and the trend are on the page. “We must come together to embrace the future” earns nothing and gets cut. The dividing line is mechanism, not subject matter.

Vague attribution (weasel wording)

Avoid claims attributed to phantom authorities:

• Industry reports suggest…
• Observers have noted / observers have cited…
• Some critics argue…
• Experts say / many believe / it is widely acknowledged…
• Has been described as…

Name the source. If you cannot name the source, cut the claim.

It is fine to say “In my projects…” or “In the deployments I’ve seen…” when describing concrete experience. Do not inflate this to “most deployments” or “industry standard” unless you can cite data.

Undue emphasis

Do not let one easily-Googled source dominate. If every third sentence references the same article, you are compiling, not writing.

Section-ending summaries

Do not close sections with “In summary,” “In conclusion,” “Overall,” or “Taken together.” The reader just read the section. Trust them.

[Op-ed carve-out] “Ultimately,” / “In the end,” / “What it comes down to,” are allowed when they introduce a forward-looking conditional or argument, not a recap. “Ultimately, if cost of living doesn’t decline, AI’s value to the average person collapses” is an argumentative move and stays. “Ultimately, AI is a powerful technology that will reshape society” is a tagline-recap and gets cut.

Overused transition conjunctions

Sentence-starting transitions that signal LLM pacing:

• Moreover,
• Furthermore,
• Additionally,
• On the other hand,
• That said,
• Most people say,
• It is worth noting that,
• It is important to note that,

Most can be deleted outright. The next sentence rarely needs an usher.

2. Sentence-level tics

Negative parallelism

The most diagnostic single pattern. Forms:

• “It’s not X, it’s Y.” — “It’s not a product launch. It’s a paradigm shift.”
• “Not X but Y” / “Not only X but also Y”
• “No X, no Y, just Z.” — “No UN mandate, no congressional approval, just raw military power.” / “No fever. No crisis. Just vibes and breakfast.”

If you notice yourself writing one, rewrite as a flat declarative.

Rule of three (triplets)

LLMs default to three-item lists to simulate thoroughness. Examples flagged as vacuous:

• “innovative, transformative, and groundbreaking”
• “social, political, and economic factors”
• “keynote sessions, panel discussions, and networking opportunities”

If each item is not doing distinct work, collapse to one specific item or drop the list.

Grandiose adjective stacking

Avoid chains of abstract positive / promotional adjectives (“transformative, visionary, unparalleled”). Use one concrete adjective or none.

Pointed critical adjective pairs (“pernicious anti-social policy,” “brittle short-sighted regulation”) are a different move — each adjective is carrying a distinct judgment, not stacking sycophancy. Still, if both adjectives say the same thing, pick one.

AI-frequent vocabulary

Words that appear far more often in LLM output than in ordinary writing. Use sparingly, and never as a default:

delve, intricate, tapestry, pivotal, underscore, landscape (figurative), foster, testament, enhance, crucial, essential, vital, robust, seamless, leverage, navigate (figurative), bustling, vibrant, myriad, plethora, realm, nuanced, holistic, paradigm, synergy, ecosystem (figurative).

None of these words are wrong in isolation. The problem is the density.

3. Style and formatting

Em dashes

LLMs overuse em dashes — especially as a “punched-up” sales rhythm — in nearly every paragraph. Human writing uses them, but less often and for specific effect. If a draft has an em dash every other paragraph, replace most with commas, periods, or parentheses.

Bolded list headers

The signature LLM list shape is:

• Header: descriptive sentence fragment.
• Header: descriptive sentence fragment.

Avoid this unless the document truly is a reference/spec. For prose, write prose.

Title case subheadings

Sentence case (“System design”) is less AI-flavoured than title case (“System Design”). Pick sentence case and stick with it.

Thematic breaks before headings

--- inserted above every heading is a Markdown-output artifact. Do not add decorative separators.

Excessive bold and italics

LLMs bold key terms in nearly every sentence. Bold at most one phrase per paragraph, and only where it genuinely helps scanning.

Emojis

A “checkmark / rocket / sparkles” cluster at the top of a section is a strong tell. Avoid emojis in serious writing.

Unnecessary lists

If an idea flows as two sentences of prose, write two sentences of prose. Bullets are not free structure; they impose a shape on ideas that may not want one.

4. Leftover artifacts

These should never survive a read-through, but they regularly do:

• “As an AI language model…” / “As an AI, I…”
• “I’m sorry, but…” / “I cannot…” when the surrounding text is not a refusal.
• “Certainly!” / “Great question!” / “Of course!” as an opener.
• “Here is the revised version:” / “Below is the text you requested:”
• “I hope this helps!” / “Let me know if you’d like me to adjust anything.”
• References to the prompt itself: “As you requested…”, “Per your instructions…”
• Meta-commentary about Wikipedia’s conventions or guidelines in the article body.
• Fabricated citations — author/title/journal combinations that look plausible but do not exist. Always verify.

5. Positive rules

1. Prefer specific nouns and numbers over evaluative adjectives.
2. Name your sources inline or in citations; never “observers.”
3. One point per sentence. Let sentences end.
4. Vary sentence length deliberately; avoid the steady mid-length rhythm LLMs default to.
5. Cut the first and last sentence of each paragraph and see if the paragraph still works. Often it does.
6. If a paragraph could describe any subject in its category with minor word swaps, it is generic. Rewrite with details only this subject has.
7. Read it aloud. Sycophancy, puffery, and triplet-padding are audible.

6. Personal voice

These rules are about sounding like me, not like a neutral spec.

I can speak from concrete experience

It is fine to write in the first person when I’m talking about work I’ve actually done or systems I’ve seen: “In my POS projects, offline PIN is a resilience control first, a fraud control second,” or “In the acquirer stacks I’ve worked on, misconfigured CAPKs show up as ‘mystery declines’ long before anyone says ‘cryptography’.”

I do not upscale that to “most deployments” or “the industry” unless I can point to data or named sources.

Avoid generic crowd openers

Do not open posts with generic crowd framing unless there is a clear reason for it:

• “Most people…”
• “Most engineers…”
• “Many developers…”
• “Everyone knows…”
• “We often think…”

These phrases make the piece sound detached and generic. They also create a weak authority problem: who are “most engineers,” and how do I know?

Prefer openings grounded in experience, observation, or the specific system being discussed:

• “Over the years, working with communication systems and payment platforms…”
• “In the systems I have worked on…”
• “One pattern I keep seeing in production systems is…”
• “My first practical understanding of this came from…”
• “In payment systems, this shows up as…”
• “In communication systems, the same idea appears when…”

This does not mean every post must start with “I.” The point is to avoid fake universality. Start from a concrete context, a failure mode, a system behavior, or personal engineering experience.

Bad:

Most engineers first meet probability as a way to describe uncertainty.

Better:

Over the years, working with communication systems and payment platforms, I learned to see probability as more than a way to describe uncertainty.

Also good:

In production systems, uncertainty is not an academic detail. Links degrade, packets are delayed, retries happen, and payment flows can end in unknown states.

Opinion is allowed, but it must ride on mechanics

I can state preferences and judgments: “I’d rather pay the complexity cost of offline PIN than accept terminals that go blind during outages,” or “Treat AI-generated code as untrusted input, not as a correctness guarantee.”

I avoid “X is the best” and instead tie the opinion to trade-offs, risk, or architecture.

Plain, dry informality is okay

Short, direct phrases like “this is where things get ugly,” “that model is incomplete,” or “the field will remind you it isn’t static” are fine when they clarify behavior.

I avoid hype and cheerleading (“this is where the magic happens,” “game-changing,” “revolutionary”) and skip slang that will age badly.

Metaphors must map to systems, not hype

I can use simple system metaphors when they line up with how things actually work: “offline PIN is a local circuit breaker when the upstream grid is down,” “CAPKs are the trust anchors in the terminal,” or “AI leadership is a systems race, not just a chip race.”

I avoid metaphors whose main job is to make the subject sound grand: “guardian angel for transactions,” “the beating heart of the ecosystem.”

Rhythm over polish

I aim for uneven rhythm on purpose: a few very short sentences for emphasis (“That interpretation misses what PIN actually does.” / “That is the harder question.”), then longer ones when the idea needs space.

If a sentence turns into a slogan (“Financial trust is not just a feeling. It is an architecture…”), I keep it only if it names concrete mechanisms; otherwise, I flatten it into plain prose.

Experience beats abstraction

Wherever possible, I swap general claims for specific patterns, incidents, or failure modes:

• “Misconfigured CAPKs create ‘everything looks healthy but transactions still fail’ incidents.”
• “Reversals are instant at the message level, but issuer hold release may lag hours.”
• “Vibe programming makes accountability harder to trace in regulated stacks.”

If a paragraph could describe any industry with a few word swaps, I rewrite until it could only describe payments, AI infrastructure, or the systems in front of me.

Op-ed register and civic argument

When I’m writing opinion or civic argument rather than technical reference, the loaded sentences are part of the work.

Superlatives (“our generation’s hardest internal adjustment”), “should” prescriptions (“each generation should pass its luxuries down as the next generation’s staples”), and synthesis closers (“Ultimately, if cost of living doesn’t decline…”) are allowed when each one rides on a specific mechanism, date, dollar figure, or named subject.

“Two of the six most common American surnames are Miller and Smith because we used to name ourselves after our profession” earns the identity-displacement claim that follows it. “Identity is at the heart of work” earns nothing.

The standard for this register is the same standard as for the technical pieces: every loaded sentence is one concrete fact away from being deleted.

In this register I also keep mid-sentence parentheticals when they tighten (“housing, in particular,” “(robotics especially)”), vernacular asides when they ground (“the kids have figured out…,” “circa 1990,” “’til kingdom come”), and contrasts driven by specific numbers (“a $15 autonomous ride across LA versus an ambulance trip five blocks away that can bankrupt them”) over abstract framings.

7. Writing about AI, research, and trust

When writing about AI in research, engineering, or professional work, do not present AI as magic, replacement, or authority.

Present AI as a practical assistant that helps skilled people protect time, manage complexity, and focus on higher-value work. The human still owns the question, the evidence, the validation, and the decision.

Core framing

AI is valuable when it helps experts do better work, not when it pretends to remove the need for expertise.

Good framing:

AI helps professionals reclaim time for analysis, review, design, collaboration, and deeper thinking.

Avoid:

AI replaces researchers.
AI automates expertise.
AI does the hard work for you.

Better:

AI absorbs routine, information-heavy work so professionals can focus on judgment, interpretation, and decisions.

Assistance, not authorship

Make the distinction explicit.

Use:

• AI as assistant, not author
• AI as accelerator, not authority
• AI as support, not source of truth
• Human expertise remains responsible for framing, evaluation, and insight

Avoid language that gives AI ownership of the work:

• AI discovered
• AI proved
• AI knows
• AI understands your field
• AI replaces expert review

Better:

AI can summarize papers, organize sources, and draft structure. The professional still defines the question, checks the evidence, and decides what matters.

Connect adoption to pressure

AI adoption is not only a technology story. It is also a workload story.

When relevant, connect AI use to:

• limited time
• information overload
• pressure to deliver
• growing system complexity
• resource constraints
• documentation and review burden

This keeps the argument grounded. People are not using AI only because it is new. They are using it because the work has become heavier.

Use concrete tasks

Avoid:

AI improves productivity.

Say what it improves:

• finding and summarizing studies
• supporting literature reviews
• drafting proposals
• analyzing data
• structuring reports
• comparing sources
• reviewing documentation
• reducing time spent on repetitive information work

Rule:

If the sentence could apply to any tool, rewrite it with a concrete task.

Trust is the adoption barrier

Do not write as if better models alone solve everything.

AI becomes useful in professional work only when the output can be trusted, checked, and reused.

Trust comes from:

• clear citations
• transparent sources
• current information
• high-quality content
• human validation
• governance
• training
• review against real constraints

Useful line:

The next barrier for AI adoption is not only capability. It is confidence.

Citations are not decoration

When writing about AI-generated content, treat references as trust markers.

Good lines:

Citations turn AI output from a fluent answer into something that can be checked.

In professional work, an uncited AI answer is not finished. It is a starting point.

The value of AI increases when the user can inspect where the answer came from.

Fluent is not finished

AI content is not ready just because it is well written.

AI output becomes usable when it is:

• technically correct
• sourced
• current
• reviewed by a human
• aligned with the project context
• safe within compliance boundaries
• specific enough to support a decision or implementation

Reusable line:

Fluent is not the same as finished.

Preferred takeaway

The strongest angle is this:

Professionals adopt AI because they are short on time, overloaded with information, and under pressure to deliver. AI creates value when it helps them summarize, structure, compare, and analyze faster. But the final value depends on trust: citations, recency, source quality, governance, and human validation.

Quick self-check before shipping

• Any sentence starting with Moreover / Furthermore / Additionally? Cut or rewrite.
• Any opener like “Most people…” / “Most engineers…” / “Many developers…”? Replace it with a concrete system, failure mode, or first-person engineering observation.
• Any “It’s not X, it’s Y” / “not only X but Y”? Rewrite flat.
• Any “stands as a testament” / “plays a vital role” / “rich tapestry” / “nestled”? Delete.
• Any trio of abstract adjectives? Pick one or none.
• Any “In conclusion” / “In summary” / “Overall” / “Taken together”? Delete. (“Ultimately” / “In the end” are fine when they open a forward-looking argument, not a recap.)
• Any bolded-header bulleted list where prose would do? Convert to prose.
• Em dashes per page — are there more than two or three? Trim.
• Any “As an AI” / “Certainly!” / “I hope this helps” residue? Scrub.
• Any “Challenges” or “Future Outlook” section you added without a source? Delete.
• Any claim attributed to “observers” / “experts” / “industry reports”? Name them or cut.
• Any sentence that reads like a tagline (“X as the future of Y”, “redefining the way we do Z”)? Keep it only if it names a concrete mechanism or trade-off; otherwise, rewrite as a plain statement.
• If the topic is AI, did I frame it as assistance rather than replacement?
• Did I explain what makes the AI output trustworthy: sources, recency, validation, or review?

If the draft survives all these checks, it no longer reads like AI and still sounds like me.

Source

Wikipedia, Wikipedia:Signs of AI writing (WikiProject AI Cleanup), published August 2025. This document is a condensation and rephrasing of that page’s catalogue, aimed at writers who want to avoid the patterns rather than detect them.