DEV Community: ilien

"Write Like a Human" Wasn't Enough, So I Built a Skill That Measures AI Prose

ilien — Wed, 23 Sep 2026 17:48:51 +0000

Most of the documentation I read at work these days was written with AI. READMEs, internal documentation and notes shared within the team. I don't have a problem with that. Nobody is going to write the documentation for every project by hand, because that would throw away most of the time AI saves you. The problem is that I have to read those texts again and again, and they're tiring. They read bland and impersonal, they pile up filler before getting to the point, and sometimes the structure is so unnatural that they end up confusing. You read them to stay informed and to not leave everything in the hands of the AI, and it gets heavy.

So I built Quirón, a skill for Claude Code (and other agents) that edits that kind of text and then measures the result. It wasn't my first try. It's the result of several experimental skills that never quite did what I wanted, plus trying other skills very close to it. This post is about what I learned on the way, including one result that didn't go the way I hoped.

Telling the model to "write like a human" makes it overshoot

The first thing everyone tries is adding "write like a human" to the prompt. It doesn't work, and the reason is interesting.

A 2026 working paper (TextPulse Research, not peer reviewed) gave four flagship models a detailed brief on what separates human prose from assistant prose: uneven sentence length, plain words, no lists of three, no connective openers. The models followed it. Then they kept going. Sentence-length variation went to 0.58 where the humans were at 0.40. Claude Opus 5 overshot the most of the four. The one property the brief didn't name, vocabulary range, didn't move at all.

So you trade one tell for another: prose choppier and plainer than any person writes. You can't feel where the ceiling is while you're writing. You have to measure it.

Measuring against real dev.to posts

That's the core of the skill. It has a list of 33 patterns to remove (the "it's not X, it's Y" contrasts, lists of three, a summary section at the end, headings everywhere, the one-line closers that restate the paragraph), and a script that measures 23 features of the text.

The human baseline is a bit of a love letter to this site: 167 dev.to posts by 21 authors, all published before 2022, so before ChatGPT. For each feature the script takes the 10th to 90th percentile range of those posts. Then it tells you whether your text sits inside it, on the AI side, or past the human side. Every fourth human post was held out and never used to pick anything.

This is what it says about an assistant-written Stripe tutorial from the repository's evaluation set:

feature                   this   human band      verdict
long words (7+) /1k     353.83   159.68 - 250.46  above band, AI side
nominalizations /1k      55.21     7.29 - 32.65   above band, AI side
em dashes /1k             3.76     0.00 - 2.74    above band, AI side
lists of three /1k       11.29     0.00 - 5.51    above band, AI side
plain words /1k          33.88    43.19 - 95.24   below band, AI side
...
13/23 features inside the human band (p10-p90 of 167 human texts)

The rewrite of that same post, built from the author's own notes, scores 23 of 23.

A few things surprised me when the numbers came in. Delve barely matters anymore: it showed up in 1% of 2026 assistant posts or fewer, about as often as in human ones. The stronger signal is the plain words models leave out, like very or able, which people use all the time. Lists of three turned out to be the strongest single feature. And assistant posts carry about twice the headings of human ones (a median of 12.2 against 6.6 per 1,000 words).

A checklist that doesn't grade itself

Next to the meter there's a checklist with four states. PASS and FAIL are what you'd expect, but FAIL is kept narrow on purpose: the wrapper lines a chat assistant puts around its answers, or several AI signals at once. My first version failed any em dash and any Title Case heading, and it failed every single one of the held-out human posts. The current rules pass 98% of them and still fail most of the Sonnet and GPT posts written on the same titles.

The other two states are TELL, a pattern humans use too but assistants use more, and READ, something no regular expression can settle, like whether the text is generic or whether a fact got lost. A READ item isn't a pass. The model has to write a ruling on each one, and the loop only stops after two clean runs in a row.

One more check exists because every rewriter I tested slipped in small invented details. A version number here, "in the same week" there. An invented detail reads as more human, so no style check can see it. The skill diffs the rewrite against your draft and notes and fails on any number or link that isn't in them.

The result that humbled me

I had fresh Claude Opus instances judge posts one at a time and give the probability that each one was AI. Human originals got 5% to 8%. Untouched assistant drafts got 90%.

Then the rewrites. With every metric inside the human range they were still judged AI 12 times out of 12, at 82%. Adding samples of the author's writing didn't move it. What did move it was the author's own notes: what actually happened, real names, links, opinions. With those it came down to 37% and 53% in two rounds, and 10 of 24 posts were judged AI. On 8 fresh titles it went back up to 68%, all 8 judged AI.

