DEV Community: Kenny Olawuwo.

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

What Is AI Slop in Code?

Kenny Olawuwo. — Sat, 06 Jun 2026 19:43:55 +0000

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 Slop Is Becoming a Software Engineering Problem

Kenny Olawuwo. — Sat, 06 Jun 2026 19:20:21 +0000

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:

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.

Introducing aislop: the quality gate for AI-written code

Kenny Olawuwo. — Sat, 06 Jun 2026 19:14:46 +0000

I got tired of reviewing pull requests that looked fine until they weren’t.

The code compiled.
The tests passed.
The feature worked on the surface.

But inside the diff, there would be things that should never have made it that far.

A silent catch {} swallowing every error.
A // TODO: implement this properly sitting in production code.
A dozen as any casts because the agent just forced the types through instead of wiring them properly.

That is the gap I kept seeing with AI-generated code.

Claude Code, Cursor, Copilot, Gemini, Codex — they are very good at producing code that satisfies the prompt. But satisfying the prompt and keeping a codebase healthy are not the same thing.

That gap compounds over time.

So I built aislop.

aislop is an open-source CLI and quality gate for teams using AI coding agents. It scans your codebase for the kind of patterns agents keep leaving behind. Not always bugs, but signals that the code was generated quickly without enough thought for maintainability.

Things like:

swallowed exceptions
unsafe as any casts
production TODOs
dead code
narrative comments
hardcoded URLs and config
fake fallbacks that hide real failures
duplicated logic from regenerated code

Each one looks small in isolation. But together, they create the kind of codebase that becomes harder to trust every sprint.

You can run it locally:

npx aislop scan

Or put it in CI so slop gets caught before it reaches main.

The reason I think this deserves its own tool is simple: normal linters were built for general code quality. aislop is built specifically around the patterns AI agents leave behind.

That is a different problem.

It also works with agent workflows. If you are using Claude Code, Cursor, Gemini, or similar tools, aislop can run as part of the agent loop instead of only after the code is done.

There is also an installable skill:

npx skills add scanaislop/aislop-skill

The repo is open source here:

https://github.com/scanaislop/aislop

And the site is here:

https://scanaislop.com

If your team is using AI coding agents heavily, run it once on a repo that has had a lot of AI-generated commits.

The first scan is usually very revealing.

How to Deploy A Golang App to Heroku.

Kenny Olawuwo. — Tue, 23 Jun 2020 00:20:22 +0000

This is a step by step tutorial on how to deploy a Golang app on Heroku.

Requirements.

Heroku Account
Heroku CLI
Golang v1.14 and above

Step 1.

Create a Heroku account using your email and password or log in if you already have an account.

Download the Heroku CLI by running the command below on Mac OS

$ brew tap heroku/brew && brew install heroku

Or go to https://devcenter.heroku.com/articles/heroku-cli#download-and-install to install on Windows.
Login to Heroku from your terminal using the command

$ heroku login

This will open your web browser to complete the login flow.

Step 2.

Create Procfile by running

$ touch Procfile

or just create it from the directory. Run echo "web: [directory]" > Procfile replace [directory] e.g

$ echo "web: currency" > Procfile

Step 3.

Generate a go.mod file using go mod init github.com/[user_name]/[project_name] e.g.

$ go mod init github.com/heavykenny/currency

Step 4.

Set variable names in .env file e.g. PORT=8080 using

$ heroku config:set PORT=8080

You can also set other variables using this command.

Step 5.

Commit your code using the following commands

$ git init
$ git add . && git commit -m "Deploying to Heroku"

Step 6.

Create a Heroku application using heroku create [project_name] e.g.

$ heroku create go-currency
$ git push heroku master

You can then proceed to test your app using https://[project_name].herokuapp.com i.e.
https://go-currency.herokuapp.com.

If you encounter any error during any of these processes, do not hesitate to comment or reach out. Thank you.