DEV Community: Scan AI Slop

aislop is now on the GitHub Marketplace

Taiwo Olawuwo — Fri, 19 Jun 2026 08:57:25 +0000

If you are writing and shipping code with Claude Code, Cursor, or Codex, this is your missing quality layer.

aislop started as a CLI built for one specific problem, catching the patterns AI agents leave behind that look fine in review and quietly degrade a codebase. Swallowed exceptions. as any everywhere the types got complicated. TODO stubs where the real logic should be.

Today it hit a milestone, it's live on the GitHub Marketplace.

That means installing aislop on a repo is now a two-click process. No manual CI setup. Every PR gets scanned automatically, findings go back to the agent that wrote the code, and nothing merges below your quality threshold.

The core is the same:

50+ rules across 8 languages
Sub-second, deterministic, no LLM at runtime
Catches swallowed exceptions, unsafe type casts, narrative comments, dead code, oversized files, dependency vulnerabilities

But the barrier to getting a team set up is now basically zero.
If you're already running npx aislop scan locally, the Marketplace app is the natural next step, same gate, every PR, no config work.

If you haven't tried it yet, this is a good moment to start. Install now on Github: https://github.com/marketplace/aislop-ai-code-quality-gate

Here is the link to the opensource project on GitHub: https://github.com/scanaislop/aislop

Visit to learn more on: https://scanaislop.com

AI Made Coding Easier. It Also Made Bad Code Easier to Ship.

Makanju Oluwafemi — Fri, 19 Jun 2026 04:39:33 +0000

At its core, software development has always been about a simple cycle:

Write > Review > Deploy > Monitor

You ship code. The code goes through reviews. You deploy it. Then you monitor production to make sure everything stays stable. When you're working in a team, code reviews are non-negotiable. They're one of the best ways to maintain quality, catch issues early, and ensure everyone is building toward the same standards. But we're now living in a very different era. An era where a developer or, honestly, a random dude with an idea can build products through conversation.

Hehe, interesting times!

From GitHub Copilot to "Build Me an App"

I remember when developers were almost shy about admitting they used coding assistants. Back in the early GitHub Copilot days, saying "I use AI to help me write code" sometimes felt like admitting you were taking shortcuts.

Fast forward to today, and we've reached a point where people can write code using natural language. I genuinely never thought we'd get here this quickly. And since then, it's been one hell of a ride.

Why 7 Out of 10 Developers Ship AI-Assisted Code

Today, most developers are shipping AI-assisted code. Not because they're bad developers. Not because they're lazy. Because it makes them faster.

AI helps close the gap between domain expertise and implementation.

You can go from "I've never heard of this technology" to "I can build something with it" within 30 minutes to an hour of focused work.

Traditionally, learning a new framework, library, or service required days of reading documentation and experimenting.

Now, AI can accelerate that process dramatically.
That's the magic.

The Part Nobody Talks About

The problem is that while AI is incredibly good at generating code, it's not always good at generating good code.

Recently, I built a product using Antigravity, and while it helped me move fast, I noticed several issues almost immediately:

Poor code quality
Weak function modularization
Security concerns
Repeated implementation patterns
Lack of reusable abstractions

The code worked. But "working" and "maintainable" are two very different things.

And that's really the challenge with AI-assisted development today. The volume of code being generated is growing faster than our ability to review it properly.

A lot of the issues aren't outright bugs. They're the subtle things that slowly make a codebase harder to maintain over time. Swallowed exceptions, generic variable names, dead code, unnecessary comments, duplicated logic, unsafe type assertions, and TODO stubs that somehow make it to production.

That's what got me interested in ScanAISlop.

One thing I like about it is that it isn't trying to play detective and tell you whether a human or AI wrote the code.

Instead, it focuses on the stuff that actually matters: bad patterns, weak abstractions, security concerns, unnecessary complexity, and all those little things that make a codebase harder to maintain over time.

The approach is pretty straightforward. No LLM sitting behind the scenes making guesses. The checks are deterministic, so the same code produces the same result every single time.

And because the rules are opinionated, the output tends to be a lot more useful than tools that flag everything and leave you sorting through noise.

You can try it right now on any public GitHub repository.

Simply replace:

github.com/<owner>/<repo>

with:

scanaislop.com/<owner>/<repo>

and you'll get an instant report showing potential quality, security, and maintainability issues across the codebase.

I ran the CLI against one of my own projects, and the results were surprisingly useful. Instead of giving me a vague score, it pointed directly to the kinds of issues that reviewers typically miss when scanning large AI-generated pull requests.

try npx aislop scan to try-out the CLI

The most interesting part?

The CLI is completely open source and MIT licensed. You can inspect the rules, contribute improvements, open issues, or even help shape what good AI-assisted engineering should look like.

Please take a minute to try it out and star the repo: https://github.com/scanaislop/aislop.

As AI continues to generate more code, I think tools like this become increasingly important—not because AI is bad, but because engineering standards shouldn't disappear just because code is easier to produce.

The Real Advantage

This is where engineering fundamentals still matter. Understanding how systems work, knowing how to structure a codebase, understanding design systems, knowing when to abstract a component, and knowing when not to.

These things still separate experienced engineers from people who are simply prompting their way through development.

For example, if I'm using a table across multiple screens, I'd rather create a reusable component once than copy and paste:

across ten different files. AI can absolutely generate the table.

But it takes engineering judgment to recognize that it should become a reusable building block.

And most times, you have to explicitly tell your coding assistant that. AI can generate code. Experience tells you what code should exist in the first place.

The New Skill Isn't Coding Faster

The new skill isn't necessarily writing code faster. It's reviewing code better. It's knowing what should be abstracted. It's spotting security issues. It's identifying AI-generated slop before it reaches production.

Because the future isn't AI versus developers. The future is developers who know how to think, using AI as leverage.

And those developers will always have an edge.

Why Your Team Needs a Quality Gate for AI-Generated Code (And How to Set One Up in Minutes)

Taiwo Olawuwo — Mon, 08 Jun 2026 11:54:07 +0000

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 →

The Output Layer Problem: Why AI Velocity Makes Quality Gates More Important, Not Less

Taiwo Olawuwo — Mon, 08 Jun 2026 11:44:07 +0000

The faster your agents ship code, the faster slop accumulates. Here's why the solution isn't slowing down.

There's a version of the AI productivity story that goes like this: agents write the code, humans review the diff, everyone ships faster. Clean. Straightforward. Optimistic.

The problem is that the middle part — "humans review the diff" — doesn't scale at the same rate as the first part. Agent output has compressed. Human attention hasn't.

When a developer using Claude Code or Cursor can generate in an afternoon what used to take a week, the review queue doesn't empty faster. It fills up with bigger diffs, more files touched, more surface area to hold in your head at once. The execution layer has gotten faster. The judgment layer is the same size it was.

This is what we'd call the output layer problem: the gap between how fast code is produced and how thoroughly it can be evaluated. And it's where a surprising amount of slop quietly enters production.

What slop looks like at speed

AI-generated code isn't bad in the way junior developer code is bad. It doesn't usually have obvious logic errors or missing edge cases you'd catch in five minutes. It compiles. It passes your tests. It looks, at a glance, like perfectly reasonable code.

What it tends to have instead are the structural signatures of code that wasn't written to be maintained:

Narrative comments that explain what the code does line-by-line rather than why it does it — a tell that the model was narrating rather than documenting
Generic naming that makes sense in the context of a single function but degrades the readability of a whole file over time
Swallowed exceptions where error handling was stubbed in and never completed — the catch block exists, but nothing happens inside it
as any and @ts-ignore scattered through TypeScript where the model hit a type complexity it didn't want to resolve properly
TODO stubs left in place where the agent ran out of context or confidence and deferred the hard part

None of these are catastrophic individually. Together, across a codebase where agents are writing code at volume, they compound into something that's genuinely difficult and expensive to work with — not because any single file is broken, but because the accumulated weight of small quality deficits makes the whole system harder to change.

This is what the vibe coding optimism tends to skip over. Building software is fast now. Running, maintaining, and evolving software is still the same job it always was — and that job is harder when the input material is structurally inconsistent.

The review bottleneck is real, and it's getting worse

If you're a tech lead on a team that's adopted AI-assisted coding in any serious way, you've probably already felt this. PRs are bigger. The diff is longer. Your engineers are shipping more, but you're spending more time in review just to keep up with what they're producing — let alone to actually evaluate it carefully.