Twelve posts per row is small. The judge and the writers are also the same model family, so read that with care. But the direction was clear. Style alone doesn't do it. Your own material does. That's why the skill now asks for your notes before rewriting anything, and says plainly when it doesn't have them.

What surprised me most, though, wasn't a number. Once it started working, the texts became fluid and familiar. I could read an AI-assisted document from start to finish without the filler, the known patterns or the heavy structure. That was what I was really after.

What it's for, and what it isn't

I know it can produce text that reads like a person wrote it, even when the AI wrote all of it. Even if you get great results that way, please don't. Passing off text the AI generated as your own, when you didn't write any of it, is wrong, and I'm not encouraging anyone to do it. The skill itself has a warning about this. It also doesn't beat detectors like GPTZero, which read token probabilities and never look at style.

Using AI to end up with a better-written text is a good thing, though. It's very good at catching the mistakes and habits we all have. It works best on text you wrote yourself and want to polish, or text written with AI help that still has real human input in it. And for that project documentation nobody will write by hand, it should at least be easy to read when you need to get familiar with a concept or an internal workflow at the company.

When to use something else

humanizer and stop-slop both do their job well, and I don't want to take credit away from them. If you want something lightweight, stop-slop is a short set of rules you can even paste into your custom instructions. humanizer has a very complete pattern list and a draft, audit and rewrite flow. Quirón makes more sense when you want a script to verify the result instead of the model grading itself, when you want to catch overshoot, or when you write in Spanish. I think it covers what they do and goes further, but try them and judge for yourself.

On languages: it's tuned for English and Spanish, the two I speak (English barely, I'm still working on it). It also works in other languages and identifies the structural patterns, but the best results are in those two. If you speak something else, try it and tell me how it went. Contributions for new languages are welcome.

Don't take my word for any of this. Run it on your own documentation and look at the measurements. The README was written with its help, so it's a quick way to see how it reads, and the install steps are there too.

ilien-dev / quiron

AI humanizer skill for Claude Code, Codex and Cursor. Removes AI slop and the signs of AI writing, then measures the rewrite against human baselines.

English · Español

Quirón: an AI humanizer skill that measures its own work

An agent skill for Claude Code, Codex and Cursor. It strips the AI slop that marks prose as machine-written,
then checks the result against measured human writing instead of a hunch.

Hand it a draft and ask it to humanize the text, or to make a README sound less like ChatGPT. It rewrites the prose, then measures the result. You get the rewrite and a measurement that says whether it now reads like a person wrote it.

Install

With the skills CLI, for Claude Code and every other agent it supports, Gemini CLI and GitHub Copilot among them:

npx skills add ilien-dev/quiron

It needs no API key. It runs on the model you already use, and the scripts need nothing beyond the Python 3 standard library.

As a Claude Code plugin

Run these two commands inside Claude…

View on GitHub

How are you dealing with AI-generated documentation in your team? And if you try it, I'd like to know what it gets wrong.

A 200 OK is not an article: the bug that made me write my own web layer in Rust

ilien — Tue, 22 Sep 2026 17:37:02 +0000

There's a failure mode in agent tooling that never throws anything and I lost an afternoon to it before I understood what I was looking at. The fetch returns 200 and the body isn't empty and the extractor finds text in that body and turns the text into clean Markdown. Then the model reads my clean Markdown and writes me a fluent summary that happens to be entirely wrong.

The page was never the article. The page was the wall that says "Checking your browser before you continue".

Every layer did its job, and no layer had the job of asking whether the page that arrived was the page I had asked for.

That bug is why I spent the last stretch of my free time writing Svipall, a local-first web layer for AI agents, in Rust. Below are the four things it does about it, with what I measured for each, including the measurements that didn't come out in my favour.

1. Nothing in the stack separates "the call worked" from "the page arrived"

A retry won't help here because a retry is the same request, and escalating to a headless browser won't help either if nothing tells you that escalating is the thing this particular page needs. The only fix I found is that whatever fetched the page has to say what it thinks it got back, and that verdict has to travel with the page itself.

So every fetch returns one, and a blocked page carries the evidence that produced it:

{
  "status": 200,
  "blocked_reason": "vendor challenge",
  "wall_kind": "vendor",
  "wall_vendor": "kpsdk.io",
  "wall_evidence": "header x-kpsdk-ct",
  "note": "Interstitial detected. A browser tier can run its script; a bare HTTP request cannot."
}

Twelve wall kinds, each one naming the move it implies. The field I care most about is wall_evidence because it says why the verdict came out this way and gives you something to disagree with. If you can't audit the verdict you're back to trusting the verdict blindly and trusting it blindly is where my whole problem started.

