De Slopify

De-Slopify

Overview

De-slopify is a methodology for removing telltale signs of AI-generated content from documentation, prose, and code. LLMs produce statistically regular output with characteristic vocabulary, punctuation habits, and structural patterns that make text and code feel inauthentic. Some patterns appear over 1,000x more frequently in LLM output than human writing.

When to use: Before publishing READMEs, after AI-assisted writing sessions, during documentation reviews, when reviewing AI-generated code for over-engineering, before committing prose or code that an LLM touched.

When NOT to use: On code logic or algorithms where correctness matters more than style. On technical specifications where precision outweighs voice. On content that was already human-written and reads naturally.

Quick Reference

Common Mistakes

Delegation

• Scan a repository for documentation files that need de-slopifying: Use Explore agent
• Rewrite an entire documentation site to remove AI artifacts: Use Task agent
• Plan a documentation voice guide and editorial workflow: Use Plan agent
• Review AI-generated code for slop patterns: Use code-reviewer agent

For systematic quality auditing across 12 dimensions (architecture, security, testing, performance, etc.), use the quality-auditor skill.

References

• Prose patterns: emdash alternatives, phrase replacements, and voice calibration
• Before-and-after examples of common AI writing fixes
• AI slop vocabulary: words and phrases that signal LLM authorship
• Code slop: detecting and fixing AI-generated code smells
• Review workflow: prompts, checklists, and integration

Before and After Examples

Emdash Chain

Three or more emdashes in a single sentence is one of the strongest AI writing signals.

BEFORE:
This tool--which we built from scratch--handles everything automatically--from parsing to output.

AFTER:
This tool handles everything automatically, from parsing to output. We built it from scratch.

The fix restructures the sentence rather than swapping punctuation one-for-one.

"Here's Why" Lead-In

BEFORE:
We chose Rust for this component. Here's why: performance matters, and Rust delivers.

AFTER:
We chose Rust for this component because performance matters.

Delete the lead-in and fold the explanation into the previous sentence.

Contrast Formula

BEFORE:
It's not just a linter; it's a complete code quality system.

AFTER:
This complete code quality system goes beyond basic linting.

Alternative fix when the contrast is the actual point:

BEFORE:
It's not about writing less code, it's about writing the right code.

AFTER:
Writing less code is not the goal. Writing the right code is.

Forced Enthusiasm in Getting Started

BEFORE:

# Getting Started

Let's dive in! We're excited to help you get up and running with our amazing tool.
In this guide, we'll walk you through everything you need to know.

AFTER:

# Getting Started

Install the CLI and run your first command in under a minute.

Delete the enthusiasm. Delete the meta-commentary about the guide. Start with what the reader does.

Robotic vs. Authentic Technical Writing

BEFORE:
Artificial intelligence is revolutionizing the way we write code. It provides
efficiency and reduces the time required for development tasks. However, it is
important to maintain quality. In this comprehensive guide, we'll explore best
practices for leveraging AI in your workflow.

AFTER:
Raw AI code is often a mess of predictable patterns and dropped context. Speed
is a trap if you aren't auditing for intent.

The before version has five AI tells: "revolutionizing", "leveraging", "comprehensive guide", "we'll explore", and the passive hedge "it is important to maintain quality." The after version has zero.

Pseudo-Profound README Opener

BEFORE:

# MyLib

At its core, MyLib is a lightweight, developer-friendly library that
fundamentally transforms how you handle state management. In the
ever-evolving landscape of frontend development, it's worth noting
that MyLib stands out.

AFTER:

# MyLib

A 2KB state manager for React. Replaces useState + useContext for
cross-component state without the boilerplate.

Delete every sentence that says nothing specific. Replace with facts: size, what it replaces, what pain it removes.

Over-Hedged Technical Claim

BEFORE:
It's important to note that, while there are many approaches to caching,
it's worth considering that Redis might be a good option for your use case,
depending on your specific requirements and constraints.

AFTER:
Use Redis. It handles our caching patterns and runs on every cloud provider.
If your data fits in memory, it is the default choice.

Three hedges in one sentence is a strong tell. Pick a position and state it.

Uniform Sentence Length

