One good measure is that in pre-AI world the person creating a piece of information normally used more time to create it than the person consuming it would need to consume it. Writing used to be slow, reading is fast.
So, when I see an AI wall of text without any editing, I assume that the author did not bother spending their time on it, but they want me to spend more of my time on reading it than they spent on creating it, and I refuse. Everyone has access to the same AI, and if I want to read AI generated text with little to no human author involvement, I'll go ask ChatGPT or Claude.
Same goes for GitHub slop PRs which are faster to create than to review.
So the issue it's then the lack of polishing, intention, drive, which again in every case of my list is the same irregardles of who does it.
On the other hand if there is no AI involved, but as another comment here mentions, before ai times, the ntfs driver that was not polished enough, then it's also slop.
> where does it start being slop and where is not?
Github/Gitea issue with feature request; typically not slop
Github/Gitea PR with AI-implimented feature; typically slop
The issue is almost always drive-by contributions. A lot of programmers don't care about dependency creep, SLOC management, SDLC nicities, fragile CI/CD or multiplatform testing. Many FOSS maintainers and core contributors have a much higher standard for what they're willing to merge, and therefore reject slop judiciously. Same goes for one-man-band vibe coding outfits that want to ship a half-assed "native" app and charge money for it. Most of these people don't understand what the industry considers standard, even with AI helping them.
FWIW, there were slop PRs even before AI. Famously Paragon's NTFS driver was so bad that Linux refused to merge it because the costs outweighed any potential benefits. It ultimately came down to a difference in culture between FOSS and closed-source development.
Human writing can often be more concise because humans are lazier and don’t want to expend unnecessary effort. An LLM does not care about word count.
One good measure is that in pre-AI world the person creating a piece of information normally used more time to create it than the person consuming it would need to consume it. Writing used to be slow, reading is fast.
So, when I see an AI wall of text without any editing, I assume that the author did not bother spending their time on it, but they want me to spend more of my time on reading it than they spent on creating it, and I refuse. Everyone has access to the same AI, and if I want to read AI generated text with little to no human author involvement, I'll go ask ChatGPT or Claude.
Same goes for GitHub slop PRs which are faster to create than to review.
So the issue it's then the lack of polishing, intention, drive, which again in every case of my list is the same irregardles of who does it.
On the other hand if there is no AI involved, but as another comment here mentions, before ai times, the ntfs driver that was not polished enough, then it's also slop.
> where does it start being slop and where is not?
Github/Gitea issue with feature request; typically not slop
Github/Gitea PR with AI-implimented feature; typically slop
The issue is almost always drive-by contributions. A lot of programmers don't care about dependency creep, SLOC management, SDLC nicities, fragile CI/CD or multiplatform testing. Many FOSS maintainers and core contributors have a much higher standard for what they're willing to merge, and therefore reject slop judiciously. Same goes for one-man-band vibe coding outfits that want to ship a half-assed "native" app and charge money for it. Most of these people don't understand what the industry considers standard, even with AI helping them.
FWIW, there were slop PRs even before AI. Famously Paragon's NTFS driver was so bad that Linux refused to merge it because the costs outweighed any potential benefits. It ultimately came down to a difference in culture between FOSS and closed-source development.