# Introducing aislop: The Quality Gate for AI-Written Code

> Source: <https://dev.to/scanaislop/introducing-aislop-the-quality-gate-for-ai-written-code-326g>
> Published: 2026-06-06 19:58:48+00:00

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.

`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.

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?

Common findings include:

`as any`

castsThese 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.

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.

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](https://github.com/scanaislop/aislop)

Site: [scanaislop.com](https://scanaislop.com)
