Thirty Rules for Sounding Less Like a Language Model

There is a dialect currently colonizing professional communication. It turns every minor update into a pivotal moment, every tool into a catalyst, and every list into a rule of three. You have read it in SEO blogs that open with formulaic abstractions about landscapes, in LinkedIn posts that declare “It’s not just X, it’s Y,” and in customer-service emails that sign off with “I hope this helps!” This is not merely bad writing. It is the predictable residue of large language models doing exactly what they are designed to do: predict the statistically most likely next token across the broadest possible distribution of contexts. The result is prose that is grammatically flawless, semantically hollow, and stylistically contagious.

The market response has been bifurcated. On one side sits a booming industry of “AI humanizers”—commercial services such as ZeroGPT, HumanizeAI.pro, and SuperHumanizer that promise to launder AI-generated text through proprietary algorithms so it can bypass Turnitin, GPTZero, and Originality.ai [1][4][10]. SuperHumanizer claims a 97% success rate at this evasion after training on 15 million human-written samples [10]. ZeroGPT advertises an advanced model that delivers 99% readability and a high score-as-human rate on detection tools [1]. These tools frame the problem as adversarial. The text is not being improved; it is being disguised.

On the other side is blader/humanizer, an open-source skill for Claude Code and OpenCode that approaches the problem as editorial hygiene. It does not mention detectors. It does not claim to bypass anything. Instead, it cites a single, unlikely authority: Wikipedia’s “Signs of AI writing” guide, maintained by WikiProject AI Cleanup. The project’s central insight is that LLM output is not merely statistically anomalous to a classifier; it is rhetorically predictable to a human editor. It leaves fingerprints in the form of thirty recognizable patterns, and those patterns can be systematically excised.

The skill is architecturally simple but conceptually sharp. It is not a standalone application or a fine-tuned model. It is a structured prompt artifact—a “skill” in the Claude Code ecosystem—that instructs the host language model to audit and rewrite text according to an explicit taxonomy. In this ecosystem, a skill is essentially a system prompt injected into the agent’s context window, giving it a persistent capability accessible via a slash command. This means the humanizer is not an external API call or a separate model download; it is a reasoning framework that runs on whatever hardware is already hosting the developer’s coding assistant.

The taxonomy is the project’s real contribution. It divides AI tics into five categories: content, language, style, communication, and filler.

Content patterns reveal the LLM’s tendency to hallucinate importance. “Significance inflation” turns the mundane into the monumental; a regional statistics bureau is not merely established, it is “marking a pivotal moment in the evolution of.” “Notability name-dropping” cites The New York Times, BBC, and The Hindu in a single breath to imply credibility without specifics. “Superficial -ing analyses” string together participles—“symbolizing, reflecting, showcasing”—to create the illusion of depth where no source exists. These habits arise because training data is heavy with promotional web copy and because the model’s objective function rewards confident, generalizable continuation.

Language patterns expose syntactic tics. “Copula avoidance” is the allergic reaction to the verb “is,” replaced by “serves as,” “functions as,” or “stands as” to create an air of technical authority. “Synonym cycling” refuses to repeat a word, turning the protagonist into the main character, then the central figure, then the hero, as if clarity were less important than variety. “Negative parallelisms” insist on framing every point as a negation: “It’s not just X, it’s Y.” The LLM is not being evasive; it is being probabilistically cautious, and caution reads as formula.

Style patterns attack the visual formatting of confidence. Em-dash overuse creates a faux-literary cadence. Boldface and inline-header lists turn prose into slide decks. Title-case headings, emojis, and fragmented headers reveal a document structured by outline rather than argument. The skill treats these not as aesthetic choices but as symptoms of a model that organizes information hierarchically because it lacks a human reader’s sense of pace.

Communication patterns are perhaps the most grating. “Chatbot artifacts” such as “Great question!” and “Let me know if you need anything else!” leak the asymmetry of the human-AI interaction into the final text. “Sycophantic tone” (“You’re absolutely right!”) and “cutoff disclaimers” (“While details are limited in available sources…”) are the model’s uncertainty expressed as flattery or hedging. Finally, filler and hedging patterns strip out the throat-clearing: “In order to,” “Due to the fact that,” “could potentially possibly”—the linguistic equivalent of a nervous cough.

