Why Your Prompts Can't Stop AI Slop
Prompts alone won't save your codebase from AI-generated garbage. AI agents frequently ignore or circumvent the coding standards you painstakingly define in your instructions, allowing low-quality code, or "slop," to slip into your projects. it's easy for agents to disregard prompt rules, introducing inconsistencies and potential issues that undermine code quality.
This slop typically isn't a bug that breaks compilation immediately. instead, it's low-evidence code, like unsafe type casting, that erodes type safety over time. The code compiles just fine, but it creates subtle, hard-to-trace bugs that surface much later, transforming minor oversights into major debugging headaches.
Consider a classic example: you pull data from a JSON API, including a createdAt field that arrives as a string. your AI agent might cast this directly to a Date object, despite JSON having no native Date type. The code compiles without complaint because you've explicitly told TypeScript to trust you. but this creates a ticking time bomb, ready to crash your application the moment anything attempts to perform a Date operation on that string, which remains a string.
A Faster, Harder Gatekeeper for Code
Forget hoping your AI agents will magically follow your coding guidelines. Instead, meet anti-slop: a collection of opinionated rules designed for Oxlint. This linter, written in Rust, boasts incredible speed, running 50 to 100 times faster than ESLint. That kind of performance is crucial for quick feedback loops, letting developers and agents alike see code issues almost instantly.
Unlike the probabilistic nature of prompt engineering, linting is entirely deterministic. It acts as a hard failure, immediately flagging any code patterns your team has explicitly banned. This isn't a suggestion your AI might consider; it's a non-negotiable quality gate, ensuring 'slop' can't sneak into your codebase.
The real power of anti-slop lies in its customization. You don't need to adopt every single rule in the package. Teams can meticulously handpick the specific rules that perfectly align with their existing coding standards, creating a highly customized, automated enforcement mechanism. It’s about building a robust, predictable system for quality, not just throwing more prompts at the problem.
Turning Linter Errors into AI Lessons
The real innovation with anti-slop isn't just its speed; it's the sheer quality of its error messages. Forget the typically cryptic TypeScript output that leaves developers scratching their heads, wondering what went wrong. This linter tells you precisely why your AI-generated code is problematic and, crucially, how to fix it. It offers direct, actionable insights instead of vague complaints.
This descriptive feedback transforms error messages into incredibly "juicy data" for an AI agent. Instead of a simple pass/fail, the linter evolves into a powerful teacher, guiding the agent to understand and repair its own mistakes. This shifts its role significantly from a basic code checker to an intelligent, self-improving feedback loop, saving countless hours of manual debugging.
The agentic workflow becomes remarkably efficient:
- An AI agent produces its initial code.
- anti-slop runs, instantly flagging any issues.
- The agent then parses the detailed error message, which includes specific instructions.
- Finally, the agent repairs the code based on those precise guidelines, resulting in higher-quality output. This iterative process prevents low-evidence patterns from ever reaching production. For a full list of these opinionated rules, check out the GitHub - dmmulroy/anti-slop: Opinionated Oxlint rules for rejecting low-evidence TypeScript and JavaScript patterns repository.
Enjoying this? Get one like it in your inbox each morning.
one email a day · unsubscribe in two clicks · no third-party tracking
From Bad Habits to Bulletproof Code
Implementing anti-slop rules fundamentally shifts your development focus. Instead of reacting to bugs after they manifest, you proactively prevent the low-quality patterns that cause them. This linter catches problematic code at its source, like an unsafe chain type assertion that discards critical type evidence. For example, casting an API response to unknown then User can hide the fact that createdAt might be a string, not a date, introducing a latent bug before it's even compiled.
Beyond prevention, anti-slop formalizes your team’s coding standards. It establishes a machine-readable, enforceable set of rules, saving valuable human review time on common, yet critical, issues. This means you don't need a human to flag things like functions returning unknown or other low-evidence TypeScript patterns. The linter flags these, explaining why they're problematic and how to fix them, such as by parsing untrusted input at its boundary.
Integrate anti-slop into your CI/CD pipeline or a local development loop, and you can systematically 'anti-slop' your entire codebase. This ensures both human and AI contributions consistently meet a higher standard of quality and evidence. AI agents, in particular, learn to produce bulletproof code by correcting against the linter's clear, actionable feedback, creating a truly robust and maintainable system.
Frequently Asked Questions
What is Anti-slop?
Anti-slop is a set of opinionated linting rules for Oxlint, a high-performance JavaScript/TypeScript linter. It's designed to reject low-evidence and low-signal code patterns often produced by AI agents.
How does Anti-slop improve AI-generated code?
It creates a feedback loop. An AI agent generates code, the linter runs and provides highly descriptive errors on why a pattern is bad and how to fix it. The agent then uses this feedback to repair the code, improving quality deterministically.
Is Anti-slop a replacement for ESLint?
Anti-slop provides rules that run on Oxlint, which is a linter that can be used alongside or as a much faster alternative to ESLint. Oxlint is benchmarked at 50-100x faster than ESLint.
What kind of code patterns does Anti-slop catch?
It catches code that might compile but is considered a 'code smell'. Examples include chained type assertions (e.g., as unknown as User), functions with unknown parameters or return types, and other low-evidence patterns that discard type safety.