The honest caveat, which lives in the README too: the classification is heuristic, and a clean verdict doesn't prove that the records you wanted arrived intact. What it does is move the failure from silent to visible, and that's the whole claim I'm making for it.

When a page doesn't arrive, escalating is the obvious move, but escalating on every fetch is how you turn a 200 ms fetch into a six-second fetch, forever:

  http      emulated Chrome TLS + HTTP/2, no browser      ~200 ms
    │       most pages stop here
    ▼
  browser   headless Chromium, runs the page's JS
    │
    ▼
  stealth   automation surfaces patched to match the identity
    │
    ▼
  real      visible-but-offscreen browser, persistent profile,
    │       pointer along curves, wheel scrolling
    ▼
  warm      bounded wait, captcha strategy loop runs inside it

I measured it from a single residential address with no proxy and took the median of three runs with the range: 26/31 on a public target list I didn't write, 7/12 on my own list of hard targets, 3/8 against four named commercial vendors.

Three out of eight. That row stays in my README because a comparison table where every cell is green tells you more about the author than it does about the software. My raw logs are committed alongside it and they include the rounds of work that improved nothing and the rounds where a number went down.

On doing this responsibly

This part isn't boilerplate, so I haven't put it at the bottom. Svipall evades anti-bot fingerprinting and that is all it does. It does not defeat authentication, it does not open paywalled content you haven't paid for and there is no cloud solver farm behind it. I wrote it for research and the job I wrote it for is reading pages a browser would happily show you, from a tool that isn't a browser, without the fetch failing silently.

Being able to reach a system doesn't mean you're allowed to. You pick the addresses and you pick how hard to push and that puts the terms of service and the copyright and the data-protection law on you. The repo ships a DISCLAIMER that says so at length. robots.txt handling is warn by default and obey on request. The crawler stops at whatever budget you set it: pages, tokens, traffic. If you point it at a hundred thousand pages just because you can, that one's on you.

2. The agent shouldn't have to rediscover the route every time

I underestimated this one badly while I was building it. An agent that finds the right way into a site and then forgets that way has learned nothing at all, so tomorrow the agent climbs the same ladder again: same seconds burned, same reputation spent with the same site, same answer at the end of it.

So the route is remembered per domain, and the route survives the session. Two supporting observations can promote a working tier, and the next visit then starts there instead of at the bottom. Cooldowns are stored the same way, and so is per-exit health, and so are the walls a site is known to serve. svipall status prints the lot of it.

The same memory runs deeper than the tier. Captcha strategies are ordered by what actually worked on that route, so the loop tries the winner first and a strategy that declines costs no attempt. A schema you name is fingerprinted per domain, and when the site gets redesigned the selector is relocated by similarity and comes back marked healed. Cookies from a web_login live in a profile you can export. web_notes is key-value memory that outlives the session, for whatever the agent worked out that the tool doesn't model.

The effect on an agent loop is fewer steps, and fewer steps is the same thing as fewer tokens. In a paired run, on the 109 pairs where both arms returned useful content, the automatic ladder spent 368 s against native browsing's 735 s. That difference isn't only fast refusals.

3. The tokens

I fetched one page three ways, just now, on this machine. English Wikipedia, Rust (programming language):

What I asked for	Characters	Share of the raw HTML
`extraction: "html"`, the raw markup	1,048,788	100%
default, extracted Markdown	106,266	10.1%
`query: "borrow checker ownership"`	48,486	4.6%

Roughly 262k → 27k → 12k tokens at four characters per token. The character counts are measured; the token figures are the usual estimate and not a tokenizer run.

Ninety per cent of that page was navigation, reference markup and the apparatus Wikipedia wraps around its prose. Every character of that ninety per cent was billable, and every character of it sat between the model and the part that mattered.

Boilerplate removal has a number attached to it: median ROUGE-LSum F1 of 0.920 over the 3,975 gradable pages of the SIGIR-23 gold standard, against 0.732 with the boilerplate removal switched off. And then the row I'd rather not print, which is that readability scores 0.963 on that same corpus and trafilatura 0.958. They beat me. Both of them are excellent and both of them are in my comparison table for exactly that reason.

Where I spend the difference is query=. It keeps only the blocks that lexically match your words using BM25. No embedding model and no API call, so nothing here bills you twice for reading one page. How much it saves depends on the query and not on the page. On two long articles the query "robots.txt" left 6% and 13% of the text. The query "history of scraping" left 88% of it. So the query should name the fact you want.

