AI slop is low-quality digital content produced in volume by AI that reads as fluent and competent while carrying little substance. In a codebase it takes a specific and more awkward form: code that compiles, passes the obvious tests and satisfies the wording of your prompt, while ignoring the structure, conventions and constraints the rest of the system depends on. It is not broken code, because broken code gets caught. It is plausible code in the wrong place, in quantity, and the cost of it arrives months after the commit. Keeping it out is a matter of narrowing what you ask for, writing down the conventions the model cannot infer, running deterministic checks that look for the specific shapes slop takes, and keeping a human on the architecture.
Where the word came from
The term arrived to describe generated images and text, not software. Cambridge Dictionary defines AI slop as digital content, such as images and video, of low quality created by artificial intelligence. Britannica frames it as media generated with seemingly little effort from a human interlocutor, and Wikipedia notes that the word carries a pejorative connotation close to spam, attached to content produced in high volume to gain attention or money.
What slop looks like when it is code
Rushed human code advertises itself. Inconsistent naming, no tests, a trail of TODO comments, a function that clearly grew by accretion. A reviewer scanning a diff spots it without reading closely.
Generated slop has none of those tells. The naming is consistent, because the model learned naming from thousands of well-kept repositories. The formatting is clean. The comments are present. Every individual line is defensible, and the problem only surfaces on the third file, when you notice that a utility function has been rewritten because the model never found the existing one, that a try/catch sits around a call that cannot throw, and that a comment restates in prose exactly what the line beneath it does. Builder.io’s write-up on de-slopping a generated codebase puts the distinction well: slop is not wrong code, because wrong code gets caught by tests. Slop is correct code that has no business being there.
The recurring shapes are consistent enough that people have built rule sets around them. Dead code left behind when a function was superseded rather than replaced. Near-duplicate helpers, six variants of the same thing across six files. Unsafe type assertions used to make a compiler stop complaining. Swallowed exceptions. Imports of modules that do not exist. Oversized functions that keep absorbing new requirements. Fallback logic that masks a real error instead of surfacing it. The open-source scanners aislop and sloppylint both organise their checks around roughly that list, which is a useful independent confirmation that these are patterns rather than anecdotes.
Part of the mechanism is that agents behave as what one analysis of AI code review calls a “yes-master”: they generate what was asked for without the pushback a colleague would give. Ask for a small change and you may get a new function that does the job correctly, while the now-obsolete original stays exactly where it was. Nobody decided to leave it. That is the point.
Accidental debt is worse than deliberate debt
Technical debt, in its original sense, is a conscious trade-off. A team knows it is taking a shortcut, knows roughly what the shortcut costs, and intends to come back. The decision is recorded somewhere, even if only in a colleague’s memory.
Slop is debt nobody chose
Written with AI assistance and reviewed under our editorial policy. Vibe coding changes quickly; details reflect sources current on 2026-09-28. Some passages are the author's opinion. Spotted an error? tell us.
Frequently asked questions
- Is AI slop just another name for technical debt?
- No. Technical debt is normally a conscious trade-off that somebody chose and expected to repay, whereas slop enters a codebase unchosen because it looks polished and passes the obvious tests. That absence of a decision is what makes it harder to find later, since there is no note explaining why the shortcut was taken.
- Can a linter detect AI slop reliably?
- A linter catches the mechanical shapes it takes, such as dead code, duplicated helpers, swallowed exceptions, unsafe type assertions and imports that do not resolve. It cannot tell you that a correct change belongs in the wrong layer of your system, which is why architectural review still has to be done by a person who knows the codebase.
- Does telling the model to write high-quality code fix the problem?
- Only partly. The SlopCodeBench runs found that instructing agents to prioritise quality improved the initial code but did not prevent deterioration as requirements changed across later checkpoints. Written conventions in a rules file, small changes and checks in CI hold up better than an instruction in a prompt.
- How do I stop generated pull requests overwhelming reviewers?
- Cap the size of what you ask for, so each change has one concern and can be understood in a few minutes, and move the mechanical checks into the build so humans are not spending their attention on duplication and dead code. The curl project's decision to end its bug bounty after a flood of generated reports shows what happens when volume outpaces the capacity to triage it.