DEV Community: Ashwin Sathian

Why "Humanize My Writing" Tools Don't Work

Ashwin Sathian — Tue, 18 Aug 2026 07:08:47 +0000

In December 2024, Florida State University linguists Tom Juzek and Zina Ward set out to answer a question that had turned into a running joke among people who read a lot of AI output: why does ChatGPT say "delve" so much?

Instead of guessing, they built a study designed to eliminate the wrong explanations first, a philosophy-of-science-style method for ruling out competing hypotheses one at a time. First candidate: maybe these words are just common in whatever text the models were trained on. Ruled out. Second candidate: something about the model architecture, or the mechanics of how the model picks its next word. Also ruled out. What was left, after comparing a base version of Llama 2 against the same model fine-tuned with human feedback, was the fine-tuning stage itself. Somewhere in the process of humans rating model outputs as good or bad, "delve" started winning.

That's not a fringe result. A separate team led by Dmitry Kobak at the University of Tübingen ran the numbers on over 15 million PubMed abstracts published between 2010 and 2024, borrowing a statistical method from epidemiology, "excess mortality," repurposed as "excess vocabulary," to separate ordinary word-frequency drift from something anomalous. "Delve" wasn't the only word that spiked. "Meticulously" rose 137% year over year. "Intricate," 117%. "Commendable," 83%. By their estimate, at least 13.5% of 2024 biomedical abstracts show signs of LLM involvement, a bigger vocabulary shift than the one COVID caused. Kobak's study measures the size of that shift. The fine-tuning explanation for why it happens is still just the FSU team's own finding, unreplicated so far.

Here's the part almost nobody mentions when they cite that finding: it's already going stale. A follow-up study from the same FSU team found "delve," "boast," and "meticulous" showing up more often in ordinary spoken language too, in podcasts and YouTube talks. People who read a lot of AI text are picking up its vocabulary and using it themselves. The tell is bleeding into the population it was supposed to detect.

The word-list trap

This is the problem with almost every "humanize my writing" tool currently on GitHub, even the well-built ones: underneath whatever nuance they add, they're still built around a list of words. I went looking, expecting a handful of thoughtful tools and a pile of junk. What I found instead was a spectrum of care applied to the same underlying mechanism.

The most-starred tool in the space has over 36,000 stars, a number worth eyeing with some skepticism given it's a single markdown file. It does real work: protecting ordinary formal vocabulary from being flagged, refusing to invent facts during a rewrite, matching a user's own writing sample instead of forcing one house style on everyone. None of that changes what it's actually doing underneath, which is checking a passage against roughly three dozen fixed patterns, a heuristic that goes stale the moment models or detectors shift. A second tool opens by citing real false-positive research on AI detectors before giving a single rule, and states outright that its signals are "worth acting on; not worth ruining someone's day over," arguably the most epistemically honest framing in the entire space. Strip away that framing, though, and the bulk of what's left is the same genre of banned-word list as everything else.

Then there's the tool at the other end of the spectrum, the one that instructs its model to treat certain words as an instant, unqualified tell: "if even one of these words appears, the text immediately flags as machine-written." Its banned list includes robust, scalable, integrated, proactive, words that show up constantly in ordinary technical writing because they're often the correct word for the job. Strike "robust" from a paragraph about fault tolerance and the paragraph just gets vaguer. No single word carries that much diagnostic weight on its own.

Even the more careful tools slip into the same trap. One enforces a rule capping em dashes at "Maximum ONE per 500 words," with no stated methodology behind the number anywhere in its documentation, and separately instructs its model to apply all its rules silently, never mentioning them to the person it's writing for. That's a strange thing to optimize for if the goal is writing that's actually good. Being undetected is a different achievement.

Word lists share the same fragility no matter how carefully they're built: cheap to build, fast to go stale, and aimed at the weakest part of the signal.

What the stronger signal actually looks like

Separately from all of this vocabulary-chasing, there's a body of peer-reviewed computational linguistics research quietly measuring sentence shape instead of word choice.

A 2024 study out of the Universidade da Coruña compared six sets of LLM-generated news text (Mistral, Falcon, and LLaMA at four different sizes) against real human-written news articles, chosen specifically from after the models' training cutoffs so nothing in the comparison could have been memorized. Human writing spread its sentence lengths across a wide range, some short, some long, unevenly. Every model, regardless of which one wrote the piece, clustered tightly into a narrow 10-to-30-token band. That gap between human and machine was larger than the differences between the six models themselves. Whatever "sounds like Mistral" and whatever "sounds like LLaMA" turned out to have more in common with each other, structurally, than either has with an actual human sentence.

