Avoid AI Slop: Keeping Code Quality While Vibe Coding (2026)

Jasmine, a dev who uses Claude Code every day and has shipped (and cleaned up) enough AI slop to write this piece.

Vibe coding gives you insane speed. But anyone who has let AI write code for a month hits the same feeling: you merge a PR that "works great," and weeks later you find it botches an edge case or stands up an abstraction layer nobody asked for. That is AI slop. This post is not anti vibe coding - if the term is new to you, read what vibe coding is first - it is about keeping quality when your vibe coding has discipline.

What is AI slop? (and why it differs from social-media "AI slop")

AI code slop is code generated by an AI that compiles and passes tests, yet still rots your codebase because it is structurally shallow, blind to the project's conventions, and reproduced at machine scale faster than a human can review it. It is not "clearly wrong" code - if it were obviously broken, you would catch it instantly. Slop is dangerous precisely because it looks right.

The distinction matters, because the phrase "AI slop" is being pulled in two directions:

Two different meanings of "AI slop":

1. AI content slop - the mass-produced junk videos, images, and articles flooding social feeds. Merriam-Webster named "slop" its Word of the Year for 2025 (announced 15 Dec 2025) in exactly this sense. Most articles you will find on "AI slop" are about this.

2. AI code slop - low-quality code produced by AI, the subject of this post. This is the engineering angle, and it gets far less honest coverage.

If you came looking for the social-media content meaning, this post is not for you. If you are a dev worried that your AI-written code looks right but is wrong, read on. Related terms you will see: ai code slop, vibe slop, low-quality AI code.

6 signs of AI slop code (a taxonomy)

Not all AI code is slop. But slop has a pretty recognizable fingerprint. Here are the 6 signs of low-quality AI code I run into most often, each with a quick example so you can spot it fast:

1. Looks right, wrong at the edges. The function is fine on the sample input but breaks on an empty string, a timezone, a negative number, or the last page of pagination. Example: an averaging function that never handles the empty array, so it divides by zero.
2. Over-engineering / needless abstraction. The AI builds a factory, a strategy pattern, and a generic layer for something that needed 5 lines. Example: an interface plus 3 classes to format a single date string.
3. Blind to repo conventions. Naming, folder structure, and error handling look nothing like the rest of the codebase. Example: the project uses Result<T>, but the AI throws exceptions all over the place.
4. Hallucinated API / config / package. It calls functions that do not exist, imports the wrong package name, or uses a config option that was removed. Example: import { parseDate } from 'date-fns' - except date-fns never exported that name.
5. Tests that mirror the implementation. The tests are written to pass the exact code that was just generated, not to check the expected behavior. Example: it mocks the return value and then asserts on that same mock.
6. Hard-coding and magic values. Numbers, URLs, and keys are jammed straight into the logic instead of config. Example: if (userId === 42), or a 3000 timeout scattered everywhere.

Why AI slop is worse than ordinary tech debt

Human-made tech debt is usually visible: you know where the sloppy code is because you (or a teammate) cut that corner on purpose. AI slop is worse in three ways.

First, it looks finished. The code is nicely formatted, has docstrings, has tests - every surface signal of "quality code" is present, so your brain lowers its guard. Second, it spreads uniformly at machine scale. A human is sloppy in one spot; an AI is sloppy the same way across 40 files in a single afternoon. Third, it passes every check your team trusts. Lint green, types green, tests green - because the tests were also written by the AI to mirror that same code.

A worrying number: research from CSET (Center for Security and Emerging Technology, "Cybersecurity Risks of AI-Generated Code," 2024) found that nearly half of AI-generated snippets contained bugs or exploitable security vulnerabilities. In other words: "it runs" is not the same as "it is safe to ship."

A familiar scenario: you ask the AI to add a small feature, and it "helpfully" refactors three related files along a pattern that sounds reasonable. The PR is green, the review is a skim because "it's just a refactor," and it merges. Three weeks later a strange bug shows up in a module that seemed unrelated - because that pattern silently changed the behavior of a shared function. You lose half a day tracing it back, only to find the root cause is a harmless-looking chunk of slop from way back.

The result: AI slop accumulates faster than traditional tech debt, but hides better - by the time it surfaces, it has soaked into several layers. And because it spreads by pattern, fixing one spot is rarely enough: you have to hunt down every copy the AI scattered.

A checklist to avoid AI slop while vibe coding

This is the core. Instead of a vague "review harder," break it across the 4 stages of a vibe coding loop. Print it and tape it next to your monitor if you like.

Before you prompt

• Write a clear spec / acceptance criteria before you type the prompt. The AI cannot read your mind; it fills the gaps with guesses - and guesses are where slop is born.
• Hand it small, narrowly-scoped tasks. One function, one endpoint at a time - easy to review, easy to catch mistakes.
• Load context: coding standards, architecture, existing patterns, your CLAUDE.md file. Thin context is the number one cause of slop.

While generating code

• Tell the AI to follow the repo's conventions (naming, error handling, structure) - say it plainly in the prompt, do not expect it to guess.
• Verify every API / package / config against current docs to fight hallucination. If the AI calls a function you have never seen, assume it made it up until proven otherwise.

Before you merge

• Read and understand every line. The unbreakable rule: never ship code you do not understand. If you cannot explain why a line exists, it is not ready.
• Review logic + contract + architecture, not just "does it run?". Reviewing AI code is a different job from reviewing human code - see the details in how to review AI code properly.
• Make sure the tests check expected behavior, not the implementation they mirror.
• Keep lint / type / coverage as CI gates - but remember, a green CI does not prove there is no slop.
• Check the dependencies and licenses the AI just added.