BEFORE:
The middleware validates incoming requests against the schema. It rejects
malformed payloads with a descriptive error message. The error includes
the field name and the expected type. This helps developers fix issues
quickly without checking the documentation.

AFTER:
The middleware validates requests against the schema. Malformed payloads
get rejected with an error that names the bad field and its expected type.
No need to check the docs.

The before version has four sentences of nearly identical length (9-11 words each). The after version mixes a medium sentence, a longer one, and a short punchy closer.

API Documentation Intro

BEFORE:
Welcome to the API documentation! In this comprehensive guide, we'll walk
you through all the endpoints available in our powerful and flexible API.
Whether you're a seasoned developer or just getting started, you'll find
everything you need to integrate seamlessly with our platform.

AFTER:
Base URL: https://api.example.com/v2

All endpoints require an API key in the Authorization header. Rate limit:
1000 requests per minute. Responses use JSON.

API docs should open with the base URL and auth requirements, not a welcome message.

Blog Post Closer

BEFORE:
In conclusion, we've explored three key patterns for handling errors in
distributed systems. By leveraging these approaches, you can build more
resilient applications. We hope this guide has been helpful on your
journey toward better error handling!

AFTER:
Retry with backoff, use circuit breakers at service boundaries, and
dead-letter failed messages for manual review. That covers 90% of
production error scenarios.

Replace the meta-summary with the actual summary. Delete "In conclusion", "we've explored", "leveraging", and "journey."

CONTRIBUTING.md Section

BEFORE:

## How to Contribute

We're thrilled that you want to contribute to our project! Your contributions
help make this project better for everyone. Here's how you can get started on
your contribution journey:

1. Fork the repository
2. Create a feature branch
3. Make your changes

AFTER:

## How to Contribute

1. Fork the repository
2. Create a branch from `main`
3. Make your changes and add tests
4. Open a PR against `main`

We review PRs within two business days.

Delete the emotional opener. Add the missing step (PR). Add the detail that actually matters (review timeline).

Changelog Entry

BEFORE:
We're excited to announce that we've added a powerful new feature that
revolutionizes how you handle file uploads! This game-changing enhancement
provides a seamless experience for your users.

AFTER:
Added: Resumable file uploads via tus protocol. Files over 100MB upload
in chunks with automatic retry on network failure.

Changelogs should state what changed, how it works, and what threshold triggers it. Not excitement.

Code Slop

AI-generated code has its own set of tells, distinct from prose slop. Research shows that 76% of developers say AI-generated code needs refactoring, and code duplication ("copy/pasted" lines) rose from 8.3% to 12.3% between 2021 and 2024 as AI coding tools gained adoption.

Over-Commenting

The strongest code slop signal. LLMs add formal docstrings to trivial functions and line-by-line narration that restates the code.

The Tell

/**
 * Retrieves a user by their unique identifier from the database.
 * @param id - The unique identifier of the user to retrieve.
 * @returns A promise that resolves to the user object, or null if not found.
 */
async function getUserById(id: string): Promise<User | null> {
  // Find the user in the database using the provided ID
  const user = await db.user.findUnique({
    // Search by the id field
    where: { id },
  });
  // Return the found user or null
  return user;
}

The Fix

async function getUserById(id: string): Promise<User | null> {
  return db.user.findUnique({ where: { id } });
}

The types already document the signature. The function name describes the behavior. The implementation is one line. Zero comments needed.

When Comments Are Justified in AI Code

Keep comments that explain why, not what:

// Stripe webhooks retry up to 3 times with exponential backoff
const MAX_RETRIES = 3;

// Auth middleware must run before rate limiter reads user tier
app.use(auth);
app.use(rateLimiter);

Unnecessary Abstractions

LLMs over-apply design patterns. A 20-line script becomes a class with three helper methods and an abstract base class. Factories and singletons appear for problems that do not need them.

The Tell

interface DataProcessor {
  process(data: unknown): Promise<void>;
}

class UserDataProcessor implements DataProcessor {
  private readonly validator: DataValidator;
  private readonly transformer: DataTransformer;
  private readonly persister: DataPersister;

  constructor(
    validator: DataValidator,
    transformer: DataTransformer,
    persister: DataPersister,
  ) {
    this.validator = validator;
    this.transformer = transformer;
    this.persister = persister;
  }

