AI Slop Is a Communication Problem

AI slop is not primarily a technology problem. It is a communication problem, and more specifically it is a communication problem that already existed inside our software delivery process. 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, ask questions, challenge a few assumptions, and nod at the same time, and everyone leaves believing the thing is understood. At that level, it probably is understood. The problem is that software is not built at that level. It is built in the thousands of small details that were never spoken out loud: naming conventions, error handling, dependency choices, data boundaries, retry behavior, logging expectations, API shape, deployment constraints, ownership rules, and all the strange little scars a platform accumulates over time. The meeting creates agreement around the idea. It does not create agreement around the implementation.

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

Imagine one of those engineers started six weeks ago. They are smart, motivated, and they know the language, the framework, and how to search the codebase. They may even know how to use AI well. What they do not know is the invisible system. They do not know that this team never puts business logic in controllers, 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 do not know that the Angular app is supposed to follow a very specific layout because that is 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 make reasonable assumptions. AI makes reasonable assumptions too, and those assumptions are often wrong. That is 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 did not define the code structure clearly enough. It did not write down its architectural preferences, explain the boundaries, create useful examples, or preserve the hard-earned lessons from previous failures in a form that a new engineer, or an AI assistant, could actually use. The team was depending on senior people to fill the gaps.

That works until the senior person is not the one doing the work. It works until the work moves to a junior engineer, until the team changes, until delivery pressure increases, or until the person with all the context is out sick, on vacation, buried in meetings, or tired of being interrupted every fifteen minutes. It also works poorly with AI. That is not because AI broke the process. It is because AI removed the illusion that the process was ever explicit.

Valid Objections, Stopped Too Early

One of the more frustrating parts of the AI conversation is that many engineers raise objections that are completely valid but incomplete. They say they do not trust AI-generated code, and they are right, because you should not blindly trust it. They say they need to understand what the code is doing, and that is correct, because you are still accountable for the code you ship. They say AI does not know our architecture, and that is exactly right, so teach it.

That is where too many engineers stop. They identify the risk and then treat the risk as a reason to avoid the tool entirely. That is not discipline. That is avoidance dressed up as craftsmanship. Apathy is not a strategy, and fear is not a strategy either.

Companies have already bought into the idea that AI can improve productivity, but that does not mean every executive understands the real work required. Many hear "AI productivity" and imagine cheaper output. Engineers hear the same phrase and imagine a flood of garbage pull requests written by people who no longer understand the code. Both reactions miss the important part.

Treat AI Like Delegation

AI is useful if you treat it like delegation. If you handed work to another engineer, you would not just say "build the thing" and then act shocked when they made different choices than you would have. At least you should not. You would explain the goal and the constraints, point them to examples, tell them which patterns to follow and which to avoid, review the work, ask questions, and test it. Working with AI is not that different.

The difference is that AI is more literal in some ways and more slippery in others. It moves quickly, but it does not carry your organization's lived experience unless you provide it. It can imitate common patterns, but common patterns are not the same thing as your patterns, and that distinction matters a lot in software.

Some frameworks are opinionated. Angular, for example, gives you a lot of structure. It pushes you toward certain patterns and away from others, which does not solve every problem but does reduce the number of decisions each developer has to invent. Other frameworks and libraries are much looser. They give you tools, not a house style, and that flexibility can be valuable, but it also leaves room for every engineer to bring their own habits. One person organizes code by feature, another by technical layer. One creates service abstractions everywhere, another keeps logic close to the caller. One thinks a dependency is fine because it is popular, another knows the team rejected it three years ago for good reasons. AI will not magically know which camp you are in.

If you do not specify the structure you want, AI tends to reach for an average approach. It borrows from the broad soup of examples it has seen. Sometimes that average is fine, and sometimes it is exactly what you hate. Then someone says, "Look at this garbage." But what did you actually ask for? Did you tell it where abstractions belong, and when not to create a new one? Did you explain how controllers should be used and what belongs in the service layer? Did you say how interfaces should be shaped, which dependencies are preferred, and which are forbidden? Did you give it examples from your own codebase and explain what good looks like? If not, then the model guessed, which is not surprising, because that is what people do too. The difference is that when a human guesses we often call it initiative, and when AI guesses we call it slop. That double standard is convenient, but it is not useful.

