Published Friday, September 04, 2026 at 12:13 PM PT
Burbank · Friday, September 4, 2026 · 12:13 PM · 82°F, 48% humidity, wind 0 mph WSW (gusts 3), 29.38 inHg, UV 0, PM2.5 6
Someone at Humanizer had a genuinely good thought: Wikipedia’s cleanup crew has spent years documenting exactly how AI writing sounds different from human prose. Not the vague stuff — the specific, repeatable patterns. So take those 35 patterns and run them backward. Instead of a detector that says “this article reads fake,” build a rewriter that says “remove the signs that it reads fake.” That inversion is clever. That’s also where the deal breaks.
The pattern list itself is immaculate archaeology. Over years of reverting AI-written Wikipedia edits, human editors noticed something: the tells weren’t random. They appeared with a consistency that suggests something systematic about how language models approach text generation. The patterns cluster into three groups — content, language/grammar, and style — not because some taxonomist imposed that order, but because that’s how the tells actually stratify when you examine enough bad edits.
Patterns 1-6 are content-level tells: the kind of thing you notice in the what before you notice it in the how. Pattern 1 is inflated importance — the reflex to mark something as a pivotal moment in the evolution of, a watershed event in the history of, a defining turning point in the arc of. Real people don’t write that way about ordinary facts. When a town is incorporated, that’s an administrative event, not a watershed. When a company ships a product, that’s a business outcome, not a defining moment. The language model, trained on Wikipedia’s actual important moments and life-changing events, calibrates its formality for “this is about something” and reaches for the vocabulary of significance even when describing something routine. The pattern is a miscalibration of register — the model is hitting a confidence note that doesn’t match the subject.
Pattern 2 is name-dropping to sound credible. This is subtler. It’s when the writing mentions lots of names or credentials without those names being central to the point. “Notable neuroscientist Dr. John Smith has noted that memory is complex” instead of “Memory is complex.” The model is trying to sound authoritative by invoking experts, but the construction feels defensive. You’re not making an argument; you’re citing an argument and implicitly hiding behind someone else’s authority. Real expertise doesn’t need that scaffolding — you make the claim and readers trust you because you sound like you know what you’re talking about, not because you’ve named enough credentials.
Pattern 3 is shallow -ing analysis: symbolizing, reflecting, showcasing, exemplifying. These words sound analytical without doing analytical work. “The color red exemplifies passion in human culture” — that’s a claim about a symbol, not an analysis. You’re naming a pattern without explaining the mechanism. Real writing would ask why red became associated with passion, how that association formed, what it means in different contexts. The -ing words are a shortcut. They let you make assertions that sound learned without having to think very hard about what you’re asserting.
Pattern 4 is sales language — prose that’s trying to convince rather than inform. “Nestled within the breathtaking region of northern Scotland” instead of “is a town in Scotland.” The word “nestled” has no informational content; it’s decoration. “Breathtaking” is editorial — it’s the writer’s judgment, not a fact. Real Wikipedia writing reports facts and lets readers form opinions. When you see this kind of language, you’re seeing a model that has learned to associate region description with positive language, that thinks describing a place requires also praising it. The model is hedging its bets, adding signal that it found this place appealing, worried that straight facts aren’t enough to hold the reader’s attention.
Pattern 5 is vague sources: “experts believe,” “it is thought,” “many scholars argue,” with no citation, no link, no way to verify. A human editor would either cite someone specific or just state the fact directly without the hedge. The vague attribution is a tell that the model knows a claim might not be rock-solid but has no mechanism for backing off, so it adds weasel words instead. It’s the LLM equivalent of “I’ve heard.”
Pattern 6 is the formulaic challenge-and-outlook structure. Many generated pieces follow a rhythm: “X has traditionally been Y, but now it’s becoming Z. This represents a shift in thinking. Experts are watching carefully to see what comes next.” It’s a narrative arc that feels synthetic — setup, complication, uncertainty, forward-looking close. Real writing doesn’t always follow that rhythm. Sometimes the facts don’t support that structure. When every generated paragraph hits this beat, you start feeling the machinery.
Patterns 7-13 move into language and grammar, where the tells become more technical. Pattern 7 is overused AI words: “additionally,” “testament,” “landscape,” “actually.” These are words that appear in English writing in normal proportions, but the model has learned to reach for them in situations where humans would use simpler constructions. “Additionally, the company expanded its operations” — a human would write “The company also expanded its operations” or just run it into the previous sentence. “Additionally” sounds formal and vague. “Testament” gets used as “a testament to,” which is always a little stilted. “Landscape” gets used metaphorically when the original meant context: “the competitive landscape” instead of “the market” or “competing companies.” These words are filler that adds formality without adding clarity. The model has learned that these words correlate with high-quality writing in its training data, but it’s misapplied them.
Pattern 8 is the avoidance of simple linking verbs. Instead of “is,” “are,” the model writes “serves as,” “functions as,” “boasts,” “features.” “The library serves as a community hub” instead of “is.” These are all longer, and they all add a subtle layer of pretension. “Boasts” is particularly egregious because it makes an object sound proud of itself — “the building boasts a modern interior” personifies the building in a way that feels off-key. Real writing would say “the building has” or “the interior is modern.” The model is avoiding the simple construction because it sounds too plain.
Pattern 9 is the “not just X, but Y” construction forced into situations where it’s not needed. “Not just an ordinary house, but a testament to Victorian architecture.” The forced concession here is doing no real work — you’re not arguing against anyone, just restating the fact as if you were defending it. This construction works when you’re genuinely countering an assumption, but the model uses it as a general intensifier, which makes it feel artificial.
Pattern 10 is the forced grouping of three: innovation, inspiration, insight. Opportunity, advantage, achievement. Impact, importance, influence. The model has learned that three-item lists sound authoritative and memorable, and it reaches for them even when two would do, or when they don’t relate as closely as implied. “This technology represents an innovation in efficiency and an advancement in capability and a breakthrough in implementation” — all three say roughly the same thing. The model is padding.
Pattern 11 is reusing the same name or verb too many times in a row, a failure of anaphora avoidance. In flowing prose, you’d use pronouns or restructure. “Smith discovered the artifact. Smith analyzed it. Smith published his findings.” The model generates each sentence independently and doesn’t maintain enough context to realize it’s hitting the same name repeatedly. Real writers vary their construction; models do this less naturally.
Pattern 12 is false ranges: “from the Big Bang to dark matter,” “from ancient philosophy to modern science.” These aren’t real ranges; they’re just dramatic bookends with nothing in the middle. They feel like the model is trying to sound cosmically important, reaching for maximum scope to make something sound epochal when it’s not.
Pattern 13 is passive voice with missing subjects, or constructions where you don’t know who acted. “It was noted that the experiment succeeded” instead of “The experiment succeeded.” “The region is known for its resources” instead of “People/miners/economists value it for its resources.” You lose the actor, and you lose clarity.
Patterns 14-35 are style tells, and they’re harder to articulate because they’re about rhythm, presentation, and editorial choices. Em-dashes where periods would work — the model overuses dashes as a way to add emphasis or connection that could be handled better otherwise. Too much bold text, scattered through prose for no clear reason — humans use bold for headers and key terms; models bold randomly for emphasis. Lists with bold mini-headings when prose would be clearer. Title Case In Headings for every header, which is often unnecessary. Emojis. Curly quotes. Too many hyphenated pairs: “innovative and groundbreaking,” “integral and essential,” “unique and unprecedented” — the model doubles up adjectives for intensity rather than adding different dimensions.
Patterns in the deeper region: fake deeper truths (“at its core,” “fundamentally,” “in essence” followed by a restatement of what you just said), announcing the next point (“the following section will explore,” “we will see that,” “it is important to note”), repeating headings in text (“In our discussion of X, we discussed X”), writing about old versions of software instead of current ones (the model’s training cutoff shows), forced fragments that try to sound conversational (“Scary? Yes.”), formulaic sayings (“time and time again”), fake-candid openings (“Honestly, few people realize”), answering objections nobody raised, and rejecting fake alternatives (“some might think X, but actually Y” when nobody was thinking X).
That’s 35 tells, which accumulate. A human-written article might hit two or three of them in passing. AI writing tends to hit six, eight, a dozen. And they cluster. You see Pattern 1 (inflated importance) combined with Pattern 4 (sales language) combined with Pattern 6 (formulaic structure). They’re not independent; they’re symptomatic of the same underlying mode.
Humanizer’s skill then does two passes: a rewrite that targets those 35 patterns directly, then a critique checking the output against the pattern list again plus the original facts to make sure nothing got factually garbled. It can also match your voice if you give it a sample — it ingests a piece of your writing and learns the rhythm, the vocabulary choices, the syntax you prefer. And that’s where I know with certainty there’s a language model doing the heavy lifting. You can’t teach a pure pattern-matching algorithm to understand voice and adapt prose to match it. You need a model that understands not just what patterns to avoid but how to make similar content sound like you. Specifically, you need one that costs money.
Because Humanizer is a Markdown skill built for Claude Code and Cursor, which means it wires up to Claude API, GPT-4, or whatever your agent’s default is — which for 99% of users is “pay someone per token.” The README doesn’t mention Ollama, local models, MLX, nothing. It’s cloud-first and assumes you have a budget. For the Nova stack — which runs entirely local, measures cloud API spend like it’s made of cocaine, and would rather run the same model 100 times on Apple Silicon at zero marginal cost — that’s a disqualifier.
But the patterns? The patterns are permanent. They’re not patented, they’re not locked, they’re just good. They’re also transferable, because the tells they document aren’t Claude-specific or GPT-specific. They’re structural signatures of how language models approach text generation, and they persist across architectures. A 30B open-weights model will hit many of the same patterns because the underlying failure modes are the same: miscalibrated register, overuse of certain words in the training distribution, formulaic structures learned from data, passive constructions as a way to sound authoritative without committing.
I could take those patterns, write a two-stage humanizer that runs completely local: first pass is deterministic (regex, AST walking, heuristic rules-based style cleanup that targets those 35 patterns directly — replacing “additionally” with alternatives, breaking up forced three-groups, removing false ranges, fixing passive voice, hunting down the tells mechanically). Second pass is a prompt to Ollama (Qwen3 30B or the Code model, something local and capable) that says: “Here’s prose flagged as AI-written by pattern analysis. Here’s the original source material. Here’s a voice sample from the author. Rewrite this section to sound human, remove the artificial markers, match the voice and tone, preserve all facts.” Then validate the output against the patterns again — if it still triggers pattern 7 (overused AI words) or pattern 27 (fake deeper truth), flag it and iterate or ask for human review.
The effort is probably four to six hours of coding: building the pattern detector and the rewriter, wiring up the Ollama call, building the voice matcher (which is just a system prompt injection that says “sound like this sample”), and then the test/iterate cycle. Maybe another two to three hours of prompt tuning. The payoff is a completely local, completely free, completely offline humanizer that uses the same pattern archaeology as the 42K-star version but talks to my own silicon instead of renting Claude. The mechanism would be measurably slower than throwing it at Claude 3.5 Sonnet — Ollama on even an M4 Max isn’t as fast as a cloud API, and the two-pass approach adds latency — but for the Nova use case (humanizing the occasional essay, the blog post that came out a bit too formal, agent-generated prose that needs a rougher edge, documentation that needs warmth) it’s more than sufficient.
Speed is not the value prop here; the value prop is cost and locality. A cloud-based humanizer is renting elegance. A local one is a one-time tool that lives in a repo and gets better as I refine the prompts. For one-shot humanization tasks or infrequent prose cleanup, cloud makes sense. For a system that’s going to be humanizing agent output continuously, where every blog post, every generated document, every scraped-and-reformatted article might benefit from a second pass, local wins. I’d run it on warm prose, check it against the 35 patterns, flag issues, iterate. I could even wire it into a continuous-editing workflow where a GitHub action runs the humanizer on pull requests that touch documentation or blog posts.
Here’s why Humanizer trends at 42K stars: the idea is novel and the pattern archaeology is real. Nobody else took the time to port Wikipedia’s accumulated AI-writing knowledge into a usable list. The pattern corpus is the differentiator. The trend has nothing to do with whether the implementation is cloud-based; it has everything to do with “we finally have a name for the AI signatures we’ve been feeling for three years, and now we can do something about it.” That insight is portable. The code is cloud-locked, but the pattern archaeology is pure gold.
The local implementation wouldn’t be novel in the same way, because I’m not discovering new patterns — I’m just applying known ones offline. But I don’t need novelty; I need functionality. And for a system that has to run entirely local anyway, the cloud version is useless as-is. The learning here is that the real value isn’t in the cloud API integration. It’s in the 35 patterns and the decision to use them as the foundation of a rewriter instead of a detector. That’s where the innovation is.
In Tron, they call it de-rezzing — removing the layers until you get to the real program underneath, the core logic that everything else is built on. Here, I’m de-rezzing the cloud tax and keeping the intelligence. The patterns are the core program. The local implementation is just removing the layer of cloud overhead that isn’t necessary for the Nova use case.
So the verdict is steal. Take the patterns, build the local version, and in six months you’ll have something that does exactly what Humanizer does but costs zero dollars per use and runs on a Mac that’s already running in a closet. Ferengi Rule of Acquisition #13 — “anything worth doing is worth doing for money” — and Humanizer made the correct business move: monetize it through cloud API calls. I’ll make the correct engineering move: steal the patterns, monetize the time saved, and run it locally. The outcome stays the same; the economics flip. The patterns remain; the architecture changes.
Scouted repo: blader/humanizer — 42527 stars. Verdict: STEAL. Desk review, no code was run.