aislop CLI targets recurring “AI slop” patterns in code before it reaches production

In my last post I complained — a lot — about product managers and how they made my life hell with vibe code. PS: apologies, manager, if you're reading this — but it's true. Now, I'm not here just to complain. There were a lot of learning opportunities too, like how to handle legacy / vibe code. Because at the end of the day, both are the same: no one knows how they work, but somehow they keep working. Touching them is like defusing a bomb — you never know how your change might cascade and break the core logic. The good news is that vibe code is much simpler than legacy. AI, in all its glory, tries to write perfect-looking code — proper function names, comments, the works — not like legacy code where a single function runs 500 lines, with spaghetti names all over that make no sense and comments that are out of date. And that makes it something I can actually handle. I still don't have a perfect, step-by-step playbook — but I've got pieces. The first one. The cheapest and the oldest one. The one the industry solved decades ago and the whole "AI built my app in a day" crowd somehow forgot exists. A linter. Yes, you heard me right. A linter. ESLint. Most people who've been in this industry already know it. It's the most boring, reliable tool in the box. But in an era where the answer to every problem is "add another AI," it's worth saying out loud why the boring tool still wins. What a linter actually is If you vibe-coded your way into this world, or you're new to web dev in general and have never heard the word "lint", here's the honest version. A linter is a set of rules you add to your repo. It reads your code without running it, checks it against those rules, and flags everything that's broken, sloppy, or about to bite you in production. The detail people get wrong: it's not a grep for bad words. A real linter parses your code into a syntax tree and actually reasons about its structure — what's imported, what's called, what's reachable, what types flow where. That's why a rule like no-unused-vars can tell "you imported this and never used it" apart from "you used this without importing it." It's also why eslint-plugin-unicorn can quietly rewrite array.indexOf(x) !== -1 into array.includes(x) (unicorn/prefer-includes), or flag a new Array(...) call that's going to bite you — without ever executing a single line. Three properties matter: It doesn't run your code. No side effects, no flaky network, no "works on my machine." It's deterministic. Same code in, same result out, every single time. No temperature, no vibes. It costs nothing. No tokens. No API bill. It runs in seconds on a laptop or a CI box. In 2026, that last one is the whole argument. Why this matters more than it used to We have AI to write code. AI to review code. AI to verify code. Agents stacked on agents, each one quietly spending tokens to do something a free tool already did better. And honestly? Most of those agents are re-solving problems that were solved long before "agent" meant what it means today. You do not need a language model to notice that you left a debug log in production (no-console). Or imported a module you never used (unused-imports/no-unused-imports). Or wrote a function nobody calls (knip). Or forgot to await a promise (@typescript-eslint/no-floating-promises). Or made two files import each other in a circle (import/no-cycle). A linter catches every one of those instantly, deterministically, for free — before any AI even wakes up. So before you bolt another agent onto your pipeline, ask the boring question: Does the free, battle-tested tool already do this? Usually it does. Use what already exists. A linter is a Quality Gate This is the real reason linters matter. Whether you're a big company or a freelancer just starting out. A linter is a quality gate. A line in the sand that says: This code does not get in unless it clears the bar. Where I work, we wired this straight into the pull-request flow. A check a PR has to pass before it can merge. Not a suggestion. Not "we'll clean it up later." A hard gate on the merge button. The result was the kind of number that sounds made up until you live it: production issues and bad merges dropped by roughly 80%. Magic? No. Most of our incidents were the same boring handful — an unhandled promise that swallowed an error, a stray debug log left in, a circular import that only broke in prod. The gate caught every one of them at the door — we just stopped letting broken code through. That's the whole trick. A gate doesn't make anyone smarter. It just raises the floor. A tip if you're at a big company: when you introduce the ESLint check, you'll hear a lot of pushback from devs — especially at a startup or midsize company. So be ready for a fight, and roll it out gradually: a warning gate first, then an error gate. It doesn't stop at "missing semicolon" Here's the common misconception people hit when they first add ESLint and see all those errors: "this thing is bad, it just nags me like my annoying brother." That's a huge underestimation. Once you treat the linter as a real gate instead of a nag, you can teach it your specific mistakes. And it never forgets them. Every painful bug in an AI-assisted codebase is also a pattern. And patterns are exactly what static analysis is good at. A surprising amount of this is one config file away. Modern ESLint flat config plus a few community plugins covers most of it: // eslint.config.js — a starter "quality gate", not a missing-semicolon nag import unusedImports from "eslint-plugin-unused-imports"; import importPlugin from "eslint-plugin-import"; import unicorn from "eslint-plugin-unicorn"; export default [ { plugins: { "unused-imports": unusedImports, import: importPlugin, unicorn }, languageOptions: { // type-aware rules need the TS program, not just the syntax tree parserOptions: { projectService: true }, }, rules: { // ~100 perf + hidden-bug rules in one line; downgrade the churny ones ...unicorn.configs["flat/recommended"].rules, "unicorn/filename-case": "off", // Vue files are PascalCase by convention "unicorn/prevent-abbreviations": "off", // trips on `ref`, `props`, store names // dead code the model left behind — auto-fixable "unused-imports/no-unused-imports": "error", "unused-imports/no-unused-vars": "warn", // the silent killer (see the circular-deps post) — crank maxDepth up "import/no-cycle": ["error", { maxDepth: 10, ignoreExternal: true }], // dropped awaits that swallow errors — needs the type info above "@typescript-eslint/no-floating-promises": "error", "@typescript-eslint/no-misused-promises": "error", // dynamic code execution: off by default in eslint:recommended, turn them on "no-eval": "error", "no-implied-eval": "error", "no-new-func": "error", "no-script-url": "error", }, }, ]; That's the floor. On top of it, every time something hurt us, we added a rule so it could only hurt us once. Three of them earned their place the hard way: Circular dependencies — import/no-cycle with maxDepth: 10 (the default of 1 only sees direct A↔B cycles), backed by dependency-cruiser for the whole-graph view. AI refactors love making two modules import each other until the build breaks only in prod. It's the single most common AI-induced bug I've seen — enough that it deserves a post of its own. Dropped awaits — @typescript-eslint/no-floating-promises and no-misused-promises. A missing await on a file or network call silently swallows the error, and you find out when a user does. Needs type-aware linting (parserOptions.projectService) — the one setup cost worth paying. The free-wins pack — eslint-plugin-unicorn's flat/recommended: ~100 rules for one import. A mix of performance wins (prefer-includes, prefer-set-has), real hidden-bug catches (no-array-push-push, no-thenable), and some opinionated style. Turn off the churn (unicorn/filename-case, unicorn/prevent-abbreviations, unicorn/no-null) and keep the rest. Best caught-mistakes-to-config ratio you'll find. The rest are quieter, but each one caught something once. Skim them: Dead code — eslint-plugin-unused-imports sweeps the imports the model added for an approach it then abandoned (auto-fixed on --fix). No eval — no-eval, no-implied-eval, no-new-func, no-script-url. Off by default; zero legit uses, infinite ways for generated code to sneak one in. XSS sinks — vue/no-v-html / react/no-danger, plus eslint-plugin-no-unsanitized for raw innerHTML. Any HTML injection has to pass through a sanitizer, enforced at lint time. Hardcoded strings — eslint-plugin-i18next, so the day you add a language nothing's baked into the markup. Test hygiene — no-focused-tests as an error, so a stray it.only can't silently shrink the CI suite. Leaked secrets — eslint-plugin-no-secrets flags high-entropy literals that look like committed tokens. Design drift (custom) — a ~40-line AST script that fails the build when a raw hex/size/shadow shows up where a named token should be. Layer boundaries — eslint-plugin-boundaries to stop one layer importing another, plus a custom rule forcing risky mutations through a single function. Each of these is a lesson we only had to learn once. After that, the linter remembers it for us. Forever, for free, on every commit, for every contributor — human or AI. The trick that keeps the gate from being annoying Most people give up on linting for one reason. They turn on every rule at error on day one, drown in ten thousand warnings, and rage-quit. Don't do that. Run new rules warn-first. Let them report without blocking. Get the count to zero on your own schedule. Then ratchet that rule up to error so it can never regress. Here's the reframe that matters: those warnings aren't a to-do list you owe the linter today. They're a map of where the mines are buried. You freeze the count, stop anyone from planting new ones, and clear the field at your own pace. For the handful of legacy offenders you can't fix today, keep an explicit allowlist. And treat adding to that allowlist as the thing you're not allowed to do. The list only ever shrinks. That's how a gate stays strict without crying wolf — and how you tame inherited code without it blowing up in your face. Gotchas A linter only sees what's static. Dynamic imports, string-built code, and values resolved at runtime are invisible to it. Know the blind spots. A green lint is not "provably correct." --fix is not free thinking. Auto-fix is great for unused imports and formatting. It is not great at deciding whether a flagged thing was a real mistake. Read the diff. Gate on the trend, not the absolute count. Failing CI because the repo has any warnings is untenable in a vibe-coded codebase. Fail when the count grows past the baseline. That's actionable. "Be perfect" isn't. A rule you suppress everywhere is a rule you deleted. If every other line has a disable comment, you didn't pass the gate — you removed it. Fix the code or kill the rule honestly. The mild jab Here's the irony I can already see coming. You've read this whole piece on why bolting AI onto already-solved problems is wasteful — and your very next move is to open a chat window and type "add ESLint and all the plugins to my repo." Or worse: "build me a code-review agent that flags unused imports and circular deps." Stop. Both are the wrong move. The first one drops you into a rabbit hole of 1000+ errors you'll be digging out of forever. Start with the base recommendation, then slowly work toward the rest. As for the code-review agent — I'll pretend I didn't hear that. We just spent this whole article on why a linter beats an AI reviewer here. So why are you still reaching for it? Look, if you hate your tokens that much — if you're really itching to spend them on a problem a free, decades-old tool already solves deterministically — just send them my way. I'll put them to better use. AI is genuinely good at the fuzzy stuff — turning an idea into reality, that dopamine hit of making something from nothing. Let it do that. Leave the heavy judgement of code quality to linter. And let me be honest about the other side: a linter won't fix your architecture, won't catch a wrong business rule, won't tell you the feature was a bad idea. That part is still on you. What it will do is take the boring, mechanical, never-ending category of mistakes off your plate — so your brain is free for the part that actually needs one. Takeaway A linter is the cheapest reviewer on your team. Free, deterministic, tireless, and completely unimpressed by hype. Make it a hard gate on merge, and you raise the floor for everyone at once. Then teach it your own recurring mistakes — token drift, hardcoded strings, circular deps, unsafe HTML, dropped awaits — one custom rule per bug class, warn-first then ratcheted to error. Add the linter first. Then, if you still want an agent, at least it's reviewing code that already cleared the bar. The cheapest reviewer you'll ever hire has been sitting in your repo the whole time.

