• "I built a mobile app with no coding experience."
• "I cloned Spotify in a weekend."

A lot of people online would call these slop. I would too. But while most of the discourse focuses on the quality of the code, I think that misses the point. The real issue is upstream of the code entirely.

Building something and deciding what's worth building are fundamentally different activities. AI has made the first massively cheaper and faster. It hasn't touched the second at all. And that gap - between the ability to produce and the ability to judge what's worth producing - is where slop comes from.

The Friction Filter

When building software was expensive, friction did a lot of invisible work. If it took a team of five engineers three months to ship something, the idea had to survive a gauntlet before anyone wrote a line of code. Someone had to believe in it enough to fund it. A product manager had to scope it. Designers had to think about who would use it and why. The sheer cost of execution acted as a filter - not a perfect one, but a real one.

A competent execution of an okay idea could still find an audience simply because fewer things existed. If your note-taking app was fine, and there were only a dozen others, "fine" was enough.

That world is gone. AI didn't just lower the cost of building - it removed the filtering pressure that cost provided. Now anyone can spin up a note-taking app in a weekend. Or a habit tracker. Or a portfolio site. Or a clone of something that already exists but slightly worse. The constraint that used to kill mediocre ideas before they shipped has largely evaporated.

What Slop Actually Is

This is why I think "slop" is the wrong framing when it's applied to code quality. An AI-generated codebase with messy abstractions and no test coverage isn't slop because the code is bad. It's slop because nobody asked the hard questions before the code was written.

Is this fun? Will people use it? Does this solve a problem someone actually has? Would anyone pay for it? Is there anything here that couldn't be replaced by the next person with an LLM and a free afternoon?

Take video games as an example. AI can help you build one quickly - maybe even impressively quickly. It can generate assets, write boilerplate game logic, scaffold levels. But "fun" is not a property of code. Fun is the result of hundreds of small design decisions that require taste, playtesting, and an understanding of what makes a player want to keep going. The games that matter - the ones people remember and recommend - weren't great because they were well-engineered. They were great because someone had a vision for an experience and made thousands of judgment calls to realize it.

AI doesn't make those judgment calls. It produces output. The judgment about whether that output is worth anything still comes from you.

The Disappearing Middle

For people working in software, I think the uncomfortable implication is that the middle is getting thinner. There used to be a large, comfortable space where you could build a career on competent execution of well-understood problems. Translate a spec into working code. Implement a CRUD app. Stand up a standard infrastructure stack. That work isn't disappearing overnight, but it's becoming less defensible by the month.

This isn't just a junior developer problem, either. A senior engineer whose primary value is "I can build what you describe, reliably and on time" is in a more precarious position than they might think. That's exactly the kind of work AI is getting good at. The leaky abstractions and edge cases still require human judgment today, but the trend line is clear.

What's harder to automate - and what I think becomes the primary differentiator - is the ability to figure out what should be built in the first place. Product sense. Taste. Understanding users well enough to know which of their stated needs are real and which are noise. Spotting a genuine problem or niche before it's obvious. Knowing when to say no to a feature that's technically easy but strategically wrong.

These skills were always important. Experienced developers have always known that the best engineers aren't just fast coders - they're the ones who push back on the wrong spec, who simplify the requirements before implementation starts, who have an instinct for what will matter six months from now. But when building was expensive, you could get by without those skills as long as you were technically strong. The cost of production provided enough cover.

Where This Leaves Us

I don't think this is all doom and gloom. If anything, the devaluation of pure execution is clarifying. It forces a more honest accounting of where human value actually lies in the software development process.

If you're a developer, the question isn't "can I build this?" - that's increasingly a given. The question is "should this be built, and am I the person who can see why?" The developers who thrive in a world full of slop won't be the ones who produce the most code. They'll be the ones who produce the least unnecessary code - because they understood the problem well enough to know what was actually needed.

The irony is that in a world where anyone can build anything, the scarcest skill isn't building. It's knowing what's worth building. Slop isn't a production problem. It's a taste problem. And taste, for now at least, is still ours.