A separate PNAS study found the same convergence in the shape of entire stories instead of sentences: LLM-generated narratives cluster around a much smaller set of recurring plot patterns than human-written ones do, even across different prompts. Same convergence, different scale, still nothing to do with vocabulary.

This is the inconvenient part for anyone building a "humanizer" out of a word list: structure is a harder problem to fake your way around, and it's also the more durable signal, because it isn't tied to which specific words happen to be fashionable in this quarter's training data. A model can stop saying "delve" tomorrow. Rewriting the shape of its sentences is a different kind of problem.

The em dash isn't the story people think it is

If there's one tell that's achieved genuine cultural traction outside of NLP circles, it's the em dash. NPR ran a piece on "the unofficial movement to save the em dash" from guilt by association. A Rochester Institute of Technology student paper cited GPT-4.1 using the mark at roughly 3.28 times the rate of typical human essays.

What's less settled, and this is where the sources genuinely disagree, is whether that overuse even means what people assume it means, let alone why it happens. One independent analysis argues it's a training-data artifact: labs eventually ran out of fresh web text and started digitizing older, pre-1950s books, which use em dashes far more heavily than contemporary writing, and GPT-3.5, trained before this shift, didn't show the same overuse that GPT-4o does. A competing explanation points the other direction: human raters, during the reinforcement-learning stage that shapes a model's final behavior, reward the clarity and pacing an em dash provides, and that preference gets baked in regardless of what the training data looked like.

Benjamin Dreyer, Random House's longtime copy chief and about as credentialed a human authority on English prose as exists, doesn't think the overuse claim itself holds up. He went looking for the "charts and graphs and proofs" behind the em-dash panic and found none. Examining sample AI prose by hand, he called the whole thing "social media blather" and found nothing anomalous in the counts. What worries him more is the chilling effect: students spooked into avoiding a perfectly good punctuation mark for fear of being falsely flagged, paying a real cost for a signal that was never trustworthy on its own to begin with.

What the source of all this actually said

At least 6 of the 13 tools I looked at trace their DNA back to one place: Wikipedia's "Signs of AI writing" essay, maintained by volunteer editors who patrol new submissions for undisclosed AI content. It's genuinely excellent applied research. Built from thousands of real cases and revised as models change, it's more rigorous than most of what's built on top of it.

It also contains a warning that hardly anyone who cites it seems to have read past: its own verdict on the tells it catalogs is that they're surface symptoms of something worse underneath, unreliable sourcing, shallow synthesis, no real editorial judgment. Scrub the vocabulary without touching any of that and you've, in the essay's own words, "obscured the actual concerns." A find-and-replace pass that swaps "delve" for something else and caps the em dashes gets past the pattern-matching. It never produces text anyone actually thought through.

That's the harder problem, and it's the one worth building for. We ended up doing exactly that: research on 27 cross-referenced tells, ranked by source strength and how often each one actually shows up, plus a teardown of what the tools above get wrong, that became a Claude Code skill built around structure and specificity first, with the vocabulary list demoted to a backup role instead of the primary mechanism. It's not foolproof, and it'll date the same way every tell-based approach eventually does. It's on GitHub if you want to check the sourcing yourself: github.com/AshwinSathian/humanize-writing-skill.

Why Better Auth's MongoDB adapter can't populate() a Mongoose ref

Ashwin Sathian — Mon, 17 Aug 2026 19:48:36 +0000

If your Node app already uses Mongoose and you wire up Better Auth with its official MongoDB adapter, this looks fine at first:

import { betterAuth } from "better-auth";
import { mongodbAdapter } from "better-auth/adapters/mongodb";
import mongoose from "mongoose";

const client = mongoose.connection.getClient();

export const auth = betterAuth({
  database: mongodbAdapter(client.db()),
});

Then you try to reference a Better-Auth-created user from your own model:

const Post = mongoose.model(
  "Post",
  new Schema({
    title: String,
    author: { type: Schema.Types.ObjectId, ref: "user" },
  }),
);

const post = await Post.findOne({ title: "..." }).populate("author");

post.author; // null

populate() silently fails. Not an error — just null, like the ref never resolved. If you've hit this, you're not doing anything wrong.

Why it happens

mongodbAdapter() talks to the raw mongodb driver, not Mongoose. It never registers a Mongoose model for user, session, account, or any of Better Auth's own tables. Two consequences fall out of that:

