What Is AI Slop? How to Detect and Prevent Low-Quality AI-Generated Code

AI slop is AI-generated code that compiles, passes tests, and quietly rots your codebase from the inside — and Larridin's AI Slop Index detects it automatically by analyzing repos for duplication, architectural drift, and code durability signals.

That definition needs unpacking, because "bad AI code" undersells the problem. AI slop isn't code that crashes. Crashing code gets caught. AI slop is the code that works fine on Tuesday and becomes a maintenance nightmare by March. It's structurally correct but architecturally thoughtless — copy-pasted patterns where you needed abstractions, 500-line functions where you needed five composable pieces, tests that pass because they mirror the implementation instead of validating behavior.

If you've seen what happens when someone uses ChatGPT to write a report — grammatically perfect, says absolutely nothing — you already understand AI slop. The same dynamic is playing out in codebases across every industry, except the consequences compound with interest.

The Numbers Behind the Quality Crisis

The data is no longer ambiguous. GitClear analyzed 211 million lines of code across thousands of repositories from 2020 to 2025 and found a pattern that should alarm any engineering leader:

Duplicated code blocks grew 4–8x. Copy-pasted code exceeded refactored (moved) code for the first time in 2024, with blocks of 5+ duplicated lines increasing eightfold. When AI generates code, it generates whatever pattern it's seen most — not the pattern that fits your architecture.

Refactoring collapsed. Moved lines — the signal that developers are consolidating code into reusable modules — dropped from 25% of all changes in 2021 to under 10% by 2025. A 60% decline. AI doesn't refactor. It adds.

Short-term churn spiked. Code that gets rewritten or deleted shortly after being committed — the clearest signal that something shouldn't have been merged in the first place. Heavy AI users generated 9x more churn alongside their output.

CodeRabbit's analysis adds another dimension: AI-generated code contains 1.7x more issues than human-written code, with 75% more logic and correctness errors in areas that contribute to downstream incidents. Google's own DORA research found the tradeoff in aggregate — a modest +3.4% quality gain offset by a -7.2% stability drop.

These aren't edge cases. This is the new baseline. And if your measurement stack can't distinguish AI-generated code from human-written code, you're averaging these problems into invisibility. As we explored in why DORA metrics break in the AI era, traditional frameworks weren't designed to capture this signal.

Why AI Slop Is Harder to Catch Than Traditional Tech Debt

Traditional bad code has tells. Rushed code looks rushed — inconsistent naming, missing tests, TODO comments scattered like confetti. A senior engineer scanning a pull request can spot it in seconds.

AI slop has none of these tells. It's polished. The naming is consistent (the model learned from thousands of well-named codebases). The tests exist (the model generated them alongside the implementation). The documentation is present. The PR description is articulate. Everything looks professional.

The problems are deeper:

Pattern mimicry without architecture. AI generates code by pattern-matching against its training data. If your codebase has three different patterns for database access, the AI will happily use whichever one it saw most recently in context — or invent a fourth. Over months, this produces a codebase where every module works individually but nothing fits together. The architectural coherence that makes a system maintainable erodes one AI-generated PR at a time.

Test-implementation coupling. AI-generated tests frequently mirror the implementation's logic rather than testing actual behavior. They pass. They'll keep passing. They won't catch the regression that matters, because they're asserting how the code works rather than what it should do. Your coverage number looks great. Your actual safety net has holes.

Complexity inflation. An experienced engineer solving a problem thinks about the simplest solution that handles the requirements. AI generates the most common solution from its training data, which is often more complex than necessary. A 200-line AI-generated solution to a problem that needed 40 lines isn't wrong — it just introduced 160 lines of future maintenance burden that nobody asked for.

Silent architectural drift. This is the one that costs the most. Each AI-generated PR moves the codebase slightly away from its intended architecture. No single PR is a problem. But after six months of AI-assisted development, the gap between "how this system was designed" and "how this system actually works" becomes a chasm. Refactoring your way back is exponentially harder than preventing the drift.

The Taste Gap: Why Speed Without Judgment Produces Slop

Andrej Karpathy coined "vibe coding" in early 2025 — "fully giving in to the vibes, embracing exponentials, and forgetting that the code even exists." He described using voice input to direct AI agents, barely touching the keyboard. For prototypes and hobby projects, it's liberating.

