▲ 2 r/bestaihumanizers+2 crossposts

I counted 16 things in ~100 blog posts to find out what actually makes writing read as AI-written

I built a Claude Code skill that scores how human a draft reads and drives the fix loop. It's free, MIT, no signup and no paid tier, and there's a one-command way to try it below without installing anything.

Here's what it does and where the numbers came from.

Two piles of blog posts. 36 written by people, published before LLMs were common. 45 generated, same topics. Then I counted 16 things in every one of them: paragraph lengths, sentence lengths, how often the writer says "we", contractions, em-dashes, how many specific things get named. Also every "AI tell" people put in their prompts, so hedging words, "moreover", "robust", "seamless".

Then compare the two piles, count by count, and keep only the ones that actually come apart.

Almost none of the word stuff survived. Hedging words landed on a coin flip, and the humans used them more than the AI did. "Moreover" was rare in both piles. "Robust" went in no particular direction. Every wordlist I'd been pasting into CLAUDE.md was doing nothing.

What came apart cleanly was shape. Paragraph length variance was 28.6 for people and 12.8 for the AI, so we write a long paragraph, then a short one, then a one-liner, and it writes the same size block forever. First person was 8.18 per thousand words for people and exactly 0.00 across all 45 generated posts. It never says "we".

Those counts became the ranges. Ask Claude Code to humanize or audit a draft, the skill loads itself, scores the draft, tells Claude which single count is furthest off, fixes that one thing, then counts again. Four passes max, then it stops instead of rewriting forever.

Claude Code did most of the building. I ran the counting functions over both piles with it, argued with it about which thresholds were guessed rather than measured, and it caught a version where every count had to be in range — which passed 0% of both piles. The whole calibration write-up came out of that back and forth.

Free to try, two ways. Nothing to sign up for. Clone and score a file directly:

git clone https://github.com/SadhvikChirunomula/measured-humanizer
node measured-humanizer/skills/measured-humanizer/gate/style_gate.js YOUR_DRAFT.md --brief

Or install it as a plugin:

/plugin marketplace add SadhvikChirunomula/measured-humanizer
/plugin install measured-humanizer@measured-humanizer

Node 14+ is the only requirement, and there are no dependencies.

Not a detector bypass. 75% of human posts pass and 11% of generated ones slip through, so

https://github.com/SadhvikChirunomula/measured-humanizer

reddit.com
u/Sadhvik1998 — 14 days ago
▲ 1 r/DuckDB+1 crossposts

Big data exist cuz hardware was small in the past. With the new hardware, do we still need Distributed Computing?

I did some research on the big data myth. Started with the MotherDuck blog, which says 'Big Data is Dead.' By looking at it, I felt, "Oh, really?" then, I did some research to understand 'BIG DATA.' After almost 100 hours of research, I personally felt, 'Is distributed Computing even still needed?'

Big data evolved because at that time, the late 1990s and early 2000s, the machines were small and the hardware was small (literally the largest storage hardware was ~200GB at that time). So it was difficult to store and process the data in a single machine, which led to a distributed computing and Storage Ecosystem. But today, we have clouds offering ~32TB Disk and ~1TB RAM and ~144 vCPUs. That means more than 90% of data workloads can fit in a single box.

So are we still following the principles of distributed computing (spark, hadoop) even when the hardware today is ready to handle almost all of your data needs in a single box? Do we need to stop, think and redesign existing pipelines to a single node architecture from a cluster mode architecture? It made me re-think the reality of hardware. Moore's Law is real, and we see that growth of hardware has exponentially increased.

I have put all my understanding into a paper and published it on medium. Hope it helps. Maybe it is time for us to rethink new hardware and redesign the pipelines. This not only saves cost but also improves the performance because the I/O gets low, and everything is packed into a single VM, and using the cache enhances the joins. What do u think?

reddit.com
u/Sadhvik1998 — 1 month ago

Databricks DBU pricing is getting insane—Photon misconfiguration in a small POC caused a 5-digit cloud bill

One of our dev teams in the POC was doing some runs using Job Compute, and we suddenly saw a spike in the cloud cost usage, and our cloud-finance team reported this.

https://preview.redd.it/2harsa74nu3h1.png?width=705&format=png&auto=webp&s=dc55f864a4a7ebe420a3586619f67ede40ffc164

Two things to note here.

  1. Databricks by default has now enabled the photon option in Databricks, which the dev didnot see cuz it was not like that earlier, due to which the instances ran with Photon

  2. The cost clearly (from the image above) shows that the DBU pricing (48,805 INR) is literally more than 2x compared with the Azure Compute (23,000 INR) pricing.

It looks like the Databricks License is getting extremely high day by day, and I don't know how enterprises are paying such a heavy price. Just for a POC, with a small misconfiguration, we hit a number in 5 digits, and looking at a real-world scenario, how big are amounts being charged for DBU.

It feels like it is better to switch to a Databricks alternative; maybe look at a Flat License based on Tiers or some alternative spark data platform.

reddit.com
u/Sadhvik1998 — 3 months ago