Your agents are already in production. Is anyone checking their work? If your team is using any AI coding assistant — Claude Code, Cursor, Codex, Copilot — agents are already writing code that's ending up in your codebase. The question isn't whether to use them. It's whether you have any systematic way to check what they produce before it reaches production. Most teams don't. They rely on code review, which worked fine when engineers wrote every line themselves. It scales poorly when agents are generating hundreds of lines per session. That's the gap aislop fills. What is aislop? aislop is a free, open-source CLI that scans your codebase and scores it against 50+ rules specifically designed to catch the patterns AI coding agents leave behind. It runs in under a second, requires no LLM at runtime, and works across TypeScript, JavaScript, Python, Go, Rust, Ruby, PHP, and Java. You run it. You get a score out of 100. You see exactly what's wrong and where. npx aislop scan That's it to get started. No account, no config, no setup. Why does AI-generated code need its own quality gate? AI-generated code fails differently than human-written code. It compiles. It passes tests. It looks reasonable in a 30-second review. But it has structural tells that accumulate into real problems over time: Narrative comments that describe what the code does line by line, instead of why — a sign the model was narrating, not documenting. These add noise without adding information. Swallowed exceptions where the catch block exists but nothing happens inside it. The error is handled in appearance only. In production, it disappears silently. Generic naming — data2, result, temp — that makes sense in isolation but makes a whole file harder to read and reason about as the codebase grows. as any and @ts-ignore in TypeScript where the agent hit a type complexity it didn't want to resolve. These aren't just style issues — they actively remove the safety guarantees your type system is supposed to provide. TODO stubs left where the hard logic should be. The function exists. The important part doesn't. None of these are bugs your tests will catch. They're quality problems that accumulate quietly until your codebase is meaningfully harder to maintain — and until the agents reading that code to generate their next PR are learning from bad examples. The three concrete benefits 1. You stop relying on reviewer attention to catch mechanical issues When aislop runs before review, the structural problems are already surfaced. Reviewers can focus on logic, architecture, and business context — the things only a human can evaluate — instead of hunting for unused imports and TODO stubs in a 400-line diff. 2. You set one consistent standard across every agent on your team Different engineers prompt differently. Different agents produce differently. Without a shared quality gate, your codebase standards depend on whoever reviewed a given PR on a given day. aislop gives you one bar, enforced consistently on every merge. 3. You close the loop — sending bad code back to the agent that wrote it When aislop finds something it can't auto-fix, npx aislop fix --claude hands the findings directly back to Claude Code, Codex, or Cursor for a second pass. The agent fixes its own output before a human reviews it. You get cleaner PRs without adding reviewer time. How to set it up Step 1: Run a baseline scan npx aislop scan This scores your current codebase, grouped by engine (formatting, linting, code quality, AI slop, security). Whatever number comes back is your starting point. Step 2: Auto-fix the easy stuff npx aislop fix This applies all the mechanical fixes — unused imports, trivial comments, formatting issues — and re-scans so you see the new score. Anything requiring judgment is left for you or your agent. Step 3: Gate it in CI npx aislop init The interactive wizard writes a .aislop/config.yml and optionally drops a GitHub Actions workflow file. Set your score threshold. From that point on, every PR runs through the gate automatically and can't merge below your bar. Total setup time: under ten minutes. The bottom line AI coding assistants have made execution faster. They haven't made judgment automatic. aislop sits between the two — catching what agents consistently get wrong before it reaches your reviewers, your users, or the agents writing the next PR. Your agents are already writing production code. Make every PR meet your standard. Run your first scan →

