Open a random pull request from a team that recently "adopted AI." Not from a team that uses AI deliberately. From a team that just turned it on.
You will recognize the code. Functions that almost work. Comments that describe what the code does rather than why. Error handling that catches everything and does nothing. Security assumptions borrowed from a different system in a different era. It compiles. The tests pass. Nobody understands it.
That is slop. Programmer Simon Willison defined it well: slop is to AI what spam is to email. High-volume, low-effort, indistinguishable at a glance from the real thing. The difference between slop and code is not format. It is intent, precision, and accountability.
Here is the thing nobody wants to say out loud: the teams shipping slop are not victims of AI. They are victims of their own skill floor.
AI multiplies. It does not add.
"Garbage in, garbage out."
— George Fuechsel, IBM, 1960s
That phrase predates LLMs by sixty years. It has never been more relevant.
AI coding tools multiply whatever you bring to the prompt. Bring a clear mental model of the system, sharp constraints, and the pattern of every production incident you have ever debugged: AI accelerates all of that. Bring vagueness, a copy-pasted requirement, and no idea how this service fails under load: AI accelerates that too. It just does it faster.
The multiplier is not the problem. The starting point is.
A junior developer using Claude Code and a senior architect using Claude Code are not using the same tool in any meaningful sense. They are both holding a hammer. One of them knows where the nails are.
The two ways slop gets shipped
Vague prompts produce generic code. "Build me an authentication flow" will get you an authentication flow from the statistical average of all authentication flows the model has ever seen. Average security assumptions. Average error handling. No consideration of your threat model, your session store, your existing middleware, or how your team names things.
Andrej Karpathy coined the term "vibe coding" for this: you describe a feeling and accept what comes back. It is a fine way to prototype a demo. It is a terrible way to build production software that other people will operate at 3 AM.
Unreviewed acceptance is the silent killer. AI-generated code has no confidence calibration. It sounds equally certain when it is right and when it is subtly wrong. Brian Kernighan put the problem in terms that apply directly here:
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
— Brian Kernighan, The Elements of Programming Style (1978)
The code AI writes is often clever in the wrong way. It solves the stated problem while creating an unstated one. Catching that requires pattern recognition you can only build from production scars. You cannot automate your way around that.
What experienced architects do differently
The difference is not which AI tool you use. It is the work you do before and after the prompt.
Before the prompt: A senior engineer encodes context that would take a junior hours to find. The specific failure modes of this service. The team's conventions on error boundaries. The performance budget this function must respect. The data contract with the downstream system. That context goes into the prompt. The prompt is now part of the codebase. Treat it accordingly.
During review: The review question is not "does this look right?" It is "would I be comfortable defending this in a postmortem?" Every diff gets read. The code gets run. A test gets written against the case that would have caught the last incident in production. If you cannot explain why the implementation is correct, you do not ship it.
At the architecture level: Senior engineers decompose the problem before they touch the AI. They plan the seams: where data transforms, where failure propagates, where the invariant needs to hold. AI fills the interiors. Humans verify the seams. The architecture is still human work.
Martin Fowler wrote that any fool can write code a computer can understand. Good programmers write code humans can understand. AI optimizes for the former by default. Your review must correct toward the latter.
The IBERANT bar
"Slop is what happens when nobody in the loop has the scars to recognize it."
— Alejandro Tamayo, Founder of IBERANT Group
At IBERANT, every commit passes through a senior engineer who has lived through the failure mode that commit might introduce. AI accelerates the time from problem to candidate solution. It does not change what happens at review. That part is still human, still rigorous, still slow enough to be meaningful.
That is not a constraint on our speed. It is the reason our speed is trustworthy.
The floor is rising. The ceiling is not.
AI is raising the floor for trivial software. Generic CRUD apps, straightforward automations, scaffolding that would have taken a sprint now takes an afternoon. Good.
The ceiling is a different story. The ceiling is where architecture decisions compound, where security boundaries matter, where performance characteristics interact with system topology in ways that require you to hold the whole system in your head. AI cannot hold a system in its head. You need a human for that, and not just any human.
"Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away."
— Antoine de Saint-Exupéry
That instinct, knowing what to remove from the AI's output, is exactly what experience gives you. The engineers who develop it will have an extraordinary decade ahead. The ones who skip that work and just accept what the model generates will be left wondering why their fast code keeps breaking slowly.
If you want a team that knows the difference, let us talk.