  async process(data: unknown): Promise<void> {
    const validated = await this.validator.validate(data);
    const transformed = await this.transformer.transform(validated);
    await this.persister.persist(transformed);
  }
}

The Fix

If there is only one implementation of each interface, the abstraction is premature:

async function processUserData(data: unknown): Promise<void> {
  const user = userSchema.parse(data);
  const normalized = { ...user, email: user.email.toLowerCase() };
  await db.user.create({ data: normalized });
}

The Rule

Introduce abstractions when you have two or more concrete implementations, not before. LLMs generate "extensible" code for requirements that do not exist.

Verbose Naming

AI-generated code uses longer, more explicitly descriptive names than human developers. Research shows AI averages 19 characters per function name versus 14 for humans.

The Tell

const retrievedUserFromDatabase = await getUserById(userId);
const isUserCurrentlyAuthenticated = session.isValid();
const formattedDateTimeString = date.toISOString();
const filteredActiveUsersList = users.filter((u) => u.active);

The Fix

const user = await getUserById(userId);
const isAuthenticated = session.isValid();
const timestamp = date.toISOString();
const activeUsers = users.filter((u) => u.active);

Context eliminates the need for every noun in the name. In a function called getUser, the variable holding the result does not need "retrieved" or "fromDatabase."

Defensive Over-Engineering

LLMs wrap every operation in try-catch, validate inputs that the type system already guarantees, and add null checks for values that cannot be null.

The Tell

async function getUser(id: string): Promise<User | null> {
  try {
    if (!id) {
      throw new Error('User ID is required');
    }
    if (typeof id !== 'string') {
      throw new Error('User ID must be a string');
    }
    const user = await db.user.findUnique({ where: { id } });
    if (!user) {
      return null;
    }
    return user;
  } catch (error) {
    console.error('Error fetching user:', error);
    throw error;
  }
}

The Fix

async function getUser(id: string): Promise<User | null> {
  return db.user.findUnique({ where: { id } });
}

TypeScript enforces id is a string at compile time. The findUnique call already returns null when no record exists. The try-catch logs and re-throws, which is worse than letting the error propagate naturally.

When Defensive Code Is Justified

• At API boundaries where input comes from untrusted sources
• Around third-party service calls that have known failure modes
• In error recovery paths where you need cleanup logic

Code Duplication

LLMs generate code without awareness of the existing codebase. The same utility function gets reimplemented in multiple files with minor variations.

Detection

# Look for suspiciously similar function signatures
grep -rn "function formatDate\|function formatTimestamp\|function dateToString" src/

The Fix

Extract duplicated logic into a shared utility. LLMs resist this because each generation is context-independent; they do not know what already exists elsewhere.

Statistical Regularity

Human code varies in style across a file. Some functions are terse, others verbose. AI-generated code maintains eerily consistent patterns:

• Every function has exactly the same comment structure
• All error messages follow the same template: "Error [verb]ing [noun]: [error]"
• Import blocks are identically organized across every file
• Every function is roughly the same length

The Fix

Inconsistency is not a problem to solve. If the code works and is readable, do not impose artificial uniformity. The tell is when uniformity already exists across code that should show natural variation.

Code Slop Review Checklist

Model Collapse in Iterative AI Edits

When AI assistants repeatedly modify code without human oversight, each iteration introduces small deviations from best practices. Variable names become more generic, comments replace clear code, functions grow longer, and domain concepts blur. This is called "model collapse" in codebases.

The defense: after every AI-assisted editing session, do a human review pass specifically looking for:

• Generic names that replaced domain-specific ones (e.g., data replacing invoice)
• New comments that explain obvious code
• Increased function length
• Lost abstractions that were previously correct

Prose Patterns

Emdash Alternatives

LLMs overuse emdashes in places where humans would choose commas, semicolons, colons, or parentheses. The fix is never mechanical; each instance requires reading the sentence and choosing the punctuation that fits.

Replacement Decision Table

When Emdashes Are Fine

Not every emdash is slop. Keep an emdash when:

• It creates a deliberate interruption that no other punctuation achieves
• The sentence would lose its punch with a comma or semicolon
• It appears once in a paragraph, not three times in a sentence