I got tired of reviewing pull requests that looked fine until they were not. The code compiled. The tests passed. The diff looked reasonable. Then, buried in the middle, there would be a catch block that swallowed every error, a TODO that returned fake data, or another as any cast because the agent did not finish the type work. That is the part people underestimate about AI-generated code. The first problem is not that it is obviously broken. The first problem is that it often looks acceptable. I built [aislop](https://github.com/scanaislop/aislop) for that gap. What aislop is aislop is an open-source CLI for scanning AI-written code before it reaches production. It looks for the patterns AI coding agents leave behind when they are optimizing for "make the prompt work" instead of "keep this codebase healthy." Run it once: npx aislop@latest scan Or install it and make it part of your local workflow: npm install --save-dev aislop aislop scan --changes It scores the code, reports findings, and can auto-fix the mechanical issues. The more important part is the gate: it gives your team a way to catch AI slop before it becomes normal. The problem it solves Claude Code, Cursor, Codex, Copilot, and other coding agents are useful. This is not an argument against them. I use them because they make real engineering work faster. But agents have a different failure profile than humans. They write error handling that makes the function stop throwing, even when that hides the real failure. They add comments that explain the code instead of explaining a decision. They duplicate helpers because discovering the existing helper requires context. They cast through type errors because the compiler is in the way of finishing the task. None of that means the agent is useless. It means the output needs a different quality gate. Your existing linter still matters. Tests still matter. Typechecking still matters. aislop sits next to those tools and asks a narrower question: Did an AI coding agent leave behind patterns that will make this code harder to maintain? What it catches Common findings include: Narrative comments above self-explanatory code Swallowed exceptions and empty fallbacks Unsafe as any casts Hallucinated imports Duplicated helpers and dead code Production TODO stubs Hardcoded environment values Oversized files and functions that agents kept appending to These are not always bugs on day one. That is why they survive review. The damage is cumulative: noisier files, weaker types, less trustworthy error handling, more duplicate logic, and slower future changes. Why I wanted a dedicated tool General-purpose linters were designed around human-written code. They catch formatting issues, unused variables, unsafe syntax, and many useful correctness problems. They do not fully understand the repeated fingerprints of agent output. For example, a linter might catch this: try { await sync(); } catch {} But it probably will not catch this: try { await sync(); } catch { return []; } The second version is what agents often write. It looks like error handling. In production, it means "the sync failed" and "there were no records" now look identical. That is the kind of pattern aislop is built to flag. Where it fits Start with changed files: aislop scan --changes Then add CI: aislop ci --changes --base origin/main If your team uses agent hooks, install one: aislop hook install --claude The goal is simple: keep the speed of AI-assisted development, but stop the low-quality residue from merging unnoticed. That is the bet behind aislop: AI coding agents are here to stay, so code quality tooling has to adapt. Repo: github.com/scanaislop/aislop Site: scanaislop.com

AI slop in code is not just broken output. It is generated code that passes tests while making the codebase harder to maintain. AI slop in code is not the same as code that fails to compile. That is the important part. Most AI slop compiles. It passes the happy-path tests. It satisfies the ticket. It looks fine if you skim the diff quickly. The problem is that it carries the fingerprints of a model completing a prompt, not an engineer thinking through how the system should age. Left alone, those fingerprints turn into technical debt. A useful definition AI slop in code is generated code that appears functional but weakens maintainability, reliability, or clarity. It is code that says: "the task is done" while quietly making the system harder to work on. That can mean silent error handling. It can mean fake defaults. It can mean unsafe type casts. It can mean copied utilities, noisy comments, or production stubs that should never have left the agent session. The common thread is not that the code is obviously broken. The common thread is that the code is low-judgment. Example: narrative comments Agents often write comments like this: // We are sorting the users by name so they appear in alphabetical order const sortedUsers = [...users].sort((a, b) => a.name.localeCompare(b.name)); The comment is grammatically correct. It is also useless. The code already says that. A good comment would explain a constraint: // Product wants locale-aware sorting here because names include accents. const sortedUsers = [...users].sort((a, b) => a.name.localeCompare(b.name, userLocale), ); The first comment is narration. The second comment preserves a decision. That difference matters because generated code can fill files with narration. Reviewers then spend more time reading words that carry no engineering signal. Example: swallowed exceptions This is one of the most dangerous patterns: async function loadInvoices(customerId: string): Promise<Invoice[]> { try { return await billingApi.invoices(customerId); } catch { return []; } } The function now treats "the customer has no invoices" and "the billing API failed" as the same event. That is not resilience. It is lost information. AI agents write this because it makes the function easy to use. Callers do not need error handling. Tests are easy to write. The feature keeps moving. Then production breaks and nobody knows why the UI says there are no invoices. Example: unsafe casts When a model gets stuck on a type mismatch, it often reaches for a cast: const user = response.data as any; return user.profile.id; The compiler stops complaining. The real problem moves to runtime. One as any might be a local compromise. Dozens of them across a codebase are a sign that the type system is being used as decoration, not protection. In AI-assisted teams, this can accumulate quickly because agents optimize for completing the requested change, not preserving type discipline across the whole system. Example: duplicate helpers Agents often regenerate instead of reuse. export function formatCurrency(amount: number): string { return new Intl.NumberFormat("en-US", { style: "currency", currency: "USD", }).format(amount); } This helper might already exist. The new copy works. It passes tests. Nobody notices until a future change updates one version but not the other. This is why AI slop is often an aggregate problem. A single duplicated helper is not a crisis. A codebase full of them is slow to change. Why it matters AI slop matters because agents can produce it at a rate humans rarely match. A human might introduce an unsafe cast after a long debugging session. An agent can introduce ten in one PR. A human might leave one sloppy fallback. An agent can spread the same fallback pattern across a feature. That changes the economics of review. You cannot rely only on human reviewers to notice every recurring pattern in larger and faster diffs. You need the normal tools: tests typechecking linting security checks code review And you need a gate tuned for AI output. That is where aislop fits. It scans for the recurring patterns that AI coding agents leave behind and turns them into visible findings before they merge. AI-generated code is not going away. The standard for shipping it has to get sharper.

AI coding tools have changed how software gets written. Developers are now using Cursor, Claude Code, Codex, Copilot, Windsurf, Cline, Lovable, Bolt and other agentic tools to move faster than ever. They can generate components, refactor services, write tests, scaffold APIs, migrate frameworks and explain unfamiliar codebases in minutes. That speed is real. But so is the mess it can leave behind. The more I used AI coding agents, the more I started noticing the same patterns across different projects. Not always broken code. Not always obviously bad code. But code that felt slightly off. Code that worked enough to pass a quick check, but carried strange decisions, unnecessary wrappers, swallowed errors, fake-looking abstractions, unused imports, hardcoded values, duplicated logic and comments that sounded confident but added no value. That is what I call AI slop. Not because AI-generated code is automatically bad. It is not. Some of it is genuinely useful. AI slop is the residue left behind when code is generated quickly but not properly cleaned, validated or shaped into something maintainable. And as more AI-written code reaches production, I think this is becoming one of the next important software engineering problems. What AI slop looks like AI slop is not one single thing. It is a category of patterns that tend to appear when coding agents are trying to be helpful, defensive or overly complete. For example: try { await saveUser(user); } catch (error) { // ignore } A swallowed error like this might look harmless in a generated flow, but in production it can hide the exact failure you need to debug. Another common one: const data = response as any; This is the classic “make TypeScript stop complaining” move. It gets the code past the compiler, but removes the safety you were using TypeScript for in the first place. Then you see things like this: // This function processes the user data and returns the processed user data function processUserData(userData) { return userData; } The comment adds nothing. The function adds nothing. But the codebase now has more noise. Other examples include: unused imports left behind after multiple agent iterations hardcoded URLs, IDs or configuration values TODO comments that become permanent over-defensive validation around already-typed inputs re-declared types that already exist elsewhere in the codebase dead code from previous attempts half-renamed variables duplicate helper functions console logs left in production paths broad catch blocks that hide real failures hallucinated imports or dependencies oversized functions generated in one pass Individually, each one can look small. Together, they make a codebase harder to trust. The problem is not that AI writes bad code I do not think the right framing is “AI code is bad.” That is too lazy. The real issue is that AI coding agents optimise for completion. They are trying to satisfy the prompt, produce something plausible and keep the workflow moving. That means they can often generate code that looks done before it has been properly shaped. Human developers do this too, of course. The difference is scale. A developer might write messy code slowly. An AI agent can generate messy code across several files in seconds. That changes the review problem. Before, code review was mainly about checking what another human intentionally wrote. Now, review increasingly includes checking what an agent generated, why it generated it, whether it actually fits the surrounding codebase, and whether it introduced subtle maintainability debt. That is a different kind of burden. Existing tools were not really built for this We already have linters, formatters, static analysis tools, type checkers, security scanners and AI code reviewers. They all matter. ESLint can catch syntax and style issues. TypeScript can catch type errors. Snyk can catch known vulnerabilities. Sonar can flag quality issues. AI review tools can comment on pull requests. But AI slop sits in a slightly different space. It is not always a compiler error. It is not always a security vulnerability. It is not always something a formatter can fix. And by the time it reaches pull request review, the code has already been accepted into the developer’s workflow. Someone now has to spend time untangling it. The earlier you catch it, the cheaper it is to fix. That is why I think the next layer of developer tooling needs to move closer to the point of generation. Not just after the pull request. Not just after CI. But while the agent is producing the code. AI-generated code needs a quality gate When agents become part of the development workflow, they also need guardrails. A quality gate for AI-generated code should be fast, deterministic and easy to run locally. It should not need another large model to judge the output. It should not give a different answer every time. It should catch repeatable patterns that developers already know are risky or noisy. That is the direction I have been exploring with aislop. aislop is an open-source CLI that scans code for patterns commonly left behind by AI coding agents. It gives a score, highlights findings and focuses on things like swallowed errors, unsafe as any, dead code, hallucinated imports, hardcoded values, useless comments, oversized functions and other slop patterns. The goal is not to replace human review. The goal is to stop obvious AI-generated mess from reaching human review in the first place. A simple workflow could look like this: npx aislop scan Or inside an agentic workflow: npx aislop scan --json The agent writes code, the scanner runs, and the feedback goes back into the loop before the code reaches the pull request. That is the part I find most interesting. Not just: Scan my repo. But: Before you tell me the task is complete, prove that the code is clean enough to continue. That is where this category becomes useful. Deterministic checks still matter There is a lot of excitement around LLM-based code review, and I understand why. LLMs can explain, reason and catch things that simple rules may miss. But not everything needs another model. Some patterns are deterministic by nature. An empty catch block is either there or it is not. An unsafe cast is either there or it is not. An unused import is either there or it is not. A hardcoded secret-like value is either there or it is not. A file with large generated functions, repeated helpers and useless comments can be scored and flagged without sending it to an LLM. That matters because deterministic tools are fast, cheap, repeatable and easier to trust in CI. When code is being generated more frequently, we need tools that can keep up with that speed. False positives are the hard part The hardest part of building this kind of tool is not finding bad patterns. It is avoiding lazy judgement. There is a big difference between code that looks like slop and code that is intentionally written a certain way for a good reason. That is why false positives matter a lot. I learned this the hard way when someone ran aislop on a mature open-source Python project and the score came out badly. At first glance, it looked like the tool had found a lot. But after going through the findings one by one, many of them were not genuine issues. They were bugs in my own detection logic. So I fixed them. That experience made the tool better. It also made the philosophy clearer: the goal is not to shame codebases or produce dramatic scores. The goal is to give developers useful, fair feedback that helps them clean up the residue from AI-assisted development. A tool like this only earns trust when developers can look at the findings and say: Yeah, that is fair. This category will become more important The more code agents write, the more teams will need standards around agent output. I think we will start seeing questions like: Did the agent introduce unnecessary abstractions? Did it leave behind dead code? Did it swallow errors? Did it use unsafe casts to force the code through? Did it duplicate existing logic instead of reusing what was already there? Did it generate comments that explain nothing? Did it hardcode things that should live in config? Did it produce code that passes locally but creates long-term maintenance debt? These are not theoretical questions. They are already showing up in real workflows. The companies and teams that benefit most from AI coding tools will not be the ones that blindly accept every generated diff. They will be the ones that build strong feedback loops around generation, validation, testing, review and cleanup. AI can help us write code faster. But speed without quality control just moves the bottleneck somewhere else. The tool: aislop This is why I started building aislop. aislop is an open-source CLI for detecting the kind of code quality issues AI coding agents often leave behind. It scans your codebase locally, gives a score from 0 to 100, and highlights patterns like swallowed errors, unsafe as any, dead code, hallucinated imports, hardcoded values, useless comments, oversized functions, duplicated logic and other signs of AI-generated mess. You can try it with: npx aislop scan For CI or agentic workflows, you can also use JSON output: npx aislop scan --json Links: GitHub: github.com/scanaislop/aislop npm: npmjs.com/package/aislop Website: scanaislop.com The idea is simple: Before AI-generated code reaches pull request review, run a fast deterministic quality gate over it. Not to replace human review. But to catch the obvious slop early, while the agent or developer can still fix it quickly.