Deslop: Oxlint rules that flag AI-written TypeScript patterns

ai-deslop is an open-source package of lint rules for Oxlint, the JavaScript and TypeScript linter, built to reject code patterns its author associates with AI-generated output. Its author, posting as maharshi365, introduced it as a Show HN on 13 October 2026. It had 32 points and eight comments when fetched. The package.json on the main branch lists version 0.4.8 and the licence is MIT. Everything below is the README and the thread, not an independent test.

What the rules cover

The README says the recommended configuration enables every rule not marked opt-in. By its tables that is 21 rules under the deslop namespace, in three groups:

• Type safety and evidence (12 rules): rejects nested `as` assertions, `unknown` or `object` on function inputs, `unknown` return types, type aliases that only rename another type, and non-const assertions without a comment justifying the invariant.
• Code quality (5 rules): rejects adjacent eager array filter and map passes, copying the accumulator inside reducers, and global `Reflect.apply` and `Reflect.get`.
• Tests (4 rules): flags tests whose assertions only check that a mock was called, module mocking in Vitest and Jest, and tests that only check a constant string contains substrings.

Five further rules are opt-in, including exact duplicate type contracts, duplicate all-caps constants across files and Tailwind CSS v4 class spelling. The README also turns on five standard rules, such as no floating promises, which need type-aware linting.

Setup and provenance

It installs from npm as a dev dependency and loads as an Oxlint JavaScript plugin. The README credits the generic rules to dmmulroy/anti-slop, vendored verbatim under MIT. The author wrote in the thread that the additions are a few of their own rules, the Tailwind and duplicate-type checks, and packaging as a dependency rather than an installed agent skill.

What commenters said

SSchick, who said their project recently moved heavily to AI-assisted feature work, wrote that without a defensive lint configuration and test coverage near 80% most of that work would be close to impossible, and that they would adopt the Reflect.get rule because Claude uses it often. Another commenter, navs, said Oxlint and ast-grep rules had become a necessity for any LLM code generation in their workflow. A third, tmsh, asked what it adds beyond anti-slop; the author's reply is the list above.

What a team can take from it

The useful idea is that you can encode what reviewers keep correcting in AI-written code as rules that fail the build, instead of repeating it in review comments. Unknown: how often these rules fire on real code, and how many hits are false positives. Run it on one repository in warning mode, count the hits for a sprint, then decide which rules to make blocking.