The test: if you can read the sentence aloud and the emdash pause feels natural, keep it.

Phrase Replacement Guide

"Here's Why" Family

These phrases add a clickbait cadence to technical writing. The fix is to delete the lead-in and start with the explanation.

BEFORE: We chose Postgres. Here's why: it handles our query patterns well.
AFTER:  We chose Postgres because it handles our query patterns well.

BEFORE: Here's why it matters: stale cache entries cause duplicate API calls.
AFTER:  Stale cache entries cause duplicate API calls.

BEFORE: Here's the thing about connection pooling.
AFTER:  Connection pooling has a cost most teams miss.

Contrast Formulas

The "It's not X, it's Y" structure is one of the strongest AI tells. The EQ-bench slop score weights this pattern at 25% of total detection.

BEFORE: It's not just a linter; it's a complete code quality system.
AFTER:  This code quality system goes beyond basic linting.

BEFORE: It's not about speed, it's about correctness.
AFTER:  Correctness matters more than speed here.

BEFORE: This isn't just another framework. It's a paradigm shift.
AFTER:  This framework changes how you structure server components.

Forced Enthusiasm

Delete the enthusiasm. Start with what the reader gets.

BEFORE: Let's dive in! We're excited to help you get started.
AFTER:  Install the CLI and run your first command in under a minute.

BEFORE: Ready to supercharge your workflow? Let's get started!
AFTER:  The setup takes two steps.

BEFORE: We're thrilled to announce our latest feature!
AFTER:  Version 3.2 adds streaming responses.

Pseudo-Profound Openers

These phrases promise depth but deliver nothing. Delete them and start with the actual point.

BEFORE: At its core, React is a UI library.
AFTER:  React is a UI library.

BEFORE: In essence, this approach trades memory for speed.
AFTER:  This approach trades memory for speed.

BEFORE: Fundamentally, the architecture relies on event sourcing.
AFTER:  The architecture relies on event sourcing.

Unnecessary Hedges

Hedges weaken statements. If something is worth noting, just note it.

BEFORE: It's worth noting that the API rate-limits to 100 requests per minute.
AFTER:  The API rate-limits to 100 requests per minute.

BEFORE: It's important to remember that migrations are irreversible.
AFTER:  Migrations are irreversible.

BEFORE: Keep in mind that this only works in Node 20+.
AFTER:  Requires Node 20+.

Robotic Closers

BEFORE: In conclusion, TypeScript improves developer experience.
AFTER:  (delete, or) TypeScript catches the bugs that unit tests miss.

BEFORE: To summarize, we covered three key patterns.
AFTER:  (delete the closer entirely; the reader just read the patterns)

Linguistic Pattern Breaking

Human writing has irregular rhythm. AI writing is metronomic. Breaking the pattern is as important as fixing individual phrases.

Sentence Length Variation

Mix short punchy sentences (under 8 words) with longer explanatory ones (15-25 words). If every sentence in a paragraph is 12-18 words, the text reads as AI-generated regardless of vocabulary.

BEFORE (uniform):
The caching layer handles invalidation automatically. The system checks
for stale entries every thirty seconds. The background worker processes
the queue in batches of fifty items.

AFTER (varied):
Invalidation is automatic. The system checks for stale entries every
thirty seconds, and a background worker drains the queue in batches
of fifty. Most teams never touch these defaults.

List Structure Variation

AI defaults to lists of exactly three items, with parallel grammatical structure. Humans produce uneven lists.

BEFORE (AI-typical):
- Improved performance
- Enhanced reliability
- Better developer experience

AFTER (human):
- 40% faster cold starts
- Fewer OOM crashes in production (we saw zero last quarter)
- Autocomplete actually works now

Contractions and Informality

Use contractions where the tone allows. "Don't", "won't", "we're", "it's" signal human authorship. Formal writing that never contracts feels robotic.

Specificity Over Generics

Replace vague claims with concrete details. Names, version numbers, dates, error codes, and measurements make text feel authored by someone with actual experience.

BEFORE: This significantly improves performance.
AFTER:  p95 latency dropped from 340ms to 90ms after switching to connection pooling.

