AI Slop Code: What It Is, How to Catch It in Your Repo
SHIPS FAST, ROTS FASTER
AI slop is code that ships fast and gets rewritten faster. The git-visible signals that expose it, and how to clean it up before it compounds.
TL;DR: AI slop is plausible-looking generated code that ships fast and gets rewritten, duplicated, or quietly deleted soon after. You don't detect it by squinting at style. It's visible in git as rising copy/paste, collapsing refactoring, and code rewritten within weeks. Measure those signals and slop turns into a fixable number with receipts.
What is AI slop code?
AI slop is AI-generated code that looks finished and isn't: plausible, verbose, duplicated, and shipped without the understanding that would let anyone maintain it. The name is new; the failure is measurable. Slop doesn't announce itself in review. It surfaces weeks later as rework, duplicate logic, and bug reports in code nobody remembers approving.
The word "slop" gets thrown at anything AI-touched, which is lazy. Plenty of AI-assisted code is fine. The honest definition is behavioral: code whose short-term survival rate is bad. It gets rewritten, reverted, or copy-pasted around instead of being built on. That definition matters because it's checkable. Your git history already contains the verdict.
What the research actually says
The biggest independent dataset comes from GitClear's 2026 "Maintainability Gap" report, which analyzed 623 million code changes from 2023 to 2026. Their findings, in their own units and against their own baseline years:
- Code-block duplication up 81% against 2023.
- Within-commit copy/paste rose from 9.4% of changed lines in 2022 to 15.7% in the first half of 2026.
- Refactoring line-moves down 70% against 2022 levels; moved code fell from 21% of changed lines in 2022 to 3.8% year to date in 2026.
- Two-week churn up 15%: more code revised or discarded shortly after shipping.
Their 2025 report (211 million changed lines, January 2020 to December 2024) had already flagged the direction: cloned lines rose from 8.3% of changed code in 2020 to 12.3% in 2024, while refactoring's share sank from 25% of changed lines in 2021 to under 10% in 2024. And Faros AI's 2026 AI Engineering Report added the downstream bill: bugs per developer up 54% at high AI adoption.
Read those together and the shape of slop is clear. AI doesn't write broken code so much as it makes copy-paste cheaper than refactoring, and teams under delivery pressure take the discount. The interest compounds later.


How do you catch AI slop in your repo?
You don't catch it by reading diffs and trusting your nose. You catch it with three git-visible signals, each checkable this week:
1. Short-window churn
Pick a window - two weeks after merge is what the GitClear research uses - and measure how much shipped code gets rewritten or deleted inside it. Rising short-window churn is the single most direct slop signal, and it's the subject of its own deep dive: AI code churn and why AI-written code gets rewritten.
2. Duplication and vanishing refactors
Track your copy/paste ratio and your moved-code ratio over time. Slop shows up as the first climbing while the second collapses: new code piling up beside old code instead of replacing it. Most static-analysis tools and even git log --follow archaeology can expose this; the trend matters more than the absolute number.
3. Review pressure that didn't scale
AI multiplied code output; it did not multiply reviewers. If PR volume and size went up while review depth and pickup discipline stayed flat, your safety net has holes exactly where the generated code lands. Watch review coverage next to AI adoption, not instead of it. Review health is where slop either gets caught or gets merged.
One honest caveat on attribution: if you want to compare AI-authored code against human-authored code, use explicit signals only (commit trailers, bot accounts, agent identities). ML fingerprinting that guesses "this looks AI-written" produces numbers nobody can defend in a retro. If you can't attribute cleanly, measure the whole repo's trend lines instead; slop moves them anyway.


Cleaning it up
The cleanup, in order of payback:
- Set a rework budget. Celebrate code that survives 90 days instead of lines generated. The moment "shipped and stayed shipped" is the scoreboard, slop shows up on it.
- Hunt duplication where churn is hottest. Don't refactor alphabetically. Rank directories by short-window churn, then collapse the duplicate logic in the top offenders first - that's where the next bug already lives.
- Restore review pressure. Smaller PRs, explicit reviewer load balancing, and no self-merges on AI-heavy changes. A reviewer who can hold the diff in their head is your cheapest slop filter.
- Make attribution a habit. Commit trailers for AI-assisted work cost nothing and turn every future measurement from a guess into a receipt.
None of this requires abandoning the tools. It requires knowing whether the tools are compounding your output or your debt, and your repo can answer that. For the wider frame on what to measure across churn, review load, and delivery before trusting any AI dashboard, start with the AI productivity paradox, then check your own repo's AI impact signals.
Slop is not a moral failing and it's not a reason to panic. It's deferred maintenance with a fresh coat of paint. Teams that measure it early pay a small bill; teams that discover it in an incident review pay the compounded one.
Frequently asked
Is AI slop inevitable if we use AI coding tools?
No. Slop is what happens when generation speed outruns review and refactoring discipline. Teams that keep review coverage, small PRs, and a rework metric ship AI-assisted code that survives. The tool isn't the slop; the missing safety net is.
How do I know which code is AI-generated?
Use explicit signals: commit trailers, bot and agent accounts, and tool-attributed commits. ML-based 'AI detector' fingerprinting guesses, and you can't act on a guess. If you can't attribute honestly, measure the repo-wide trend instead; churn and duplication don't care who typed.
Does AI slop mean we should turn the tools off?
Measured teams don't need to. The research shows quality erosion at high adoption without guardrails, not that assistance is unusable. Keep the tools, add the receipts: attribution, a churn window, review pressure, and a duplication check in CI.