DEV Community

Cover image for AI Didn't Invent Slop. It Only Made It Infinite.
Don Johnson
Don Johnson Subscriber

Posted on

AI Didn't Invent Slop. It Only Made It Infinite.

The shift from writing to vetting code

Every generation believes it is witnessing the death of taste.

The printing press was going to flood the world with trash. The cheap camera was going to destroy photography. The internet was going to drown serious thought in blogs, forums, spam, and noise. Smartphones were going to turn every sacred moment into a blurry rectangle.

Now artificial intelligence, we are told, has brought us to the final collapse: endless images, endless songs, endless essays, endless pull requests that compile and ship and mean nothing.

We call it AI slop.

And to be fair, much of it deserves the name.

You can feel it when you see it. The over-polished fantasy portrait. The too-perfect lighting. The fake article that says everything and means nothing. And if you write software: the 600-line PR that passes CI and no human can explain. The README generated by a machine that has never run the code. The test suite with 100% coverage that asserts only that the mock returned the mock.

It is work nobody will remember making.

It has texture but no conviction. Output, but no memory of why.

But AI did not invent slop.

It only made it infinite.

We Have Been Here Before

There was a time when a photograph meant something simply because it was difficult to make.

A camera was not just an object. It was a ritual. Film had to be bought. Shots had to be chosen. Light had to be respected. Mistakes cost money. The photographer carried the burden of scarcity.

Then cameras became cheap, then digital, then they entered every pocket on Earth. Suddenly, humanity became a species of photographers. We photographed lunch, and mirrors, and sunsets we barely watched. We created billions of images, most of them forgotten before the day ended.

Photography did not die.

But the average photograph became meaningless.

That distinction matters. The medium survived. The scarcity did not.

No one calls it "camera slop," but perhaps we should have.

Slop Is What Happens When Creation Becomes Cheap

This is the uncomfortable truth underneath the AI panic:

Whenever the cost of creation collapses, the volume of mediocre work explodes.

That is not a flaw unique to artificial intelligence. It is one of the oldest patterns in media history — and it has names. Sturgeon's Law already told us that ninety percent of everything is forgettable. What changes, across eras, is only how cheaply we can manufacture the ninety percent.

When printing became cheaper, the world got pamphlets, propaganda, gossip sheets, and disposable novels. When desktop publishing arrived, everyone became a designer. When blogging platforms arrived, everyone became a columnist. When GitHub made it trivial to publish code, every weekend produced ten thousand repos that would never see a second commit.

Every tool that democratizes creation also democratizes mediocrity.

That sounds cruel, but it is not. It is simply math. When the gates open, more people enter. Most are beginners. Many are opportunists. Some are brilliant. The room gets louder before it gets better.

AI is not breaking that pattern. AI is accelerating it.

Slop Is a Taste Crisis, Not a Technology Crisis

The real danger of AI slop is not that machines can make things.

The danger is that humans may stop caring whether the things are worth making.

That is the disease. Not automation. Indifference.

Slop is not defined by the fact that AI was used. It is defined by the absence of intention. A human can make slop with a camera. A human can make slop with a paintbrush. A human can make slop with vim and forty years of experience and a million-dollar budget.

Slop is not a medium. Slop is a relationship to creation.

It is what happens when the goal is output instead of meaning. Velocity instead of correctness. Shipped instead of understood.

The machine did not create that hunger. The machine simply feeds it faster.

The System Loves Slop

Slop thrives because the systems around us reward frequency.

Merge faster. Chase the metric. Bump the contribution graph. Worship the green build. Close the ticket. Remove the silence where thinking used to live.

AI fits perfectly into this economy because AI is tireless. It does not sleep, or get bored, or stare at a failing test for three days before finding the one assumption that was wrong from the start.

The pipeline wants endless output. AI can provide it.

That marriage — between machine generation and a culture that measures motion instead of meaning — is where slop becomes industrial. Not because AI is evil. Because infinite production met infinite distribution, and nobody in the middle asked whether any of it mattered.

Copilot Did Not Make You an Engineer

A cheap camera allowed anyone to take a picture. It did not make everyone a photographer.

