AI Slop Is a Communication Problem

Slop is a communication problem, and it was sitting inside the delivery process long before anyone opened a coding assistant. AI just makes it harder to pretend the process was ever clean.

A lot of teams still plan software the way they always have. A group of senior people get in a room, talk through the idea, and nod at the same time, and everyone leaves believing the thing is understood. At the level of the idea, it probably is. Software gets built somewhere else, though, in the thousands of small details nobody said out loud, like how errors are represented, where retries happen, and all the strange little scars a platform picks up over time. The meeting produced agreement about the idea and none at all about the implementation.

Then the work gets translated into tickets. Sometimes they stay at the epic level, and sometimes, if someone puts in extra effort, they get down to stories with acceptance criteria, designs, and a few examples. Then they get handed to engineers.

Give one of those tickets to the engineer who started six weeks ago. They know the language, the framework, and how to search the codebase, and they may even use AI well. What they don't know is the invisible system. Nobody told them this team never puts business logic in controllers, or that the service layer exists because three other teams depend on its behavior, or that one package is technically allowed but culturally banned because it caused production pain before they joined. They don't know the Angular app follows a very specific layout because that's how the team keeps feature ownership clear, or that "just add a helper" is how the last codebase turned into a junk drawer. So they guess. AI guesses too, and the guesses are often wrong, and that's when someone looks at the output and says, "This is AI slop."

Maybe it is, but the more honest phrase is human slop. The team never wrote down how it wants code structured, where the boundaries are, or what it learned from the last few failures, at least not anywhere a new engineer or an AI assistant could find it. It was depending on senior people to fill the gaps.

That works until the senior person isn't the one doing the work. The ticket moves to a junior engineer, or the team reorganizes, or the person with all the context is on vacation or tired of being interrupted every fifteen minutes. It works even worse with AI, because an assistant can't lean over a desk and ask the one person who remembers why the service layer exists.

Valid Objections, Stopped Too Early

The frustrating part of the AI conversation is how many engineers raise completely valid objections and then stop halfway. They don't trust AI-generated code, and they shouldn't trust it blindly. They want to understand what the code is doing, which is correct, since they're still accountable for what they ship. And when they say AI doesn't know our architecture, they're exactly right. So teach it.

Too many engineers stop at the risk and treat it as a reason to avoid the tool entirely, which is avoidance dressed up as craftsmanship. Apathy isn't a strategy, and neither is fear.

Meanwhile, companies have already bought the idea that AI improves productivity, and plenty of executives hear "AI productivity" and imagine cheaper output. Engineers hear the same phrase and picture a flood of garbage pull requests from people who no longer understand the code. Neither group is asking what the tool needs to be told before it can do good work.

Treat AI Like Delegation

AI is useful when you treat it like delegation. If you handed work to another engineer, you wouldn't just say "build the thing" and then act shocked when they made different choices than you would have. At least I hope you wouldn't. You'd explain the goal and the constraints, point them at examples of the patterns you want, and review and test what came back. Working with AI isn't much different.

AI is more literal than a person in some ways and more slippery in others. It moves quickly, but it doesn't carry your organization's lived experience unless you hand it over, and it imitates common patterns when what you need is your patterns.

Some frameworks are opinionated. Angular gives you a lot of structure and pushes you toward certain patterns and away from others, which doesn't solve every problem but does cut down the number of decisions each developer has to invent. Other frameworks and libraries hand you tools without a house style. That flexibility has value, and it also leaves room for every engineer to bring their own habits, so one person organizes code by feature and another by technical layer, one wraps everything in service abstractions while another keeps logic next to the caller, and one picks a dependency because it's popular while the person at the next desk remembers the team rejecting it three years ago for good reasons. AI has no way of knowing which camp you're in.

Left unspecified, AI reaches for an average approach borrowed from the broad soup of examples it has seen. Sometimes the average is fine and sometimes it's exactly what you hate, and then someone says, "Look at this garbage."