The instinct is to review faster. Skim the obvious stuff, focus on the logic, trust that tests will catch the rest.

The problem is that the patterns aislop flags — unused exports, oversized functions, trivial comments, unsafe type assertions, swallowed exceptions — are exactly the things that get skimmed past in a fast review. They're not bugs. They're not even wrong, exactly. They're just the structural residue of code that was generated rather than crafted, and they accumulate quietly until the codebase is meaningfully harder to work in.

Speed-reviewing your way through AI-generated output doesn't solve the output layer problem. It just defers it.

What a quality gate actually changes

A deterministic quality gate doesn't replace engineering judgment. It protects it.

When aislop scans a PR before it reaches review, the mechanical issues are already surfaced and scored. The reviewer doesn't have to catch them — they're in the findings. The auto-fixable ones are already gone. What's left for the human reviewer is the stuff that actually requires a human: the architectural decisions, the business logic, the tradeoffs that only make sense if you know why the system works the way it does.

That's the division of labour that makes AI-assisted coding actually work at scale. Agents handle the execution. Deterministic tooling handles the structural quality check. Humans handle the judgment calls that context-free tools can't make.

Without the middle layer, you get a situation where reviewers are either doing the machine's job (checking for as any and TODO stubs in a 400-line diff) or not doing it (approving PRs that look fine but quietly degrade the codebase). Neither option is sustainable as agent output volume grows.

The compounding problem nobody talks about

There's a second-order effect here that's worth naming directly.

Agents don't just write new code. They read the existing codebase to understand context for what they're generating. When the codebase has accumulated structural slop — inconsistent naming, commented-out dead code, generic variable names that don't signal intent — agents use that as training signal for what's acceptable.

Slop, in other words, teaches agents to produce more slop. A codebase that's been maintained with a quality gate produces materially better agent output than one that hasn't — because the agent has better patterns to learn from and fewer ambiguous examples to confuse it.

This is the compounding argument for catching slop early. It's not just about the current PR. It's about the quality floor of every PR that comes after it.

Codifying what "good" looks like

The article that inspired this one — from the Leaders of Code podcast, featuring Jon Hyman of Braze and Jody Bailey of Stack Overflow — makes the point that one of the most consequential engineering tasks of the next few years will be getting experienced engineers' knowledge out of their heads and into a form that agents can use.

That's true of architectural decisions and business context. It's equally true of code quality standards.

Right now, most teams' sense of what acceptable code looks like lives in the heads of senior engineers and in the informal feedback loop of code review. When an agent violates those standards, a reviewer catches it — if they're paying attention, if they're not in a hurry, if the diff isn't too large to parse carefully.

A quality gate externalises that standard. It makes the bar explicit, consistent, and enforceable without depending on reviewer attention in any given review cycle. That's not a replacement for the senior engineer's judgment. It's a way of making that judgment durable and scalable — which is exactly what needs to happen as agent output grows.

What to do with this

If you're running a team that uses Claude Code, Codex, Cursor, or any other AI coding assistant at any meaningful volume, three things are worth doing now rather than later.

Set a baseline score. Run npx aislop scan on your current codebase. Whatever comes back is your current baseline — the accumulated structural debt from however your team has been working. You can't improve what you haven't measured.

Gate new additions, not just the baseline. The value of a CI gate isn't in fixing everything at once — it's in preventing new slop from accumulating while you address the existing debt incrementally. Set your threshold, commit the config, block merges that fall below it. New agent output gets checked before it reaches review.

Hand failing findings back to the agent. When aislop surfaces an issue that isn't auto-fixable, npx aislop fix --claude sends it directly to the agent that wrote the code for a second pass. You're not adding reviewer work — you're closing the loop before the human ever sees it.

The execution layer has gotten dramatically faster. The judgment layer is still human-sized. A quality gate is what keeps those two things from diverging in ways that are expensive to fix later.

aislop is a free, open-source CLI for scoring AI-generated code. It's sub-second, deterministic, and requires no configuration to start. Run it in your repo →, Github →

Introducing aislop: The Quality Gate for AI-Written Code

Kenny Olawuwo. — Sat, 06 Jun 2026 19:58:48 +0000

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