AI Slop in Code: The Cost Lands on the Reviewer

Slop in prose is embarrassing. Slop in code is an accounting problem, and until recently nobody had measured it. Three studies published between December 2025 and July 2026 now have, and they agree on something the tooling discussion mostly misses: the defect is not that generated code is bad. It is that generating it is cheap and checking it is not, so the saving and the cost land on different people.

That is a transfer, not a productivity gain, and it is why “just review it more carefully” has not worked as advice. It sits alongside the meter cost of generating the code in the first place, covered separately in the hidden cost of AI-generated code.

What counts as slop when the code compiles

Prose slop is a vocabulary problem you can see. Code slop is not, and that is most of the difficulty: the output compiles, passes the linter, has comments, and reads cleanly.

The shapes are consistent enough to name. A comment that restates the line beneath it. A catch block that swallows an error so the build stays green. A guard against a state the type system has already ruled out. A value whose type is widened, passed along, then asserted back into a narrower shape at the point of use, so the code claims knowledge it discarded two functions ago. An abstraction introduced for a second caller that never arrived.

None of these are bugs on the day they land. They are claims the code is making that the code cannot support, and the cost of each one is paid later, by someone reading it.

Where AI code actually lives in a repository

The most useful corrective to the whole debate is a measurement of where generated code ends up. A 2025 preprint, AI Code in the Wild: Measuring Security Risks and Ecosystem Shifts of AI-Generated Code in Modern Software (Wang et al.), built a detection pipeline and ran it over development commits from the top 1,000 GitHub repositories between 2022 and 2025, plus more than 7,000 recent CVE-linked code changes.

Its first finding is that adoption is structured rather than uniform. Generated code is already a substantial share of new code, but it concentrates in glue code, tests, refactoring and documentation, while core logic and security-critical configuration remain mostly human-written. Teams are not handing over the parts they are afraid of.

That is reassuring and it is also the setup for the second finding.

The propagation path that did not exist before

The same study reports that certain CWE families are overrepresented in AI-tagged code, and that near-identical insecure templates recur across unrelated projects. Not projects sharing a maintainer, or a vendored dependency, or a copied Stack Overflow answer. Projects sharing a model.

The authors call these AI-induced vulnerabilities, propagated by shared models rather than shared maintainers. It is worth sitting with how different that is from every prior mechanism. A vulnerable dependency has a version number, an advisory and a blast radius you can query. A vulnerable habit distributed through a model weights file has none of those, arrives pre-integrated into your source, and every consumer of that model reproduces it independently.

Their third finding closes the loop. In human and AI edit chains, the model introduces high-throughput changes and humans act as the security gatekeepers. When review is shallow, AI-introduced defects persist longer, stay exposed on network-accessible surfaces, and spread to more files and more repositories.

What developers actually complain about

The best read on the human side is a 2026 preprint, “An Endless Stream of AI Slop”: How Developers Discuss the Burden of AI-Assisted Software Development (Baltes, Cheong and Treude). It analysed 1,154 Reddit and Hacker News posts by hand, building a codebook of 15 codes: 14 topical, plus one rhetorical code for irony. Of the 1,154 posts, 978 received at least one code, yielding 1,603 codings at an average of 1.6 per post.

The ranking is the surprise.

What the discourse is actually about

Item	Value
structural-drivers	256
ai-limitations	227
slop-mitigations	226
sarcastic-skepticism	155
Eleven other codes	739

structural-drivers leads at 256 codings, which the paper reports as 26.2 percent of coded posts and which is 16.0 percent of all codings, the denominator the chart above uses. It covers systemic incentives that reward producing slop. ai-limitations follows at 227 and slop-mitigations at 226, and together the three account for 44.2 percent of all codings. The fourth is sarcastic-skepticism at 155, which the authors read as ironic framing being a common register in this discourse.

Put plainly: the single most discussed aspect of AI slop is not the quality of the output. It is the set of incentives that make producing it rational for the person producing it. That is a management finding, and it explains why tooling threads keep circling back to arguments about headcount and performance review.

The paper frames the whole phenomenon as a tragedy of the commons: individual productivity gains externalise costs onto reviewers, maintainers and the broader community. Codebases accumulate debt, knowledge resources get polluted, and reviewer capacity is consumed by work someone else generated in seconds.

Review is the control point, and the evidence is honest about itself

