What 264,000 Scans Say About AI-Generated Code Quality
Most AI-generated code is fine. The interesting number is not the average, it is the steady minority of edits that quietly take something with them.
Arguments about AI-generated code quality usually run on anecdote. Someone posts a bad diff, someone else posts a good one, and the thread relitigates whether agents can write software at all.
In August, aislop ran 264,290 scans. Two datasets came out of that, measuring different things, and together they say something more specific than either side of that argument.
1. Six in ten repository scans found something
17,434 developers ran 110,941 full repository scans. 59.7% surfaced at least one issue. Narrowing to the patterns coding agents specifically leave behind, narrative comments restating the code below them, swallowed exceptions, unsafe casts, duplicated helpers, 40.1% of scans turned up at least one. 15.5% turned up a security finding.
What it means: a scan of a working repository usually finds something worth removing. What it does not mean: that 40% of AI-generated code is bad. A finding is one flagged line, not a broken feature, and the median repository still scored 99 out of 100.
2. One in eight agent edits left the file worse
The second dataset is narrower and more direct. 153,349 scans fired from agent hooks, which run automatically the moment a coding agent finishes writing a file. That is a sample of AI-generated code at the instant it is written, before any human has read it.
56,482 of those scans had a previous score to compare against. Among them, 12.3% scored worse after the edit and 2.5% scored better. The remaining 85.3% were unchanged. So an agent edit was roughly five times more likely to degrade the file it touched than to improve it.
What it means: quality drift from agent edits is real, measurable and one-directional. What it does not mean: that agents make code worse on average. The median edit scored 100. Most were clean.
3. The denominator matters more than the percentage
Of the 153,349 hook scans, 96,867 had no previous score to compare against, usually because it was the first time that file had been scanned. Quoting 6,934 regressions against the full 153,349 would give 4.5% rather than 12.3%, understating the rate by more than half.
This is the most common way a statistic like this gets mangled, including by the person who collected it. The rate is only meaningful against edits where a before and an after both exist.
4. The problem is volume, not accuracy
Take the two datasets together. Most edits are fine. A small, steady fraction is not. At the scale agents now operate, that fraction stops being a rounding error.
121 developers generated 153,349 hook scans in a single month, a median of 230 each. Nobody reviews 230 edits a week line by line, and nobody reviews 153,000 of anything. The failure mode is not that agents write bad code. It is that the volume outran the review, so a minority pattern accumulates unread.
What this data cannot tell you
Four limits worth stating plainly.
The sample is self-selected. Every repository here belongs to someone who chose to install a code quality tool. That group is not representative of all software, and probably skews toward people who already care about this.
Hook scans only cover touched files. That is why the median hook scan scores 100: a single edited file usually has nothing wrong with it. These numbers describe edits, not codebases.
One agent dominates the sample. 144,192 of the 153,349 hook scans came from a single coding agent. The others are too small to compare fairly, which is why no league table appears here.
A score is not a verdict. aislop measures deterministic, nameable patterns. It cannot tell you whether the feature is correct, the architecture is sound, or the code should exist at all. Those remain human questions.
Method
All figures are August 2026, from anonymous CLI telemetry. It is on by default and can be disabled with AISLOP_NO_TELEMETRY=1 or DO_NOT_TRACK=1, so the totals are a floor rather than a ceiling. It records a score, a finding count, a file count bucket and an anonymous install identifier. It never records source code, file names or repository names.
The hook figures are distributed rather than concentrated: 121 developers, a median of 230 scans each, with the single heaviest accounting for 10.1% of the total.
Run the same scan on your own repository with npx aislop@latest scan, or read how the score is computed.
Frequently asked questions
How often does AI-generated code contain quality issues?
In August, 40.1% of repository scans turned up at least one AI-slop pattern and 59.7% turned up at least one issue of any kind. That is a sample of repositories belonging to people who installed a code quality tool, not a random sample of all software.
Do AI coding agents make code worse?
Usually not. The median agent edit scored 100 out of 100 on the files it touched. But among the 56,482 edits with a previous score to compare against, 12.3% scored worse afterwards and 2.5% scored better, so an edit was about five times more likely to degrade a file than improve it.
What are the most common AI slop patterns?
Narrative comments that restate the code below them, swallowed exceptions, unsafe type assertions, duplicated helpers and dead imports. aislop groups these under its ai-slop engine, which fired on 40.1% of repository scans.
Where does this data come from?
Anonymous telemetry from the aislop CLI, which is on by default and can be disabled with AISLOP_NO_TELEMETRY=1 or DO_NOT_TRACK=1. It records a score, a finding count and a file count bucket. It never records source code, file names or repository names.