You end up with two disconnected views of the same database. Better Auth writes through MongoClient directly. Your own code reads and writes through Mongoose. No shared schema, no shared validation, no shared hooks between the two.
The _id types don't line up. Better Auth's default ID generator produces a 32-character base62 string — not a real ObjectId. Mongoose's populate() needs a real ObjectId to resolve a ref against. There's nothing valid on the other end.

This isn't a one-off — it's been an open, documented gap on Better Auth's own repo since February 2025:

better-auth#1492 — forced to install the raw mongodb package as a duplicate dependency, even in apps that only ever use Mongoose.
better-auth#6289 — id/session mismatches from mixing Mongoose reads with raw-driver writes on the same collections.
better-auth discussion #9364 and #1921 — people hitting exactly this populate() failure and asking for a real Mongoose adapter.

The workaround everyone lands on — mongoose.connection.getClient(), hand the raw client to mongodbAdapter() — only fixes where Better Auth connects. It doesn't fix what it stores. Your ref field still has nothing valid to resolve against.

The actual fix

better-auth-mongoose registers Better Auth's tables as real, extendable Mongoose models on a connection you already own, and overrides ID generation to produce real 24-character ObjectId hex strings instead of Better Auth's default base62 IDs — converting between ObjectId and string at the boundary so Better Auth's own core still sees plain strings, but MongoDB stores actual ObjectIds underneath.

import { betterAuth } from "better-auth";
import { mongooseAdapter } from "better-auth-mongoose";
import mongoose, { Schema } from "mongoose";

await mongoose.connect(process.env.MONGO_URI!);

export const auth = betterAuth({
  database: mongooseAdapter(mongoose.connection),
});

Same Post model, same .populate("author") call, no workaround:

const Post = mongoose.model(
  "Post",
  new Schema({
    title: String,
    author: { type: Schema.Types.ObjectId, ref: "user", required: true },
  }),
);

const post = await Post.findOne({ title: "..." }).populate("author").lean().exec();

post.author.email; // resolved

This is a real, CI-run test in the repo, not a claim in a README:

describe("the differentiator: a consumer's own model can .populate() a Better-Auth-created user", () => {
  it("resolves Post.author via .populate() after Better Auth creates the user", async () => {
    const auth = betterAuth({ database: mongooseAdapter(connection) });

    const { user } = await auth.api.signUpEmail({
      body: { email: "author@example.com", password: "correct-horse-battery-staple", name: "Post Author" },
    });

    await Post.create({ title: "Hello, populate()", author: coerceToObjectId(user.id) });

    const post = await Post.findOne({ title: "Hello, populate()" }).populate("author").lean().exec();

    expect(post.author.email).toBe("author@example.com"); // passes
  });
});

It also passes the official @better-auth/test-utils adapter contract suite, so it's not just "populate works" — it's a fully conformant Better Auth adapter.

What else comes with it

Zero direct dependencies. mongoose and better-auth are peers you already have; the raw mongodb driver is never pulled in.
Schema extension that doesn't fight Better Auth. schemas: { user: new Schema({ role: { type: String, default: "member" } }) } merges your fields in without letting a required Better Auth field get accidentally loosened.
Transactions on by default, using real Mongoose sessions, with automatic fallback to non-transactional writes on a standalone mongod (common in local dev) instead of crashing on boot.
Adapter-level joins. Better Auth 1.4+ can push joins down to the adapter for a documented 2–3x latency improvement on endpoints like get-session. This adapter turns that straight into .populate() calls — flip experimental: { joins: true } and it's already wired up.
If you're on NestJS: examples/nestjs-mongoose is a complete app built on @thallesp/nestjs-better-auth, exercised over real HTTP in CI on every push.
If you're building multi-tenant SaaS on top of Better Auth's organization plugin, there's a companion package, better-auth-mongoose-tenant, for automatic tenant-scoped queries on your own models.

pnpm add better-auth-mongoose mongoose better-auth

better-auth-mongoose.ashwinsathian.com has the full writeup, a compatibility matrix (Mongoose 6–9, Better Auth 1.4–1.6), and more recipes. Repo's at github.com/AshwinSathian/better-auth-mongoose — MIT licensed, not affiliated with the Better Auth team, built because this gap has sat open for a year and a half.

Why ngx-runtime-i18n treats the active language as a signal, not an Observable

