Deslop: Using Oxlint Rules to Clean Up AI-Generated TypeScript Code

AI writing code is becoming increasingly common, but the accompanying "code slop" problem is also gradually surfacing. In the Show HN section of Hacker News, a project called "Deslop" attempts to address this growing pain point with Oxlint rules—specifically targeting quality control for AI-generated TypeScript code.

The "Slop" Dilemma of AI-Generated Code

"Slop" is a term that has become popular in AI circles in recent years, broadly referring to low-quality content mass-produced by large language models. When it spreads to the code domain, the problem becomes more concrete: AI-generated TypeScript code often looks impeccable on the surface—syntactically correct, fully typed—but hides "machine habits" that human programmers would never develop. Typical symptoms of this kind of code include redundant type assertions, excessive defensive checks, mechanical naming patterns, and large amounts of "looks useful but actually superfluous" fallback logic.

The difference between humans and AI writing code isn't whether they make mistakes, but how they make them. Humans tend to omit checks they assume are safe, while AI tends to add redundancies it assumes are thorough. Deslop's approach cuts in precisely from this difference.

Type Assertions and Defensive Checks

In TypeScript, type assertions (the as syntax) are a means of forcibly telling the compiler "I know the type of this value," bypassing type checking, and are therefore regarded by the community as a "last resort." AI-generated code often abuses as, such as asserting any as a concrete type, or directly asserting where a type guard could clearly narrow the type, which causes the type system to lose its protective effect. Defensive checks refer to heavily adding logic like if (x == null), try-catch, and default value fallbacks throughout the code. Reasonable defense can improve robustness, but AI often repeatedly checks the same condition at unnecessary levels, or adds null protection for variables that can never be null, leading to code bloat and reduced readability. Deslop aims to capture exactly these "syntactically correct but semantically redundant" patterns.

What Deslop Does

Deslop is essentially a set of lint rules customized for Oxlint, with a very clear goal: to catch common anti-patterns in AI-generated TypeScript code. Oxlint is a JavaScript/TypeScript linter written in Rust, launched by the Oxc project, and is far faster than ESLint. Deslop builds a layer of "anti-AI-smell" checking logic on top of it.

Choosing Oxlint rather than ESLint as the foundation reveals the author's consideration for performance—AI-generated code tends to be large in volume, and the overhead of line-by-line review cannot be ignored. The Rust-driven parsing engine can maintain a smooth experience in large codebases, which is quite critical for AI-assisted development workflows that need to run lint frequently.

Oxlint and the Oxc Project

Oxlint is a static code checking tool launched by the Oxc (The JavaScript Oxidation Compiler) project, with its core written in Rust. Compared with ESLint, its biggest selling point is performance: on large codebases, Oxlint's checking speed is typically dozens of times faster than ESLint, because it doesn't need to go through the layered overhead of the Node.js runtime and JavaScript interpreted execution, but is instead compiled directly into native machine code. Oxlint's rule system is compatible with a large number of existing ESLint rules, while also allowing developers to extend custom rules via plugins or configuration. Deslop leverages this extensibility to layer "anti-AI-smell" checking logic on top of Oxlint in the form of a rule set. Choosing a linter from the Rust ecosystem as the foundation means Deslop can scan large volumes of AI-generally generated code at low overhead, without becoming a performance bottleneck in CI like traditional ESLint.

Why It's Worth Paying Attention To

Currently, the project's popularity on Hacker News isn't very high (4 points, 0 comments), but the problem it touches on is universal. With the spread of tools like Cursor, Claude Code, and GitHub Copilot, the proportion of AI contributions in many projects' codebases is rising rapidly. The challenge teams face has shifted from "whether to use AI to write code" to "how to manage code written by AI."

Traditional linter rules were born from the soil of human coding habits and lack specificity for AI's unique patterns. Deslop represents a new direction for the toolchain: not broadly improving code standards, but precisely identifying AI-generated "fingerprints" and cleaning up the parts that seem reasonable but are actually superfluous.

The Possibilities and Limitations of Such Tools

From a conceptual standpoint, dedicated lint rules for AI code have their rationale. AI does have some predictable output patterns, such as overusing as type assertions, tending to wrap everything in try-catch, and introducing unnecessary abstractions in simple scenarios. These patterns can be caught through static analysis.

But the difficulty lies in drawing boundaries—there's often only a fine line between "safe defensive programming" and "AI-style over-defense." If the rules are too aggressive, they may harm reasonable code styles; if too conservative, they lose the meaning of the tool. Whether Deslop can find this balance point will determine its practical value.

Another question worth pondering: as model capabilities evolve, AI's coding habits are also changing. Today's "AI anti-patterns" may disappear tomorrow, which means such tools need continuous iteration to remain relevant.

Static Analysis and the False-Positive Tradeoff

Static analysis tools discover potential issues without running code by parsing the abstract syntax tree (AST) and building data flows. Its advantages are speed and automation, but the cost is a lack of runtime context, making it prone to false positives. For patterns like "AI-style over-defense," rules need to judge whether a check is "superfluous," and whether something is "superfluous" often depends on business logic and caller conventions, making it difficult to be 100% accurate based on syntax structure alone. Therefore, tools like Deslop typically need to weigh rule strictness against false positive rates: the more aggressive the rules, the more redundancy they can clean up, but the more likely they are to flag safety code that humans deliberately wrote as a problem. In practice, teams often need to adjust rule thresholds in combination with project standards, or even exempt specific directories or files from checking.

Implications for Developers

Regardless of how far Deslop itself can go, the question it raises deserves serious attention from every developer using AI to code. When AI becomes the primary producer of code, what we need isn't just smarter generation tools, but also smarter review tools. Code quality management is evolving from "humans write, humans review" to "AI writes, tools review," and Deslop is an interesting footnote in this evolution.

One-line Summary

Deslop uses an Oxlint rule set to specifically clean up redundant anti-patterns in AI-generated TypeScript code.

Paragraph Summary

Deslop is a lint rule set built on top of Oxlint, specifically identifying "slop" anti-patterns in AI-generated TypeScript code, such as redundant type assertions, excessive defensive checks, mechanical naming, and superfluous fallback logic. It chooses the Rust-driven Oxlint over ESLint to handle scenarios with large volumes of AI-generated code that require frequent checking. The article points out that the difference between human and AI coding isn't whether they make mistakes, but how they make them: humans often omit checks, while AI often adds redundant ones. Deslop attempts to precisely capture this "AI fingerprint," but the core challenge lies in distinguishing reasonable defensive programming from AI-style over-defense. As AI coding tools become widespread, code quality management is evolving from "humans write, humans review" to "AI writes, tools review," and Deslop is an early attempt in this trend.