What elevates the project above a mere list of pet peeves is its operational design. The skill performs a two-pass rewrite. The first pass removes the thirty patterns. The second pass conducts an “obviously AI generated” audit to catch artifacts that survived the initial edit. This acknowledges a hard truth about LLM output: the tics are layered. Removing the em dashes and boldface in pass one may still leave behind the significance inflation and copula avoidance. The audit functions like a copy editor with a fresh cup of coffee.

The skill also offers voice calibration. Instead of producing generic “clean” output, it can analyze two or three paragraphs of the user’s own writing and mimic their sentence rhythm, word choices, and quirks. This is a meaningful departure from commercial humanizers, which often replace one generic register with another. Voice calibration recognizes that “human” is not a monolithic style; it is specific, idiosyncratic, and sometimes deliberately rough. The README’s worked example demonstrates the effect brutally. The “before” text is a masterpiece of the genre, complete with testament, landscape, and nested em dashes. The “after” text reads like an engineer at a whiteboard: “AI coding assistants can speed up the boring parts of the job. They’re great at boilerplate.” The transformation is achieved not by adversarial perturbation but by editorial instruction.

The broader context makes this approach look almost radical. A survey by Metaflow AI describes the typical humanizer as combining “pattern detection, contextual rewriting, tone and style adjustment, plagiarism and detector evasion” [9]. Anangsha’s review of thirty-plus tools notes that most platforms now combine humanization with rewriting, offering “Stealth Scores” and paragraph-level rewrites designed to fool specific classifiers [2]. Grammarly, the incumbent, offers tone adjustments and an Authenticity suite [2]. FlowHunt.io notes that search engines reward genuine expertise and engagement, which raw AI output often fails to deliver because it reads formulaically without added value [12]. Even prompt-based approaches, such as those described by Marcus Sheridan, are often framed around velocity—producing articles ten times faster while adding “soul” [3].

Against this, humanizer is a text file. It is MIT-licensed. It is versioned—currently at 2.7.0 with thirty patterns, up from an initial twenty-four—suggesting active maintenance and iterative refinement. It lives in the developer’s terminal as a skill for Claude Code and OpenCode, which means it is positioned to clean up the AI-generated documentation, commit messages, and technical posts that developers are already producing. It treats the problem as craft, not cryptography.

The adversarial approach looks even shakier in light of detector accuracy. Pangram’s comparative review of thirty AI detector tools found that even dedicated services like Quillbot and Scribbr achieved only a 44% detection rate against AI-generated text, while failing entirely on Claude-generated samples [8]. If the detectors are themselves unreliable, optimizing for their evasion is a game with moving goalposts and questionable value.

That said, the project has real limits. It is, fundamentally, a sophisticated prompt template. Its efficacy depends on the host model’s ability to recognize and correct its own kin’s habits—a slightly paradoxical request. If the underlying model is itself prone to sycophantic tone or significance inflation, asking it to edit itself may only dilute the tics rather than eliminate them. The voice calibration feature is only as good as the sample provided; a user whose own writing is already indistinguishable from AI output will simply get more of the same. And the pattern list, derived from crowdsourced Wikipedia observation rather than formal linguistics, is descriptive of today’s models, not necessarily tomorrow’s. GPT-4’s tics are not GPT-5’s tics.

There is also the risk of second-order conformity. If every AI-assisted writer runs their text through the same thirty-pattern filter, the output may converge on a new generic: not obviously LLM-generated, but obviously “humanized.” The project attempts to mitigate this by emphasizing voice calibration and by privileging specific facts over polished abstractions. Whether that is enough remains an open tension.

Still, humanizer signals a maturation in how we think about generative text. The first wave celebrated volume; the current wave is preoccupied with credibility. Tools like this suggest a future where AI output is routed through editorial pipelines—style guides, fact-checkers, and voice matchers—before it reaches a reader. In that pipeline, detection evasion becomes irrelevant. The goal is not to trick a classifier, but to produce prose a human would actually want to read. After all, the best way to sound human is not to fool a detector. It is to say something specific, in your own voice, and then stop.