20 AI Slop Code Examples—and the Better Pattern
AI slop becomes actionable when it has a name, a failure mode, and a better pattern. Use these examples as a review and rules checklist.
“This looks like AI slop” is not a useful review comment. It guesses at authorship and gives the contributor nothing concrete to repair.
A useful comment names the pattern, explains the failure it creates, and points to the smaller or safer alternative. The examples below are language-neutral on purpose. They can appear in TypeScript, Python, Go, Rust, Java, Ruby, PHP, or generated configuration with different syntax.
Review the observable pattern. Do not use style as an AI detector.
Errors and fake resilience
1. Swallowed exception
Slop: catch an error, log it, then return an empty result as if the operation succeeded. Better: return a typed failure or add context and rethrow so the caller can decide.
2. Catch-and-rethrow with no context
Slop: catch only to throw the same error unchanged. Better: remove the wrapper, or convert the failure once at a real boundary with useful context.
3. Universal fallback
Slop: turn every network, authorization, parse, and server failure into cached data. Better: define which failures are recoverable and make degraded state visible.
4. Retry without a budget
Slop: retry every error indefinitely or with identical timing. Better: retry only transient failures with a cap, backoff, jitter, cancellation, and idempotency.
Types, validation, and invented safety
5. Type-system escape hatch
Slop: cast unknown data directly to the desired domain type. Better: parse at the boundary and construct a value that cannot represent invalid state.
6. Validate everywhere
Slop: repeat the same null and range checks in controller, service, repository, and view. Better: validate untrusted input once, then pass a trusted type through the domain.
7. Defensive check against an impossible state
Slop: add fallback branches for values the type system or constructor already excludes. Better: trust the invariant and keep impossible states unrepresentable.
8. Boolean blindness
Slop: pass several true-or-false arguments whose meaning is invisible at the call site. Better: use a named mode or domain option with valid combinations.
Structure and comprehension
9. Narrative comment
Slop: write “increment the counter” above an increment. Better: remove narration; comment only on a non-obvious constraint or tradeoff.
10. Generic names
Slop: call important values data, result, item, and handler. Better: name the domain fact or decision.
11. One-call wrapper
Slop: add a helper that only forwards its arguments to another function. Better: call the dependency directly until an abstraction owns policy or has a second meaningful caller.
12. Oversized orchestration function
Slop: mix parsing, business rules, persistence, network calls, and response formatting in one generated block. Better: separate boundaries from domain decisions and test each responsibility.
13. Duplicate implementation
Slop: recreate an existing formatter or permission check because the agent did not search the repository. Better: inspect for established ownership before adding code.
14. Dead helper from an abandoned approach
Slop: leave code that was useful during debugging but no longer participates in the solution. Better: perform a minimum-patch pass after tests succeed.
Tests and verification
15. Test deletion as a fix
Slop: remove or skip the assertion that exposes the regression. Better: explain the changed contract, repair the implementation, or replace the test with stronger behavioral evidence.
16. Tautological generated test
Slop: reproduce the implementation's calculation inside the test and compare the two. Better: assert an independently known outcome at the public boundary.
17. Snapshot everything
Slop: update a large snapshot until CI turns green without reviewing the semantic change. Better: use narrow assertions for the behavior and review intentional snapshot deltas separately.
Dependencies, configuration, and scope
18. Hallucinated dependency
Slop: install a plausible package name directly from an agent response. Better: verify the registry, repository, maintainers, age, releases, license, and necessity before installation.
19. Speculative configuration
Slop: add environment variables, flags, and defaults for future scenarios the task does not require. Better: ship the smallest explicit configuration and add options when a real second case appears.
20. Drive-by rewrite
Slop: reformat, rename, or refactor unrelated files while fixing one bug. Better: keep the behavioral patch reviewable and move optional cleanup to a separate change.
Turn the list into a review system
Split the examples into three buckets. Automate patterns with a repeatable syntax or metric. Give contextual questions to an AI reviewer as hypotheses, not verdicts. Keep product intent, risk acceptance, and minimum-patch judgment with a human owner.
aislop detects many of the deterministic examples in this list, including swallowed errors, unsafe type assertions, narrative comments, dead code, empty functions, debug leftovers, unresolved stubs, generic naming, and complexity thresholds.
npx aislop@latest scan --changesThe scanner's value is consistency, not authorship detection. The same pattern receives the same rule ID whether a human, an agent, or a code generator created it.
Sources and further reading
Frequently asked questions
What does AI slop look like in code?
Common examples include swallowed exceptions, redundant comments, unsafe type casts, fake fallbacks, hallucinated dependencies, dead helpers, generic names, duplicated validation, disabled tests, speculative configuration, oversized functions, and unrelated edits that survive an agent's search process.
Is every code smell AI slop?
No. The same pattern can be written by a human. AI slop describes low-value residue produced or multiplied by AI-assisted workflows. Review the code and its impact rather than trying to infer authorship from style.
Can AI slop be detected automatically?
Many repeatable patterns can: empty catches, unsafe assertions, dead code, debug statements, unresolved placeholders, trivial comments, large functions, and vulnerable dependencies. Intent errors and unnecessary-but-plausible changes still require contextual or human review.