BEFORE: Many developers find this approach helpful.
AFTER:  Three teams at our company adopted this after the Postgres 16 upgrade.

Voice Calibration

Before editing any document, answer three questions:

1. Who is writing? A maintainer speaks differently from a marketing team. An individual contributor writes differently from a VP. 2. What tone? Conversational, professional, terse, friendly. Pick one and hold it. 3. Who is reading? Fellow engineers tolerate jargon. End users need plain language. Stakeholders want outcomes.

Then maintain that voice consistently. Inconsistent voice across sections is itself a tell; LLMs often shift register between paragraphs because each paragraph is generated semi-independently.

The Read-Aloud Test

After editing, read the full text aloud. If any sentence makes you pause awkwardly, cringe, or sounds like a chatbot, it needs another pass. A competent developer should be able to read the document without thinking "AI wrote this."

Review Workflow

The Core Prompt

Use this prompt to trigger a full de-slopify pass on any document. The key instruction is manual, line-by-line review; no regex or automated substitution.

Read through the complete text carefully and look for any telltale signs of
"AI slop" style writing; one big tell is the use of emdash. Replace with a
semicolon, a comma, or recast the sentence so it sounds good while avoiding
emdash.

Also avoid certain telltale writing tropes, like sentences of the form
"It's not [just] XYZ, it's ABC" or "Here's why" or "Here's why it matters:".
Basically, anything that sounds like the kind of thing an LLM would write
disproportionately more commonly than a human writer and which sounds
inauthentic/cringe.

You MUST manually read each line of the text and revise it in a systematic,
methodical, diligent way. Use ultrathink.

Quick Prompt (Minor Touch-Ups)

For documents that are mostly clean but need a light pass:

Review this text and remove AI slop patterns: excessive emdashes, "Here's why"
constructions, "It's not X, it's Y" formulas, and other LLM writing tells.
Recast sentences to sound naturally human. Use ultrathink.

Code Review Prompt

For AI-generated code:

Review this code for AI-generated patterns: over-commenting (comments that
restate the code), unnecessary abstractions (interfaces with one implementation,
factories for simple construction), verbose variable names, defensive error
handling that adds no value (try-catch that logs and re-throws, null checks
on non-nullable types), and duplicated logic. Simplify to the minimal working
solution. Use ultrathink.

Pre-Edit Checklist

Before starting any de-slopify pass, answer these questions:

The Review Process

Step 1: Scan for Density

Run a quick grep to estimate slop density:

grep -icE "delve|tapestry|landscape|revolutionize|leverage|seamless|game.changer|worth noting|at its core|in essence|here's why|dive in|ever-evolving|furthermore|moreover" README.md

Use the count to decide the scope of review:

Step 2: Define Voice

Set the persona, tone, and audience before editing. Write a one-sentence voice description:

Voice: Senior engineer writing for other engineers. Direct, specific, no
hedging. Uses contractions. Cites exact versions and error codes.

Step 3: Line-by-Line Review

Work through the document section by section:

1. Read each sentence aloud (mentally or actually) 2. Flag emdashes, slop phrases, and vocabulary tells 3. For each flag, choose: delete, replace, or recast the sentence 4. Check that the fix maintains the surrounding paragraph's flow 5. Verify no technical accuracy was lost

Step 4: Rhythm Check

After individual fixes, read full paragraphs for rhythm:

• Are sentences varied in length?
• Do any paragraphs feel metronomic?
• Is there at least one short, punchy sentence per section?
• Are lists varied in item count (not always exactly three)?

Step 5: Read-Aloud Test

Read the final text aloud. If any sentence makes you cringe or sounds like a chatbot wrote it, it needs another pass.

When to De-Slopify

Files to Prioritize

Focus on public-facing text first:

1. README.md 2. CONTRIBUTING.md 3. API documentation 4. Blog posts and announcements 5. Changelog entries 6. Error messages and user-facing strings 7. CLI help text

Code comments are lower priority; they follow the project's comment policy.

Integration with Git Workflow

As a Pre-Commit Check

Add a slop scan to your review process. This is not a blocker; it identifies candidates for human review.