The third study is a 2026 preprint, 3100 Opinions on Code Review in an AI World: Building Causal Theory from Practitioner Discourse (Agarwal, Miller, Kästner and Vasilescu). It collected 38,709 grey-literature documents, filtered to those substantively about code review, and coded a stratified random sample of 3,100 with an assisted pipeline, producing a causal model of 26 constructs and 67 relationships, three of which it marks as contested rather than resolved.

Its observational component found that agent-authored pull requests are reviewed less often, merged several times faster, and discussed less than human-authored ones. The reason to trust this paper is what it says next: the direction of those trends flips under different but equally defensible analysis choices. The traces establish that something is changing without establishing why.

That is a rare sentence in this literature, and it should make you distrust any article citing the “merged several times faster” number without it, including the ones that will cite this page.

The paper’s organising claim is the useful part. Review is the control point through which a coding agent’s effect on a codebase is decided, and AI does not fix the sign of that effect. The team sets it, through the expertise its humans bring and how it structures review. The same agent makes a disciplined team faster and an undisciplined one worse, which is why cross-team comparisons of agent productivity keep failing to replicate.

What developers propose, and what it costs

The mitigations reported in the Baltes paper are procedural rather than technical, and they are quoted from practitioners rather than recommended by the authors. They include capping pull request size, with one source quoted as “less than 500 LOC per PR or they won’t review it”, requiring self-review before peer review, running synchronous code walkthroughs, and dual code reviews with outside teams.

Every one of those is a deliberate reintroduction of friction. That is the point, and it is also why they are unpopular: they slow the person who was made faster in order to protect the person who was made slower. A team that adopts them has decided the reviewer’s time is the scarce resource, which is precisely the accounting the tragedy-of-the-commons framing implies but very few organisations actually run.

Separately, in its recommendations to tool builders rather than in the developer discourse, the paper argues for making AI assistance visible through provenance, and for structuring output to support inspection rather than further reducing generation time.

The one check that scales

Procedure depends on people holding a line under volume pressure. A deterministic rule does not, which is the argument for putting at least one check in the build rather than in the review.

anti-slop by Dillon Mulroy is the clearest implementation: 18 Oxlint rules, each with a colocated test file, that reject low-evidence TypeScript and JavaScript. The rule names are the taxonomy. no-known-value-widening and no-widen-then-assert catch code that discards what it knew and then asserts it back. no-chained-type-assertions catches stacked casts. no-unknown-parameters, no-unknown-returns and no-unknown-type-aliases stop uncertainty leaking through a public signature. require-safety-comment-for-type-assertion forces the author to write down why a cast is safe, which is the cheapest possible provenance.

The design decision worth copying is that the project is meant to be vendored rather than depended on. There is deliberately no npm package: the bundled skill copies the rules into your repository and merges them into your lint configuration, after which they are yours to edit. The maintainer states outright that the rules encode one team’s taste rather than a universal standard, which is both honest and the correct way to ship an opinion.

Two others cover different shapes. desloppify is an agent harness that reworks existing generated code rather than linting it, though it has had no commits since 13 May 2026. miqdadbadjuber/anti-slop spans generated UI, copy and code from one rule set, describes itself as a filter rather than a style guide, and takes direction from a DESIGN.md you write.

For everything that is not code, the prose and interface half of this problem has its own tooling, sorted by which failure it fixes, in the guide to unslopping AI output. The most installed of those tools gets its own breakdown in the Humanizer skill, explained. Every tool named across both pages has a row in the directory of Claude and agent skills.

What none of this fixes

A rule can see that a comment restates the code. It cannot see that the function is solving the wrong problem.

That is the ceiling on the entire category, and it is worth being clear about because the tooling keeps implying otherwise. Every check described here operates on the shape of the code. None of them can tell you whether the change should have been made, whether the abstraction matches the domain, or whether the test asserts anything that would fail if the feature broke. Those are review questions, and the research above says review is exactly where the capacity has gone.

The uncomfortable conclusion is that the tools help most with the part that was already cheapest to catch, and help least with the part the papers identify as the actual cost. A linter buys back reviewer attention. What that attention gets spent on is still a judgment call, and that judgment is the thing being eroded.

Frequently asked questions

What is AI slop in code?