Ashwin Sathian — Mon, 17 Aug 2026 15:49:34 +0000

The idea of building @ngx-runtime-i18n came from my personal experience and if I may daresay frustration at the popular options when it came to internationalisation in Angular app. Particularly in applications of scale especially at an enterprise level, it was no picnic. Among many others, one critical decision point was regarding the usage of signals which clearly was the road ahead and yet, even as we speak, not the standard for the community at large.

Most Angular i18n libraries predate signals. ngx-translate and transloco both started as RxJS-first services, and both have spent the last year retrofitting signal support on top: transloco added translateSignal by wrapping toObservable() around its existing pipeline (jsverse/transloco#781 is the tracking issue - still open, with a maintainer confirming a signals-native rewrite is in progress); ngx-translate went further in its v18 rewrite and made signals the primary API. Angular's own built-in i18n never solved this because it isn't runtime at all but a compile step that produces one build per locale, with no way to switch languages
without a page reload, which also means that local development is no party either.

I wanted the opposite starting point: build the service on signals from day one, and treat RxJS as an optional bridge for people who still need it, not the other way round. That's @ngx-runtime-i18n/angular. I18nService exposes lang(), ready(), and switching() as signals directly; t$() is a computed signal that recomputes when the language or the parameters change; there's no toSignal(this.service.stream$) anywhere in the implementation. If you do need Observables where your codebase uses existing NgRx effects, older RxJS-based code, the I18nCompatService wraps the same state as lang$/ready$ instead of the other way round.

The other piece I didn't want to compromise on was ICU. A lot of runtime i18n libraries handle "1 item" / "2 items" and stop there, which works for English and fails for Arabic (six plural forms), Polish, or Russian. formatIcu() implements plural, select, and selectordinal against the actual CLDR plural categories (zero/one/two/few/many/other), so a translator can write correct plural rules for their language instead of the library silently falling back to English-shaped logic.

SSR was the third constraint. provideRuntimeI18nSsr() seeds the resolved catalog into Angular's TransferState on the server, so the client picks up exactly what was rendered instead of re-fetching and re-resolving the language after hydration - no flash of the wrong language, no mismatch warnings.

None of this is finished in the sense that the library is done growing. It's six packages now (core, angular, primeng, material, schematics, cli), all on npm as of v2.1.0, with real but small usage so far. The parts I'd like feedback on most: route-scoped catalog loading (loadScope()/unloadScope()) for large apps with many feature modules, and whether the fallback-chain API (fallbacks: string[] on top of defaultLang) covers the cases people actually hit in multi-region products.

Repo: https://github.com/AshwinSathian/ngx-runtime-i18n
npm: https://www.npmjs.com/package/@ngx-runtime-i18n/angular
Docs: https://i18n.ashwinsathian.com/

Announcing @ngx-runtime-i18n v1.2.0 — Runtime i18n Done Right for Angular 16+

Ashwin Sathian — Fri, 14 Nov 2025 08:03:11 +0000

@ngx-runtime-i18n is a modern, runtime-driven internationalisation system designed for the current Angular ecosystem — signals, SSR, hydration, and streamed rendering.

The new v1.2.0 release brings three major improvements that close long-standing gaps in the Angular i18n landscape:

1. Ordered Fallback Chains

Missing keys now resolve across a full chain:
active → fallbacks[] → defaultLang

This removes an entire class of runtime failures and enables cleaner catalog organisation.

2. Catalog Caching Modes

Select the caching strategy for your app:

none: minimal memory footprint
memory: session-level caching
storage: hydrate translations directly from localStorage (with background verification)

Perfect for PWAs, offline-first apps, and SSR setups.

3. Developer Experience Helpers

New introspection methods:

getCurrentLang()
getLoadedLangs()
hasKey()

These are especially useful during SSR, logging, and debugging dynamic or user-driven catalog loads.

The SSR demo app now reflects these features, and all documentation has been updated.

If you're using Angular 16 or above and want to modernise your i18n strategy, give it a try.

Runtime i18n for Angular — Signals-first, SSR-safe, and ~3 kB gzipped

Ashwin Sathian — Mon, 27 Oct 2025 07:11:58 +0000

TL;DR

Angular finally gets a runtime internationalisation (i18n) library that’s:

Signals-first with an RxJS fallback
Hydration-safe for SSR
~3 kB gzipped
Works from Angular 16 → 20
And takes 2 lines to set up


bash
npm i @ngx-runtime-i18n/angular @ngx-runtime-i18n/core