But what did you ask for? Did you tell it where abstractions belong and when not to create a new one, or what belongs in a controller versus the service layer? Did you say which dependencies are preferred and which are forbidden, or give it an example from your own codebase of what good looks like? If not, the model guessed, the way people do. When a human guesses we tend to call it initiative, and when AI guesses we call it slop.

We Stopped Writing the Standards Down

Years ago, teams spent more time on code style guides, and I mean the kind that explained how code should be written in a particular system, well beyond formatting rules. Where does validation live? How should errors be represented? When do we create an interface, and when do we avoid one? What should a unit test prove that an integration test doesn't? How do we name things so another engineer can follow the trail six months later?

Somewhere along the way, many teams stopped writing those answers down. Senior engineers carried the standards in their heads, code review was supposed to catch the rest, and new people were expected to learn by osmosis. That was always expensive, and AI just sends the invoice faster.

A Prompt Is an Engineering Interface

If you want better code out of AI, stop treating prompts as magic spells and start treating them as engineering interfaces. A prompt is a handoff, a coding agent instruction file is a style guide, and a repository guide is an onboarding document. The test suite is the contract. A pull request is a request for the build pipeline to verify that the work fits, which is a long way from proof that the work is done.

The productivity gains come from building a working environment where the tool has enough context, constraints, and feedback to contribute something useful, and asking AI to write the feature while hoping for the best won't get you there. That means writing the boring documents nobody wanted to write and building examples of the patterns you want. It means listing the dependencies you prefer and the ones you've banned, and putting architectural decisions somewhere other than the memory of the most experienced person on the team. It means tests that fail when the wrong behavior shows up, and validation that doesn't depend on one tired senior engineer staring at a pull request at 5:37 p.m.

AI Rewards Explicit Systems

The teams that get good results from AI will be the ones that already know how to make work clear. They define done, capture decisions where people can find them, and review code without relying on vibes, while other teams yell better prompts into the void. AI rewards explicit systems and punishes vague ones.

That's uncomfortable, because a lot of software organizations run on vague ownership, vague standards, and acceptance criteria that could mean anything. Experienced engineers paper over it. They notice when a ticket is missing something, they know who to ask, and they know which part of the codebase lies. That skill is valuable, and it's also a bottleneck, because you can't scale heroics and you can't scale context that lives in one person's head. If every good outcome depends on a senior engineer quietly correcting the work as it moves through, the process is weaker than it looks, and AI exposed that weakness without creating it.

So the phrase "AI slop" is often too generous to the humans involved. It suggests the machine polluted a clean process, when the process was usually dirty already, with thin instructions, tribal standards, and an architecture that lived more in memory than in documentation. Then AI walked in and behaved like any new contributor with incomplete context, filling gaps, sometimes badly, that shouldn't have been gaps in the first place.

AI Does Not Remove Accountability

None of this lets engineers off the hook when they use AI poorly. If you paste AI-generated code into a codebase without understanding it, or ship code you can't explain, or let the tool invent the architecture because you were too lazy to define one, that's on you. AI makes accountability matter more.

The code still has your name on it, and the pull request still belongs to you. The production system still has to run after the code ships, and the customer doesn't care whether the bug came from your fingers, your teammate, or your AI assistant.

So use AI, own the output, and quit pretending speed is the same thing as quality. Define the context, write the standards down, and test the behavior.

If you don't like the code AI produces, ask what a good human engineer would need to know before doing the same work, then write that down in the repository, the agent instructions, or the ticket template. The next person to read it might be someone you hired last month, you six months from now, or an AI tool, and every one of them needs the hidden system made visible. That's worth doing with or without AI in the picture. AI is just the thing that finally made us admit how much of our engineering process runs on memory and informal correction.

Most AI slop is a process failure wearing a shiny new costume. If that makes people mad, good, they should be a little mad. I'd just rather they aim it at the system around the tool, starting with the habit of expecting AI to infer the culture of a codebase from a vague ticket and wishful thinking.