· Ben · craft · 6 min
AI content detector false positives, and why we ignore them
Detectors flag the US Constitution and 61.3% of human-written TOEFL essays. What an AI content detector false positive actually measures, why the number moves for free, and what we check instead.
Paste one of our published posts into a detector and it comes back machine-written. It is. That's a true positive, and I have nothing clever to say about it.
Paste in the US Constitution and it also comes back machine-written. Paste in a human-written TOEFL essay and there's a decent chance of the same result: 61.3% of them, on average, across seven detectors. That's the number worth arguing about, because it's the one that tells you what the tool is actually measuring.
Meanwhile the blog for Grepture, written by Contentcron from day one, did 318 clicks and 43,627 impressions in its first eight weeks. One of those numbers has paid for something. The other one is a probability from a black box that nobody with authority over my repo has ever asked me for.
So here's the argument for why an AI content detector false positive isn't a bug to be fixed, and why there is no detector step in our pipeline.
A detector doesn't measure who wrote it
Detectors mostly score two things: perplexity, how surprised a language model is by your next word, and burstiness, how much that surprise varies sentence to sentence. Text that a model finds predictable scores as machine-written. Text that wanders scores as human.
Notice what's missing. No signature, no watermark, nothing about provenance. The classifier never sees the author. It sees a distribution and infers backwards, and the inference it makes is that predictable prose comes from a machine.
Predictable prose also comes from people who write well about technical subjects. Correct order of operations, terms defined before use, no ornament. That's a style guide, and it's also a low-perplexity generator.
The Constitution is AI-generated, apparently
In July 2023 Ars Technica ran the story of detectors confidently flagging the US Constitution as AI output. GPTZero's Edward Tian gave the explanation, and it's the whole ballgame: the text appears so often in training data that models generate text that looks like it. Nothing is malfunctioning. The detector is reporting, accurately, that this string is highly probable under a language model.
Your API reference prose has the same problem. So does your migration guide, your changelog, your "here's what shared_buffers actually does" explainer. Documentation is written to be unsurprising. That is the job.
Which means the detector's advice, followed honestly, is: write worse. Add clauses that don't earn their place. Vary the rhythm at random rather than for emphasis. Reintroduce the ambiguity you spent two drafts removing. I'm not doing that to move a number.
The vendors already told you this
The people selling detection have been more honest in public than the SERP suggests.
Turnitin launched in April 2023 promoting a false-positive rate under 1% at the document level. By June, its chief product officer had disclosed roughly 4% at the sentence level, which is a different claim wearing the same suit. Today the product suppresses any score in the 1–19% range entirely, no highlights, just an asterisk, specifically because that band produced too many false positives. That's a vendor telling you the bottom fifth of its own scale is noise.
Then there's OpenAI, which shipped an AI Text Classifier and pulled it on July 20, 2023 citing low accuracy. The organization with the most access to the training distribution of the thing being detected tried, and quit, in under six months.
61.3%
The Stanford study is the one to know. Liang et al. ran seven GPT detectors against 91 human-written TOEFL essays and 88 US eighth-grade essays. The eighth-graders were classified accurately. The non-native English writers averaged a 61.3% false-positive rate; 97.8% of their essays were flagged by at least one detector, and 19.8% were unanimously misclassified by all seven.
The broader picture isn't better. Weber-Wulff et al., in the International Journal for Educational Integrity, found every tool tested scored below 80% accuracy, with only five above 70%, and cite van Oijen's overall accuracy figure of 27.9%.
Put the vendor number and the independent numbers on the same axis and the gap is the argument. Under 1% is a document-level false-positive rate the vendor measured on its own corpus. 61.3% is a false-positive rate an outside lab measured on real essays from real people. Those are different metrics, and only one of them describes what happens to your writing.
Sources: Liang et al., GPT detectors are biased against non-native English writers; Turnitin, Understanding the false positive rate for sentences of our AI writing detection capability; Weber-Wulff et al., Testing of detection tools for AI-generated text; van Oijen, AI-generated text detectors: Do they work?
Those errors land on someone. In academia it's an international student in a disciplinary meeting. On a company blog it's nobody, because nobody is holding the hearing.
The score moves for free
Sadasivan et al. showed that recursive paraphrasing dropped watermark detection from 99.8% to 9.7% true positive rate at a 1% false positive rate, with minimal loss of text quality. The same paper demonstrates the attack in reverse: human text can be pushed to look machine-written. Krishna et al. found much the same, that paraphrasing evades detectors and retrieval is about the only defense that survives.
There is an entire product category built on this. Nine dollars a month buys you a paraphraser that takes any score to zero without changing a single claim in the article, without adding a source, without checking whether the benchmark you quoted is real.
A metric you can zero out with a subscription, while the article stays exactly as wrong as it was, is not a quality metric. It's a formatting check that half the internet has agreed to treat as a verdict.
Google doesn't run a detector, it runs spam policies
The fear underneath most of these searches isn't the score. It's a ranking penalty.
Google's guidance on AI-generated content has said the same thing since February 2023: the helpful content system targets content made primarily for search rankings rather than for people, and the focus is quality, not production method. The enforcement surface is the spam policies, where scaled content abuse was added in the March 2024 update. Mass-produced pages with nothing in them. No documented detector signal, anywhere.
So a classifier reading your post was never the risk. Publishing forty of them in a week, none of which said anything, is. We watched this play out on our own domain and wrote up what eight weeks of Search Console actually looked like, screenshot unedited.
What we check instead
Everyone piles on the detectors and then leaves you without a replacement standard. Here's ours, and it runs in a diff.
A figure that can't cite a source is rejected. Not flagged, rejected. That's why every chart we ship prints its source inside the image, and there's no AI image generation anywhere in the pipeline. Screenshots are real captures of the actual product, re-shot on a schedule and pixel-diffed so the URL only changes when the UI did. Frontmatter matches the repo's existing convention, field names and date format and slug style, because a post that breaks the build is a worse problem than a post that reads a little smooth. And the article arrives as a pull request, so a human who knows the product can leave a line comment on the paragraph that's wrong.
That last one is the whole substitution. A reviewer in a diff can say "this claim is stale, we shipped that in June." No detector will tell you that at any confidence level. If you want the longer version of that argument, it's why we think content should be reviewed the way you review code.
No humanizer pass, and there won't be one
We don't run a detector before opening a PR, and we don't run the output through a rewriter to lower a score.
The reason is mechanical. I'm not posturing about principles. The only lever a humanizer has is to make prose less predictable, and less predictable is a synonym for less clear. I'd be paying compute to degrade an article in order to move a number that has no enforcement attached to it on your own domain. The one-click chips in the chat do the opposite job: remove AI tells, tighten, simplify, vary the rhythm. Those are edits a person would ask for on a draft, applied because the sentence is bad, not because a classifier scored it.
If a paragraph reads like a machine wrote it, the fix is to say something more specific. That happens to lower the score too. It just isn't why we did it.
When the score does matter
It matters when someone with authority is holding it.
If you're submitting coursework, the detector is the institution's process and your opinion of its accuracy is not the relevant input. If you're an agency with a 0%-AI clause in the contract, or you're publishing into a marketplace that gates on a score before it accepts the piece, then you need a number under a threshold and we can't give you one. We're not your tool. I'd rather say that here than have you find out at the invoice.
Everyone else owns the domain, owns the repo, and has no accuser.
If your blog is a folder of MDX, nobody is grading it, and the only scoreboard you actually check is Search Console, then optimize for the things a classifier can't see: sourced figures, real screenshots, claims a reviewer can challenge in a comment. The first article is free, no card. Run it through whatever detector you like afterwards, then go read the article and decide on that instead.