A laptop allowed anyone to make music. It did not make everyone a musician.

A blog allowed anyone to publish. It did not make everyone a thinker.

Copilot lets anyone generate working code. It does not make everyone an engineer.

This is where the confusion begins. We keep mistaking access for mastery.

The tool can produce the surface of a thing. It can mimic the genre, satisfy the linter, pass the tests it also wrote. It can imitate the grammar of competence.

But engineering is not merely code that runs.

It is selection, restraint, and the refusal to write the clever abstraction that will rot in eighteen months — even though the model offered it, ready to paste, today. It is a human being deciding that one design matters more than another and being able to say why.

AI can generate a thousand implementations in an hour.

The engineer is the one who knows which one should not exist.

The Scarce Resource Was Never the Tool

For decades we confused engineering value with the difficulty of execution.

The person who could write tight assembly possessed rare power. The person who could wrangle pointers, or hold a distributed system in their head, or make the build green, possessed rare power.

But technology has a way of eating technique. Again and again, the machine absorbs what once required years of specialized execution. And every time, people panic and say the craft is dead.

But the craft is not dead. It moves.

When execution becomes easier, taste becomes more important. When production becomes abundant, judgment becomes more important.

When everyone can generate a pull request, the real question becomes: who can read it? Who can see the load-bearing line? Who can look at infinite plausible code and say, "Not that. This."

But Abundance Is Not the Enemy of Craft

Here is the part the optimists get right and the part they get wrong.

The right part: every explosion of mediocrity also expands the possibility of genius. Cheap cameras gave us billions of forgettable images — and handed visual language to people who would never have entered a photography school. Home studios created oceans of bad music — and gave us bedroom producers who reshaped global sound. The early web buried us in spam — and also gave us Linux, Wikipedia, and Stack Overflow, each built from the same flood of amateur contribution that produced the junk.

Democratization tends to move in waves. The first wave is noise. The second is imitation. The third discovers what the medium is actually for.

The wrong part — the part the optimists wave away — is that the third wave is not guaranteed. Plenty of ecosystems hit the noise wave and simply stayed there, or died: local newspapers did not ascend to some higher form, they collapsed and did not come back. "It worked out before" is not a law of nature. It is a bet. The honest claim is narrower: abundance makes a better equilibrium possible. It does not deliver one. Someone has to do the choosing.

But Won't the Machine Just Do the Choosing Too?

This is the strongest objection to everything above, so let's not dodge it.

Every earlier democratization left one thing untouched: a human layer that decided what was good. The press multiplied books, but humans still chose what to read. The camera multiplied images, but humans still chose what to hang on the wall. The scarce resource could shift to judgment precisely because judgment stayed ours.

AI attacks both sides of that deal at once. It floods faster than any reviewer can read — and it is being trained, right now, to do the reviewing: to rank, to critique, to pick the better of two diffs. If the machine can write the thousand implementations, why can't it choose the one that should exist?

Partly, it can. Taste is not magic. Much of it is pattern, and patterns are trainable. An honest version of this argument has to concede that "humans simply judge better" is a moat that will not hold — the same way "humans simply write assembly better" did not hold.

But there is a remainder, and it is not a skill. It is accountability.

Someone has to be the one who says ship it and owns what comes next — the outage, the breach, the regression that reaches a million users, the quiet harm nobody modeled. A system can rank the options. It cannot be answerable for the choice. The engineer who clicks merge is not just exercising sharper judgment than the generator; they are the human a consequence can attach to.

So the moat is not "we judge better." That one erodes. The moat is "we are responsible." Discernment is the craft you sharpen. Accountability is the part the machine structurally cannot take, because responsibility requires someone who can actually be held to it.

The Engineer Becomes an Editor of Infinity

The next great technical skill may not be generation. It may be discernment exercised under that responsibility.

We already have a name for the work: review. And it is moving from the chore at the edge of the job to the center of it.

Watch what AI does to a team. It lifts a junior's output to senior-looking quality almost overnight — clean, idiomatic, plausible. It does not lift their judgment at the same rate. So the senior becomes the bottleneck, reviewing an infinite stream of confident, well-formatted diffs from people (and models) who cannot yet see what is wrong with them. "LGTM" stops being a rubber stamp and becomes the most dangerous sentence in the codebase. The reviewer becomes the rate limiter on quality for the entire organization.