For production systems, it's a recipe for AI slop at industrial scale.

The problem isn't the tool. Cursor, Copilot, Claude Code — they're genuinely powerful. The problem is that they removed the friction that used to serve as a quality gate. Writing code by hand was slow, and that slowness forced thought. You had to understand the problem before you could type the solution. Now you can describe the problem in a sentence and get 200 lines of working code before you've finished thinking about whether 200 lines is the right answer.

Steve Jobs said the only problem with Microsoft was "they just have no taste." Bill Gates later acknowledged it — "I'd give a lot to have Steve's taste." That same dynamic is now playing out in AI-assisted engineering. Taste in software means knowing when NOT to ship what the AI produced. It means recognizing that "it works" is the floor, not the ceiling. It means understanding that a 40-line human-designed solution is better than a 200-line AI-generated one because the 40-line version will still make sense when someone reads it at 3 AM during an incident.

Senior engineers have taste because they've built systems that broke. They've maintained code at 2 AM that someone wrote fast and shipped without thinking. They've lived through the consequences of "it works today" becoming "it's unmaintainable tomorrow." AI can generate code. It cannot generate the scar tissue that produces good judgment.

This creates an uncomfortable organizational truth: your most productive AI users might also be your biggest source of slop. High output and high quality aren't correlated by default — they have to be measured independently and evaluated together.

How the AI Slop Index Works

You can't catch AI slop in manual code review. There's too much volume, and it looks too polished at the surface. You need automated signals that operate at the codebase level, not the PR level.

Larridin's AI Slop Index — part of our developer productivity suite — analyzes entire repositories in a containerized environment to produce a composite quality score. It works by combining five signals that individually are suggestive but together are diagnostic:

Code duplication ratio. Not just identical lines — semantic duplication where AI generated functionally equivalent code in multiple places instead of calling a shared function. The index compares new code against the full repository to identify patterns that should have been abstractions.

30/90-day revert and churn rates. Code that gets rewritten or deleted within 30 days of merging is a direct signal that it shouldn't have been merged as-is. The 90-day window catches the slower-burning problems — code that survives initial review but fails under real-world load or edge cases.

Complexity-adjusted analysis. A 500-line change to a complex distributed system is different from a 500-line CRUD scaffold. The index normalizes for the inherent complexity of the code being changed, so a high slop score on critical infrastructure carries more weight than boilerplate.

Architectural coherence scoring. Does the new code follow the patterns established in the codebase, or does it introduce new patterns for problems the codebase already solves? This is the signal that catches the silent drift — each individual deviation is minor, but the index tracks cumulative divergence over time.

Test behavior coverage. Not line coverage or branch coverage — behavioral coverage. Does the test suite validate what the code should do, or does it mirror what the code happens to do? AI-generated tests that simply replay the implementation score lower on this signal.

The output is a per-commit, per-developer, and per-team score that rolls up into weekly and monthly trends. Engineering leaders see where slop is accumulating — which teams, which codebases, which time periods — and can intervene before the compound interest of bad code makes intervention painful.

Building a Culture That Prevents AI Slop

Detection is half the equation. The other half is building engineering practices that prevent slop from being generated in the first place.

Identify your high-taste engineers and study them. Not your fastest shippers — your engineers with the best ratio of output to revert rate. What do they do differently? In most organizations, the answer involves three practices: they reject AI suggestions more often than they accept them, they refactor AI output before committing (shortening the code, adjusting patterns to match existing architecture), and they use AI for acceleration on well-understood problems rather than exploration on ambiguous ones.

Create explicit AI usage standards. "Use AI for coding" is not a policy. Specify where AI assistance is encouraged (boilerplate, test generation, documentation), where it requires extra review (core business logic, security-sensitive code, distributed systems coordination), and where it's prohibited (cryptographic implementations, compliance-critical paths). The organizations that avoid slop aren't the ones that ban AI tools — they're the ones that deploy them with judgment.

Restructure code review for the AI era. Pre-AI code review focused on logic correctness and style. AI-era code review needs to add architectural fit. Does this code belong in this codebase? Does it follow existing patterns or introduce new ones? Is it the simplest solution or the most common one? These questions take longer to answer, which means review capacity needs to expand — not shrink — as AI output increases.

