# Deslopping AI, Part 2: Prose > Source: > Published: 2026-10-15 20:46:28+00:00 You can often tell whether a post was written by AI or a person, but can you put your finger on why? Try to spot as many signs of AI slop as you can in this pull request (PR) description: *This PR introduces a robust caching layer for Panel’s reactive pipelines. It’s not just a performance improvement — it’s a fundamental shift in how state flows through your app. By leveraging memoization, we seamlessly reduce redundant computation, improve responsiveness, and lower server costs. Ultimately, this change empowers developers to build faster, more scalable dashboards.* If you spotted “robust,” “leveraging,” “seamlessly,” and “empowers,” those are some common ones, but swapping those words out would still leave a paragraph that reads like AI, because the rest of the problems are structural: - “It’s not just X, it’s Y” argues against a claim nobody made. - “Reduce redundant computation, improve responsiveness, and lower server costs” is a list of three because three sounds complete, not because there are three measured benefits. - The last sentence restates the first with bigger words. Delete everything that isn’t information and very little is left: *Adds memoization to the reactive pipeline.* This matters beyond style, since a reader who spots AI slop starts doubting the whole document, including the parts someone wrote carefully. For a PR description, that means the reviewer trusts the code a little less before reading a single line of it. Ironically, Claude helped me draft this post about AI slop, so I’ll let you judge how that went. Most of what follows comes from multiple passes I made flagging slop in its drafts, and some of those fixes went back into a [deslop skill](https://holoviz-dev.github.io/holoviz-skills/contributing-to-holoviz/deslop/) under `holoviz-skills`. ## Best practices for writing PRs - What makes text read as AI-written is flowery vocabulary like “delve” or “robust” in place of simple, straightforward terms, but AI patterns also include structure, like announcements, “not X but Y,” triplets, restatements, short choppy sentences, tidy closers, and heavy formatting. Swapping out words alone won’t fix all the issues. - The most effective fix is giving the model an example of the voice you want before it writes. - To clean up a draft, delete before rewriting, run a scanner (like the one under the deslop skill) for the mechanical patterns, and reread for what it missed. Then, rewrite after honing your prompt, or write the draft in your own words. - Last, have another human review it and ideally, read it out loud. ## Common pitfalls 1. Announcing something instead of saying it, with openers like “Here’s the thing,” “The key insight is,” “It’s important to note that,” and “Let’s dive in,” where the fix is to **delete the promise and keep the content** :*It’s important to note that the parser is single-threaded. → The parser is single-threaded.* 2. Contrast framing like “It’s not a tool; it’s a workflow” or “Not just faster, but cheaper” needs a wrong answer to push against, so **the model makes one up** , and the fix is to state the second half, or if both halves are real, join them into “faster and cheaper.” 3. Triplets like “fast, flexible, and scalable” show up because three has rhythm, so **count the items that are true** and keep only the ones you can back up and that aren’t repetitive. 4. Repeating the same point in new words, like, “The parser is slow. It takes a long time to run. Why is it so sluggish?” which says one thing three times, so **keep the clearest version and cut the rest** . 5. Short choppy sentences in a row, like “Banning words half works. Models find substitutes,” **chops one idea into beats** to sound decisive. Joining them with the connective they were hiding (“since,” “so,” “but”) usually reads better. 6. Tidy closers like “Ultimately, it’s about building better software” or “And that changes everything” add a sense of finish without adding information, so **if the last sentence restates the first or adds empty emphasis, cut it.** 7. Formatting as effort is bold labels on every bullet, headers over sections only two paragraphs long, and tables where a sentence would do. 8. Vague authority and passive voice attribute a claim to someone who isn’t there (“experts argue,” “many believe,” “mistakes were made”) or add “on the other hand” when one side is clearly right, so **name the source or own the claim.** ## Why models write like this One likely reason: during fine-tuning, people rate responses. Structure, balance, and emphasis all read as effort, so the model learns to add them everywhere, including where they carry nothing. It also leans toward the most common style in its training data, which includes a lot of marketing copy. A person adds a flourish when a sentence needs it while a model adds one every few sentences regardless. While writing this, I asked Claude what makes large language model (LLM) writing recognizable, and its answers came back as bold-labeled bullets under headers, ending on tidy one-liners. When I asked whether its own answers were slop, it found the not-X-but-Y pattern it had used while explaining why not-X-but-Y is bad. It’s better at spotting the patterns than avoiding them, which makes it more useful as a reviewer than as a writer. ## How to deslop ### Before you generate An example of your writing beats any list of instructions, so paste a paragraph of your own writing, or one you’d like to sound like, and ask for that voice, since, in my experience, models imitate examples far more reliably than they follow adjectives like “concise” or “natural.” (This is how the draft of this post started: I handed Claude [my last post](https://www.anaconda.com/blog/deslopping-ai-code) and said “this is my tone of voice.”) It also helps to describe the reader, since “the reader already maintains a Panel app” cuts the warm-up explanations. Then, describe what you want rather than what to avoid, because “don’t sound like AI” is vague. Model choice matters too. On the same diff, Claude Opus 5 sounded archaic, while Claude Opus 5.5 was much easier to read. ### After you generate Delete first, since most slop is extra words. Openers, closers, hedges, and announcements carry no information, and the LLM can’t replace them with new slop. For the mechanical patterns, a scanner catches them consistently, and the [deslop skill in holoviz-skills](https://holoviz-dev.github.io/holoviz-skills/contributing-to-holoviz/deslop/) includes a scanner: ``` python3 scripts/deslop_scan.py draft.md ``` It flags phrases and sentence patterns, and `--em-dash` and `--colon-triple` turn on two checks that are noisy in technical writing. It has false positives (a legitimate “no X, no Y” in quoted dialogue, say), and it can’t see a paragraph that tries to sound deep without tripping a regex. So the skill pairs the scan with a judgment pass: read the whole piece, fix hits one at a time, then re-scan and justify every hit that’s left. Reading it aloud also works, since triplets and restatements are obvious when spoken. If you control the model, fine-tuning is another option: train it against a reward that scores slop, so it writes less of it to begin with. [Sophia Yang’s first reinforcement learning (RL) run with the Jev reward model](https://www.linkedin.com/pulse/getting-started-your-first-rl-run-jev-reward-model-sophia-yang-yrmpc/) is a good place to start. ### What not to do Banned-word lists help at the margins, but models route around them, so ban “delve” and you get “dig into,” and a rewrite that swaps “Here’s the thing” for “The reality is” hasn’t fixed anything. Don’t sand your voice down to neutral either: if you write short punchy sentences or like an occasional emoji (guilty 😛), keep them. And if a draft is slop from top to bottom, an edit pass gives you a slightly cleaner bad draft, so start over with an example of the voice you want. ## Wrapping up The deslop skill and scanner are [in `holoviz-skills`](https://holoviz-dev.github.io/holoviz-skills/contributing-to-holoviz/deslop/), but they only get you part of the way, so it’s still important to review the result yourself before it goes out, and if you find slop that slipped through in this post, let me know by [posting them on the forum](https://forum.anaconda.com/). Want some tips for deslopping your AI code? [Check out part 1 of this blog series](https://www.anaconda.com/blog/deslopping-ai-code).