That is the job now. Not typing faster. Reading better.

The engineer of the next decade is part architect, part editor, part skeptic — someone who can run the machine without serving it, who generates without limit, then cuts without mercy. Someone with memory. Someone with scars from the last system that paged them at 3 a.m.

Because when any code can be written instantly, the most valuable thing you can do is refuse to merge most of it.

Slop Is the Shadow of Democratization

AI slop is real. It is everywhere — feeds, marketplaces, search results, issue trackers, and the diff you have to review this afternoon.

But it is not an alien substance. It is the shadow that appears whenever creation becomes easier than judgment. Scarcity used to do some of our filtering for us: difficulty kept the repo smaller, cost slowed people down, the sheer friction of writing it yourself meant you mostly wrote what you meant. Now that friction is gone, and the burden shifts back to us. We have to decide what matters.

The cheap camera did not destroy photography. It destroyed the illusion that every photograph was precious. AI will not destroy engineering. It will destroy the illusion that every act of generation is creative.

And maybe that is necessary. Maybe we are being forced to admit what was always true: the magic was never in the tool. The magic was in the seeing and the choosing — in taking the chaos of a problem and shaping it into something that says:

I was here. I understood this. This mattered.

In the age of infinite slop, that may become the rarest thing of all.


Notes on the Argument

This is a historical argument, not a technological one, and it is a synthesis rather than a discovered law — so here is the lineage it rests on, made explicit so you can check it:

  • Sturgeon's Law — "ninety percent of everything is crap." The baseline claim that most output in any field is forgettable. (ref)
  • Clay Shirky's "mass amateurization" — when you remove the barrier to publishing, you don't get less junk, you get "publish, then filter": the filtering moves downstream, onto the reader. This essay's "engineer as editor" is that filter, relocated to code. (ref)
  • The Jevons paradox — making something cheaper to produce raises total consumption rather than lowering it. Cheaper creation means more creation, not less — now widely invoked for AI. (ref)

The concrete parallels are well documented: the printing press produced a flood of cheap Reformation pamphlets alongside its enduring works (ref); consumer and smartphone photography pushed the world past a trillion-plus photos a year (ref); desktop publishing democratized design (and gave us the "ransom note" era), while content farms like Demand Media industrialized algorithmic filler until Google's Panda update was built to bury it (ref).

The argument deliberately holds two ideas at once: democratization of creation (good — more people gain the tools) and a decline in average quality (the expected cost when participation grows from thousands to millions). They are complementary, not contradictory. Reasonable people can disagree with where it lands. The point is to offer a frame for the debate, not to claim it is settled.

A Note on Collaboration

This essay was written through a collaboration between a human author and AI. The ideas, the thesis, the structure, and every editorial decision came from a human; AI was used as a thinking partner and drafting tool, and the historical claims above were checked against the sources cited.

Writers have always worked with tools — editors, dictionaries, research assistants, cameras, compilers, spell checkers, search engines. AI is another one, albeit a remarkably capable one. The quality of a work has never been determined solely by the sophistication of the tool that helped make it. It has always been determined by the quality of the thinking behind it.

Judge this essay by its reasoning. Not by the instrument used to write it.

(Disclosed per DEV's guidelines for AI-assisted articles.)

Top comments (9)

Collapse
 
julianneagu profile image
Julian Neagu

I build with AI every day and this matches what I've seen. Generating code is cheap now. Reading it slowly is where most of the work has moved.

Collapse
 
nazar-boyko profile image
Nazar Boyko

I'm with you right up to the accountability turn, and that's the one spot I want to lean on a little. Saying the human is the one a consequence can attach to is true, but it only means something if that human can actually read what they're signing off on. The same flood that makes review the center of the job is also what makes real review impossible at the volume the machine produces. So "someone who can be held responsible" risks becoming someone who rubber-stamps at scale and carries the blame anyway, which is accountability in name only. The honest version might be that the scarce skill isn't judgment or responsibility on its own, it's keeping the generation slow enough that a responsible human can still keep up.

Collapse
 
copyleftdev profile image
Don Johnson

You're right, and this is the objection that actually bites — accountability without comprehension is liability theater. If I can't read what I'm signing, then "the human a consequence attaches to" is just someone who rubber-stamps at scale and eats the blame anyway. No argument there.

Where I'd refine it rather than just accept it: accountability has two halves, and rubber-stamping is what's left when you keep one and lose the other — the liability (you own the breach) and the authority (you decide what merges). The rubber stamp is accountability with the veto amputated: all blame, no power to refuse. Held properly, the responsible human's defining act isn't reading faster — it's refusal.

And that's where I'd push on your fix. "Keep generation slow enough that a human can keep up" assumes you control the generation rate — but you usually don't; the market, the next team, the competitor sets it. The throttle that's actually in your hands is the merge gate, not the generator. So I'd put the scarce skill in the authority to refuse, not in slowing production: refusal you can always exercise; slowing the firehose often isn't yours to pull.

The instruments are what keep that gate from becoming the new bottleneck — mutation testing, deterministic sim, adversarial fuzzing raise how much you can legitimately wave through, so the gate isn't just "no," it's "no, unless it proves itself." That's not hand-waving: we broke a financial solver 1.1 billion times with deterministic simulation. No human reads a billion paths — but a responsible one can stand behind the machine that did. Which lands us in the same place from opposite sides: you call it keeping pace, I call it earning the right to merge faster. You just named the half I'd underweighted.

Collapse
 
vollos profile image
Pon

The line about review moving to the center matches what I see, but I'd sharpen one edge of it from the security side. The slop we're trained to catch announces itself: the 600-line PR, the coverage that only tests the mock. Ugly reads as "look closer." The AI output that scares me does the opposite. A policy that says USING (TRUE) reads as "good, they added access control." A view that exposes every user's email reads like a deliberate choice. It's tidy, it passes review, and the bug isn't in how the code reads, it's in what it permits once it's running. So "read better" holds for most of it, but there's a class where the diff just doesn't contain the finding, and a reviewer calibrated on "ugly means danger" is pointed the wrong way for the code that's dangerous because it's clean. Which sharpens your accountability point rather than softening it: whoever clicks merge owns a breach they had no way to see by reading.

Collapse
 
copyleftdev profile image
Don Johnson

This is the sharpest thing anyone's added — and the best sign you're onto something real is that you've independently re-derived something I wrote up a few weeks back. I called it "Beautifully Broken": the assumption stack doesn't announce itself, and that's exactly what makes it dangerous.

Collapse
 
vollos profile image
Pon

Going to read Beautifully Broken -- sounds like you named the thing I was circling. What ties it back to your instruments argument: the clean-but-dangerous class is exactly the one "read better" can't reach, because the finding isn't in the text, it's in what the text permits once it runs. So it's the strongest case for your "no, unless it proves itself" gate -- you can't eyeball whether USING (TRUE) is wrong, but a test that tries to read another tenant's row either comes back empty or it doesn't. The diff stays quiet; the runtime doesn't. Reading harder won't surface it; exercising what it permits will.

Collapse
 
headzoo profile image
Sean H

Reminds me of the criticisms against PHP, due to the large number of poorly written tutorials and real world code. There was nothing inherently wrong with PHP, but it did lower the barrier to entry to call oneself a programmer, which led to a flood of poorly written code.

Collapse
 
copyleftdev profile image
Don Johnson

Every generation has its "slop."

We had copy-paste PHP tutorials.
We had jQuery spaghetti.
We had Flash intros.
We had WordPress plugin hell.

None of those technologies were the problem—they simply lowered the barrier to participation before the ecosystem matured.

AI is going through the same adolescence. The slop isn't the invention. The scale is.

Collapse
 
qjjy2004 profile image
zhibi

The real problem isn't that AI generates slop — it's that the distribution cost of slop dropped to zero. Before LLMs, producing garbage still required effort. Now any prompt can generate a 2000-word 'article' in 30 seconds. The bottleneck has shifted from creation to curation, and most platforms aren't ready for that.