Make the AI Slop Index visible. When teams can see their slop score trending upward, they self-correct. Not because they're being punished — because engineers generally care about code quality. The measurement creates awareness, and awareness changes behavior. We've seen teams reduce their slop scores by 30–40% within two months of having the metric visible, without any mandate or process change.

Invest in refactoring sprints. AI generates new code. It doesn't consolidate existing code. Schedule regular refactoring cycles specifically focused on AI-generated duplication — collapsing repeated patterns into shared abstractions, aligning divergent implementations, and pruning code that never should have been merged. Think of it as the codebase equivalent of editing a first draft.

The Compounding Cost of Doing Nothing

AI slop is a compound interest problem. Each sloppy merge adds a small amount of friction to the codebase. In month one, nobody notices. By month six, everything takes 20% longer. By month twelve, your senior engineers are spending more time navigating accumulated cruft than building new features — and the AI tools that generated the mess can't clean it up because they lack the architectural context to know what "clean" looks like.

The organizations that treat AI code quality as an afterthought will learn the same lesson the content industry learned with AI-generated articles: volume without quality doesn't just fail to help — it actively poisons the well. The codebase becomes harder to work with, harder to onboard into, harder to reason about. Your best engineers leave because they're spending their days untangling someone else's AI-generated spaghetti instead of doing the work they were hired to do.

Measure it now. Measure it automatically. Measure it before the compound interest makes measurement irrelevant.

Frequently Asked Questions

What exactly is an AI Slop Index and how is it different from code quality tools like SonarQube?

Traditional code quality tools analyze individual files or PRs against style rules and bug patterns. The AI Slop Index operates at the repository level, comparing new code against the full codebase to detect semantic duplication, architectural drift, and test-implementation coupling that per-file analysis misses. SonarQube tells you a function is too complex. The AI Slop Index tells you the function duplicates logic that already exists three directories away — and that the AI-generated test mirrors the implementation instead of validating behavior.

How much AI-generated code is considered "too much" for a healthy codebase?

The percentage matters less than the quality distribution. We've seen teams where 70% of committed code is AI-generated with excellent slop scores — because their engineers use AI as an accelerator and refactor the output before merging. We've also seen teams at 30% AI-generated code with terrible scores because they accept AI output uncritically. The ratio to watch is AI code share relative to revert rate and churn. If both are climbing together, slop is accumulating regardless of the percentage.

Can AI slop be fixed with better prompts or more advanced AI models?

Partially. Better context engineering — giving the model access to architectural decisions, coding standards, and existing patterns — reduces slop. But the fundamental problem is that AI generates the most statistically common solution, not the most architecturally appropriate one. Models will improve. They won't replace the need for human judgment about what belongs in a specific codebase. The organizations that rely on "smarter models will fix it" are making the same bet as those who thought "faster hardware will fix our performance bugs."

How does AI slop affect developer experience and retention?

Significantly. Engineers who care about craft — the ones you most want to retain — are disproportionately frustrated by accumulated slop. They spend increasing time navigating duplicated patterns, debugging code that doesn't follow the codebase's conventions, and reviewing AI-generated PRs that are technically correct but architecturally wrong. Over time, this erodes job satisfaction and drives attrition among your most experienced people — the exact engineers whose taste prevents slop when they're present.

Is "vibe coding" always bad for production code?

No. Vibe coding — Karpathy's term for letting AI handle implementation while the developer focuses on direction — is effective when the developer has strong taste and the problem is well-understood. A senior engineer vibe-coding a CRUD endpoint they've built fifty times before produces fine code. A junior engineer vibe-coding a distributed transaction coordinator produces slop. The practice itself is neutral. Whether it produces quality depends entirely on whether the person directing the AI can evaluate what it produces.

What's the fastest way to reduce AI slop in an existing codebase?

Start with measurement — deploy the AI Slop Index or equivalent tooling to identify where slop has accumulated most. Then prioritize: focus refactoring sprints on high-traffic, high-complexity areas where slop causes the most friction. Don't try to clean everything at once. Target the modules where engineers spend the most time and where revert rates are highest. Most teams see measurable improvement within one or two focused refactoring cycles, typically two to four weeks of concentrated effort.