Generated source that compiles, passes the linter and reads cleanly, but makes claims the code cannot support: a comment restating the line below it, a catch block that swallows an error, a guard against a state the type system already rules out, a value widened then asserted back into a narrower shape. None of these are bugs on the day they land. The cost is paid later by whoever reads the code.

Is AI-generated code less secure?

The 2025 preprint AI Code in the Wild found that certain CWE families are overrepresented in AI-tagged code across more than 7,000 CVE-linked changes, and that near-identical insecure templates recur across unrelated projects that share a model rather than a maintainer. It also found that when review is shallow, AI-introduced defects persist longer, stay exposed on network-accessible surfaces and spread to more files and repositories. The mechanism is propagation through shared model weights, which has no version number and no advisory.

Where does AI-generated code actually end up in a codebase?

Measured across development commits from the top 1,000 GitHub repositories between 2022 and 2025, adoption is structured rather than uniform. Generated code concentrates in glue code, tests, refactoring and documentation, while core logic and security-critical configuration stay mostly human-written. Teams are not handing over the parts they are afraid of.

What do developers say the biggest problem with AI slop is?

Not output quality. In a hand-coded analysis of 1,154 Reddit and Hacker News posts, the most frequent theme was structural-drivers at 256 codings, covering the systemic incentives that reward producing volume. ai-limitations followed at 227 and slop-mitigations at 226, and those three accounted for 44.2 percent of all 1,603 codings. The top complaint is a management problem, not an engineering one.

How do you stop AI slop in pull requests?

The mitigations developers report are procedural: cap pull request size, with one practitioner quoted at under 500 lines of code per PR, require the author to self-review before peer review, run synchronous code walkthroughs, and use dual reviews with an outside team. Each deliberately adds friction for the author to protect the reviewer. Pair them with one deterministic check in the build, such as an Oxlint rule set, so enforcement does not depend on a reviewer having a good day.

Are agent-authored pull requests really merged faster?

One 2026 study of public GitHub activity found agent-authored pull requests are reviewed less often, merged several times faster and discussed less than human-authored ones. The same paper states that the direction of those trends flips under different but equally defensible analysis choices, so the traces show that something is changing without showing why. Treat the number as a prompt to look at your own repository, not as an established effect.

The bottom line

The measurements agree with each other and disagree with the marketing. Generated code is concentrated in the low-risk parts of a repository, which is the good news. It carries insecure patterns that propagate through shared models rather than shared dependencies, which is a genuinely new failure mode. And the thing developers complain about most is not the code at all, it is the incentive to produce more of it.

If you take one action, put a deterministic rule set in the build so the cheap failures stop reaching a human. If you take two, cap the size of a pull request. Both move the cost back toward the person creating it, which is the only intervention any of this research supports.

Sources

Baltes, S., Cheong, M., and Treude, C. (2026). “An Endless Stream of AI Slop”: How Developers Discuss the Burden of AI-Assisted Software Development. arXiv preprint 2603.27249v4, 28 August 2026 (preprint, not peer-reviewed). https://arxiv.org/abs/2603.27249

Agarwal, S., Miller, C., Kästner, C., and Vasilescu, B. (2026). 3100 Opinions on Code Review in an AI World: Building Causal Theory from Practitioner Discourse. arXiv preprint 2607.07980, 8 July 2026 (preprint, not peer-reviewed). https://arxiv.org/abs/2607.07980

Wang, B., Yu, W., Zhong, Y., Yu, H., Lian, K., Lu, C., Zheng, H., Zhang, D., and Li, H. (2025). AI Code in the Wild: Measuring Security Risks and Ecosystem Shifts of AI-Generated Code in Modern Software. arXiv preprint 2512.18567, 21 December 2025 (preprint, not peer-reviewed). https://arxiv.org/abs/2512.18567

Mulroy, D. (2026). anti-slop: opinionated Oxlint rules for rejecting low-evidence TypeScript and JavaScript patterns (documentation and rule source). https://github.com/dmmulroy/anti-slop

O’Malley, P. (2026). desloppify: agent harness for reworking generated code (documentation). https://github.com/peteromallet/desloppify

Badjuber, M. (2026). anti-slop: rules for an AI coding agent to filter out generic AI-generated UI, text and code (documentation). https://github.com/miqdadbadjuber/anti-slop

GitHub API (2026). Repository star counts and last-commit dates for the tools named above, retrieved 17 September 2026. https://docs.github.com/en/rest