We Stopped Writing the Standards Down

Years ago, teams spent more time on code style guides. Not just formatting rules, though those matter too, but real style guides that explained how code should be written in a particular system. Where does validation live? How should errors be represented? What does a good API boundary look like? When do we create an interface, and when do we avoid one? How should we organize tests, and what should a unit test prove versus an integration test? How do we name things so another engineer can follow the trail six months later?

Somewhere along the way, many teams stopped writing those things down. We replaced explicit guidance with oral tradition, let senior engineers carry the standards in their heads, assumed code review would catch everything, and assumed people would learn by osmosis. That was always expensive. AI just sends us the invoice faster.

A Prompt Is an Engineering Interface

If you want AI to produce better code, 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. A repository guide is an onboarding document. A test suite is a contract, and a build pipeline is a truth machine. A pull request is not proof that the work is done; it is a request for the system to verify that the work fits.

This is where the real productivity gains are. They are not in asking AI to write the feature and hoping for the best. They are in building a working environment where the tool has enough context, enough constraints, and enough feedback to make useful contributions. That means creating the boring documents nobody wanted to write, building examples that show the right patterns, and documenting the dependencies you prefer and the ones you do not want. It means explaining how your application is structured, making your expectations reviewable before the code exists, and putting architectural decisions somewhere other than the memory of the most experienced person on the team. It means writing tests that fail when the wrong behavior appears, and creating validation that does not depend on one tired senior engineer staring at a pull request at 5:37 p.m. This is not extra work. This is the work we were avoiding.

AI Rewards Explicit Systems

The teams that get good results from AI will not be the ones that yell better prompts into the void. They will be the teams that already know how to make work clear. They know how to define done, make standards visible, capture decisions, test behavior, and review code without relying entirely on vibes. AI rewards explicit systems and punishes vague ones.

That is uncomfortable, because a lot of software organizations are built on vague systems. They have vague ownership, vague standards, vague architectural rules, vague acceptance criteria, vague deployment expectations, and vague definitions of quality. Experienced engineers paper over that vagueness. They fill in the gaps, protect the platform from bad assumptions, know when a ticket is missing something important, know who to ask, and know which part of the codebase lies. That skill is valuable, but it is also a bottleneck. You cannot scale heroics, and you cannot scale hidden context. If every good outcome depends on a senior engineer silently correcting the system as work moves through it, then the system is weaker than you think. AI did not create that weakness. It exposed it.

This is why the phrase "AI slop" is often too generous to the humans involved. It makes the problem sound like the machine polluted an otherwise clean process, when in many cases the process was already dirty. The instructions were thin, the tickets were vague, the standards were tribal, the tests were incomplete, the review process was overloaded, and the architecture was more memory than documentation. Then AI walked in and behaved like any new contributor with incomplete context. It filled the gaps, badly sometimes, but it filled gaps that should not 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. Quite the opposite. If you copy AI-generated code into a codebase without understanding it, that is on you. If you ship code you cannot explain, that is on you. If you let the tool invent architecture because you were too lazy to define the architecture, that is on you. AI does not remove accountability. It makes accountability more important.

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

So the standard is simple. Use AI, but own the output. Use AI, but define the context, write down the standards, and test the behavior. Use AI, but do not pretend speed is the same thing as quality.

If you do not like the code AI produces, ask what a good human engineer would need to know before doing the same work, and then write that down. Put it in the repository, the agent instructions, the style guide, the ticket template, and the examples. Put it somewhere the next person can use, because that next person might be a junior engineer, a senior engineer new to the codebase, you six months from now, or an AI tool. The destination is the same either way: make the hidden system visible. That is the real work, not because AI deserves special treatment, but because AI forces us to admit how much of our engineering process has been running on assumptions, memory, and informal correction.

Most AI slop is not a model failure. It is a process failure wearing a shiny new costume. If that makes people mad, good. They should be a little mad. But they should not waste that energy yelling at the tool. They should use it to fix the system around the tool: write the standards down, clarify the handoffs, define the patterns, create the tests, make the architecture visible, and stop expecting AI to infer the culture of your codebase from a vague ticket and a prayer.

Your AI is not sloppy. Your communication is, your standards are, your handoffs are, and your process is. Fix that, and the AI gets better. More importantly, so do the humans.