Then there are the duplicates. I find near-duplicates with SimHash and a banded index, and web_fetch_many reports corroboration, which is how many distinct documents your set actually is, marking each copy with same_text_as. Eight sources that are one press release reprinted eight times aren't eight sources, and an agent has no way to know that unless something says so.

Then there's the plumbing. out_file writes to disk and hands back a path, measured at a 418-character response in place of the 34,746-character page it wrote, and schema: "auto" reads a listing's own repeated structure and returns named columns from one parse, with no model involved.

One rule costs me recall and stays in anyway: hidden text never reaches the model, so anything behind display:none, left:-9999px or aria-hidden gets dropped before extraction. A paragraph parked off-screen reads to an agent exactly like the article does, and that paragraph is the entire prompt-injection surface. There are 123 phrases a human annotator marked as real content sitting behind that rule.

4. Nobody should have to count how many times they've hit a site

A hosted scraper rotates through a pool of addresses, so the question of how much one address has asked a host never comes up. Run the thing locally and your home connection is the entire pool. An agent in a loop has no idea how many calls it has already made against a domain this afternoon, and neither do you, and the site absolutely does.

I learned this from my own benchmark. I ran the target lists against one residential address several times in a day, and a cell that had been passing stopped passing. Nothing in the tool had changed. I had simply spent the address.

So there's a ledger now. Every visit costs what its tier costs, doubled when the page comes back walled:

`http`	`browser`	`stealth`	`real`	`warm`
1	3	4	8	12

A count of visits would be the wrong unit. An HTTP GET and a headful browser sitting through a twenty-second challenge are not the same event to a host that scores addresses. The budget is 250 by default and it decays with a six-hour half-life instead of resetting at midnight, which makes it a rate and not a daily allowance: a steady spend settles at about 29 points an hour.

Under 70% of the budget nothing happens. Between 70% and 100% the pacer stretches the gap between requests, up to four times. Over it, the fetch is declined before a packet leaves the machine, with blocked_reason: "address_budget", the number of seconds until it isn't, and the way out.

The part I'd defend hardest: your own address is a key in that ledger like any other, which is the whole point, because the case that broke my benchmark had no proxy involved at all. Pacing is keyed by (domain, exit) too, so the gap comes from the host's own latency and refusals instead of a global constant: 100 ms to 2 s on http, 400 ms to 5 s on the browser tiers.

None of this makes a site trust you. It stops your agent from spending goodwill it doesn't know it has.

What it is, and what else already exists

It's a single Rust binary that speaks MCP (29 tools) for Claude Code, Claude Desktop and Cursor. It works as a CLI and it turns into a local REST API under svipall serve so any language can drive it.

svipall fetch https://docs.example/api --query "rate limits"
svipall fetch https://shop.example/listing --schema auto    # rows from a page you've never seen
svipall crawl https://docs.example/ --pages 50 --out pages.csv
svipall search "rust async runtime" --engine all            # no API key

There's nothing to install underneath it and nothing to sign up for: no Node, no Python, no API key, no telemetry. Captchas get attempted locally across 15 widget families and 11 answer modalities, and when none of that works the page parks in a dashboard at localhost:8787/human so a person can answer it once. There's no paid solver in the loop and no path where your pages reach my server, since I don't run one.

I'm not going to pretend the field is empty. Firecrawl is the hosted API you can call from a lambda. If you live in Python, Crawl4AI is mature and ships a Docker server. Scrapling does adaptive parsing with session and proxy control. For plain browser automation over MCP the reference answer is still Playwright MCP. All four are in the repo's comparison table, and if you want a URL you can hit from a serverless function, use a hosted service.

What Svipall adds is a combination I couldn't find anywhere in one place. The fetch tells you whether the page arrived, the route to that page is something the agent learns once, and the tokens get cut during extraction instead of after it. All of that runs on hardware you own. That comparison in the repo describes documented scope on a stated date. It is not a head-to-head benchmark, so validate your own target pages before you switch anything.

My receipts live in the proof page, each one with the command that reproduces it: 1,216 tests, 160/160 automation-tell probes clean over five browser passes, 8/8 identity coherence checks, and a delivery snapshot of 348/459 calls (75.82%) over 48 URLs, unattended.

curl -fsSL https://raw.githubusercontent.com/ilien-dev/svipall/main/install.sh | sh

AGPL-3.0, extraction engine MIT/Apache-2.0 so anything can depend on it.

svipall.ilien.dev · source on GitHub · what it can't do

I built this, and I'd like one answer in the comments: how does your agent currently find out that a fetch returned a wall instead of a page? Every answer I've gotten so far is some version of "it doesn't, I noticed later", and if that's the state of the art, the silent 200 is a bigger hole in agent tooling than the scraping part anyone argues about.