Maintaining

• Keep a "slop catalog": record the anti-patterns the AI tends to create in your repo, then feed them back into your prompt templates and CI rules. The more your codebase "teaches" the AI, the less slop you get.

Related terms for this section: AI code checklist, context engineering. No checklist kills 100% of slop - it only lowers the odds and the rate of accumulation.

A real example: one chunk of slop and the fix

Let's make it concrete with a discount function - the classic "looks right but is wrong." Here is the AI's first pass:

// BEFORE - AI slop: looks right, wrong on several edge cases
function applyDiscount(price, discountPercent) {
 const finalPrice = price - (price * discountPercent / 100);
 return finalPrice.toFixed(2);
}

// applyDiscount(100, 20) -> "80.00" ✓ seems fine

It passes the sample test, so it is easy to merge. But: (1) it returns a string, not a number - breaking arithmetic elsewhere; (2) it does not block a negative or > 100 discount; (3) it hits floating-point rounding errors on money; (4) it does not handle invalid input. The fixed version:

// AFTER - slop fixed: explicit contract, guarded edge cases
function applyDiscount(priceCents, discountPercent) {
 if (!Number.isInteger(priceCents) || priceCents < 0) {
 throw new Error('priceCents must be a non-negative integer (unit: cents)');
 }
 if (discountPercent < 0 || discountPercent > 100) {
 throw new Error('discountPercent must be within 0..100');
 }
 // Compute in cents (integers) to avoid floating-point rounding errors
 const discount = Math.round(priceCents * discountPercent / 100);
 return priceCents - discount; // returns a number (cents), not a string
}

The point is not "the fixed code is longer." It is that the slop version hid four wrong assumptions behind a tidy surface. Only when you read to understand the contract - the return type, the valid value range, how money is handled - does the slop reveal itself. That is why "it runs" is never enough.

Context engineering - the root of less slop

Fixing slop after a merge is expensive. It is far cheaper to block it up front with context engineering: give the AI the right raw materials so it does not have to guess. Concretely: coding standards, an architecture map, the existing patterns in the repo, and a solid CLAUDE.md file describing your project conventions. To go deeper into the mechanics, treat context engineering as a skill of its own.

Good context turns the AI from "a great dev on their first day at the company" into "a dev who already knows the codebase." Same model, wildly different output quality - purely from context.

At team scale, keeping context and process standards consistent across many people is hard. One approach is a ready-made kit of skills, subagents, and standard workflows for Claude Code - for example, the AgentKit kit for Claude Code packages review conventions, structure, and patterns for the whole team to share, so context and standards do not drift person by person. If you want to look at it directly, you can check AgentKit's pricing (20% off via link). No tool replaces your own judgment - but standardizing context is a real lever for cutting slop at the root.

"Taste" - the engineering judgment AI cannot replace

In the end, preventing slop cannot be 100% automated. It needs what practitioners call taste: knowing when not to ship what the AI just produced, even when it "runs." Taste is the ability to look at a chunk of code and see where it will hurt six months from now.

The AI writes code; a human is responsible for every committed line. When a bug hits production, nobody accepts "but that's how the AI wrote it." Taste cannot be bought and cannot be prompted into existence - it comes from actually reading, actually understanding, and actually owning what you merge. That is the line between vibe coding and vibe slop.

Frequently asked questions (FAQ)

How is AI slop in code different from social-media AI slop?

Social-media AI slop is content (videos, images, articles) mass-produced by AI - the common meaning that led Merriam-Webster to pick "slop" as its 2025 Word of the Year. AI code slop is low-quality AI code: it compiles and passes tests but is structurally shallow and rots the codebase. This post is about the second meaning.

Does vibe coding always produce slop?

No. Vibe coding only produces slop when it lacks discipline: vague prompts, no loaded context, and merging code you have not read and understood. Disciplined vibe coding - clear specs, good context, careful review - gives you AI speed while keeping quality.

How do I tell if my AI code has slop?

Check the 6 signs: looks right but wrong at the edges, over-engineering, blindness to repo conventions, hallucinated API/package, tests that mirror the implementation, and hard-coded magic values. If you cannot explain why a line exists, it is probably slop.

Are tests and lint enough to stop slop?

No. Lint and tests catch surface errors, but slop often sails through because AI-written tests can simply mirror the same code. You still need to read and understand the logic and check the contract and architecture with human eyes.

What tool or kit helps reduce slop?

The root fix is context engineering: load coding standards, architecture, and patterns through files like CLAUDE.md. At team scale, ready-made kits of skills/subagents/standard workflows for Claude Code help keep context and standards consistent. But tools only assist - the final call is still your judgment.

Should I ship AI code I do not understand yet?

No, absolutely not. This is the unbreakable rule for avoiding slop: if you do not understand why the code works, you cannot maintain it, cannot debug it, and cannot be accountable when it breaks. Read until you understand, then merge.

Conclusion: vibe coding with discipline

AI slop is not a reason to avoid AI - it is a reason to use AI with discipline. The formula is simple: AI's speed plus a human's review discipline equals code that is clean and fast. Drop the second half and you get slop, fast. To keep going, revisit the fundamentals in what vibe coding is and sharpen your quality control in how to review AI code properly. The AI writes the code; taste and accountability are still yours.