# In a CI script or pre-commit hook, flag files with high slop density
for file in $(git diff --cached --name-only --diff-filter=AM -- '*.md'); do
  count=$(grep -icE "delve|tapestry|landscape|revolutionize|leverage|seamless|worth noting|at its core|here's why|dive in|ever-evolving" "$file" || true)
  if [ "$count" -gt 5 ]; then
    echo "WARNING: $file has $count potential slop markers. Review before publishing."
  fi
done

As a PR Review Step

When reviewing a PR that includes documentation changes:

1. Check the diff for slop vocabulary clusters 2. Flag sections that read as unedited LLM output 3. Request rewrites with a specific voice direction, not just "fix the AI slop"

As a Periodic Audit

Run a repository-wide scan quarterly:

# Scan all markdown files and sort by slop density
for file in $(find . -name "*.md" -not -path "./node_modules/*"); do
  count=$(grep -icE "delve|tapestry|landscape|revolutionize|leverage|seamless|worth noting|at its core|here's why|dive in|ever-evolving" "$file" || true)
  if [ "$count" -gt 0 ]; then
    echo "$count $file"
  fi
done | sort -rn

Troubleshooting

"I fixed the emdashes but it still sounds AI-generated"

Emdashes are the most visible tell but not the only one. Check for uniform sentence length, generic claims, and formulaic structures. Vary rhythm and inject specific details: names, dates, numbers, version strings.

"The text sounds choppy after edits"

Over-correction. Read the text aloud. Some sentences need combining or transitional words. Not every emdash needs replacing; use judgment about which ones sound natural.

"How do I know when I'm done?"

The read-aloud test. If a competent developer can read the document without thinking "AI wrote this," you are done.

"Should I de-slopify code comments too?"

Focus on public-facing prose first. Code comments follow the project's comment policy. Over-commented AI code is a separate problem (see the code slop reference) that should be addressed during code review, not during a prose de-slopify pass.

"The AI keeps re-adding slop when I ask it to edit"

Be explicit in your prompt about what to avoid. Include the slop vocabulary list. Use the full prompt from this reference, not a vague instruction like "make it sound human." The "Use ultrathink" instruction forces deeper reasoning about each sentence.

AI Slop Vocabulary

How Slop Vocabulary Works

Certain words and phrases appear far more frequently in LLM output than in human writing. The Antislop research project found that some patterns appear over 1,000x more frequently in AI text. The EQ-bench Slop Score weights detection as 60% individual slop words, 25% contrast patterns ("not X, but Y"), and 15% slop trigrams.

These lists are not blocklists. Every word below appears in legitimate human writing. The signal is frequency and context: "delve" in a single blog post is fine; "delve" in every other paragraph is a tell.

High-Confidence Slop Words

These words are statistically overrepresented in LLM output across multiple models and prompt types. Seeing several in one document is a strong signal.

High-Confidence Slop Phrases

Slop Trigrams

Three-word sequences that appear unnaturally often in LLM output. These are subtler than single words but accumulate into an AI feel.

Newer Model Patterns

These patterns are less about individual word choice and more about conversational habits baked into RLHF-tuned models. They survive prompt engineering and show up even when vocabulary-level slop is absent.

Sycophancy

Models reflexively validate the user before answering. The praise is content-free and delays the actual response.

False Epistemic Humility

Models hedge with faux-modesty that sounds cautious but says nothing.

Meta-Commentary

Models narrate their own reasoning process instead of just reasoning.

Structured Overclarification

Models impose heavy structure on content that reads better as prose. Numbered lists, bold labels, and sub-headers appear where a single sentence would suffice.

Using These Lists

For Manual Review

Scan the document for clusters of slop vocabulary. One or two flagged words in a long document means nothing. Five or more in a single section means the section needs a rewrite, not word-for-word substitution.

For Automated Scanning

# Quick grep scan for high-confidence slop words in a file
grep -iEn "delve|tapestry|landscape|revolutionize|leverage|seamless|game.changer|cutting.edge|embark|paradigm|holistic" README.md

# Scan for common slop phrases
grep -iEn "ever-evolving|worth noting|at its core|in essence|here's why|dive in|let's explore|fast-paced" README.md

These scans identify candidates for review. Every match needs human judgment about whether the usage is natural in context.

Severity Assessment

Count slop markers per 500 words of prose: