The AI Slop Problem Nobody Wants to Admit

Open any pull request in 2026 and play a fun game: “Human or AI?” You’ll be wrong more often than you think, and that’s not the compliment to AI that people assume it is.

Because a lot of AI-generated code is slop. It works. It passes tests. It even looks clean. But it’s slop.

What AI Slop Looks Like

AI slop isn’t broken code. Broken code is easy to catch. AI slop is code that:

• Solves a problem that doesn’t exist. “Here’s comprehensive error handling for a function that’s only called internally with validated input.”
• Adds abstraction for the sake of abstraction. One function called once, wrapped in a factory pattern, with a config object, for “flexibility.”
• Handles every edge case except the one that matters. Beautiful input validation. Zero understanding of the actual business logic.
• Uses patterns from 2023. AI is trained on historical data. It’ll suggest deprecated approaches with confidence.

The worst part? It’s convincing. AI-generated code often looks more professional than what a human would write, because it follows patterns it’s seen in thousands of repos. But following patterns isn’t the same as understanding the problem.

The Terraform Example

I work with Terraform daily. Here’s what happens when you ask AI to write a Terraform module:

You get a module. It has variables with descriptions. It has outputs. It has a README. It looks textbook-perfect.

But then you notice: it hardcodes a sku that costs three times more than you need. It creates a public endpoint when your company policy requires private. It uses count where for_each would prevent state drift on deletion. And it doesn’t have a single lifecycle policy because the training data didn’t include your specific compliance requirements.

Does it work? Yes. Will it pass a basic review? Probably. Will it cost your company money and create a security finding? Absolutely.

The Real Problem: Volume

The issue isn’t that AI generates bad code. Humans do that too. The issue is volume.

Before AI, a developer might write 50-100 lines of questionable code per day. Now they can generate 500. Same percentage of problems, five times the output. That’s not productivity. That’s technical debt with a turbocharger.

I’ve seen teams where the PR queue tripled after adopting AI tools. Sounds great until you realize the review quality dropped because reviewers can’t keep up. So now you have more code, reviewed less carefully, deployed faster. What could go wrong?

How I Actually Use AI (Without the Slop)

Here’s what I’ve learned after a year of using AI tools daily:

1. Never accept the first output. AI’s first response is a rough draft. Treat it like one. If you wouldn’t push a colleague’s first draft without review, don’t push AI’s.

2. Delete more than you keep. I regularly delete 40-60% of what AI generates. The “helpful” error handling, the “just in case” validation, the wrapper functions. If I can’t explain why it needs to be there, it goes.

3. AI writes, you architect. Let AI handle the boilerplate. But the decisions - what to build, how to structure it, where to put the boundaries - those are yours. AI is a fast typer, not a designer.

4. Test the unhappy path. AI is optimized for the happy path. It’ll generate beautiful tests that all pass because they test the obvious scenarios. Write the weird ones yourself: what happens with empty input? With 10 million records? With a network timeout at exactly the wrong moment?

5. Read every line. Yes, every line. If you can’t review it, you shouldn’t ship it. “But it’s just boilerplate” - boilerplate with a wrong default value took down a production database at a company I won’t name. Read. Every. Line.

The Uncomfortable Truth

Most of us are generating more AI slop than we’d like to admit. I certainly have. I’ve pushed Terraform that AI wrote, found issues in production, and thought “I should’ve looked at that more carefully.”

The engineers who’ll thrive aren’t the ones who generate the most code. They’re the ones who can look at generated code and say: “This is wrong, and here’s why.” That requires understanding the system you’re building, not just the syntax you’re writing.

AI is a tool. A very good one. But a tool that makes it easy to produce mediocre work at scale is only as good as the person deciding what to keep and what to throw away.

So next time you generate 200 lines of infrastructure code in 30 seconds, ask yourself: would I mass-produce sandwiches I haven’t tasted? Because I used to run a sandwich shop, and I can tell you - the answer is no. You taste everything. Every time.

Your code deserves the same.

If this resonated, you might also want to read why the art of troubleshooting is disappearing and my honest take on using Claude Code daily.