AI slop is not new: we had developer slop long before AI

Slop is older than AI

People talk about “AI slop” as if it arrived with the first chatbot. It did not. We had developer slop long before AI: copy-paste fixes, hacks that quietly made it to production, and “we’ll refactor later”. AI just speeds it up. The genuinely new part is that agents are writing it now too.

That matters for anyone judging a team. If the only defence against slop is “we don’t use AI”, there is no defence. The habits that produced slop before any of these tools existed still produce it, and the tools now produce it faster.

Slop is also a more precise word than “bad code”. Bad code can be an honest mistake. Slop is code nobody really understood when it was merged, accepted because it was cheaper than thinking it through.

What developer slop looked like before AI

• The copy-paste fix. An answer from a forum pasted in because the error went away. Nobody checked why it worked or what else it changed.
• The hack that reached production. A hard-coded ID, a special case for one customer, a flag set by hand in the database. Meant for an afternoon, still there years later.
• “We’ll refactor later.” Said in good faith. Later never came, because there was never a ticket, a date or an owner for it.
• The swallowed error. A catch block that catches everything and logs nothing. The bug does not stop happening. It just stops being visible.
• The dependency for one function. A whole package installed to format a date, with its own updates and vulnerabilities from then on.

None of these needed a language model. They needed a deadline, a reviewer in a hurry and nobody whose job it was to say no. Here is the oldest one in the book:

try {
    $invoice->send();
} catch (\Throwable $e) {
    // TODO: handle this properly later
}

It passes a rushed review in thirty seconds and the exception disappears. It also means invoices can fail to send with no log, no alert and no retry. People wrote this long before any tool could. A tool will now write it too, if the prompt was “make this stop throwing”.

What AI changes: volume and polish

AI did not change what slop is. It changed two things: how much of it you can produce in a day, and how good it looks.

The cost of producing plausible code has dropped close to zero. The cost of reviewing it has not moved. A reviewer reads at the same speed whether a person typed the diff over a day or a tool generated it in a minute. When producing is cheap and checking is expensive, unchecked code piles up unless someone decides it will not.

Polish is the subtler problem. Old slop had tells: inconsistent naming, a stray comment, a function in the wrong file. Reviewers learned to spot them. Generated code is tidy, consistently formatted and confidently named. It looks reviewed before anyone has reviewed it, and an invented helper method or an outdated API call hides well in code that otherwise reads cleanly.

AI did not invent slop. It made it cheaper to produce and harder to spot.

The new part: agents write it too

Autocomplete still has a person at the keyboard, accepting or rejecting each suggestion. Coding agents change that. You give one a task, it reads the codebase, edits several files, runs the tests and comes back with a pull request. Nobody typed the code, and sometimes nobody watched it being written.

That removes an informal check we used to rely on without noticing. When a developer wrote a hack, at least one person knew the hack existed. With an agent, the first person to see the change may be the reviewer, looking at a finished diff with no memory of the decisions behind it.

Agents also optimise for the goal you gave them. Tell one to make a failing test pass and it looks for a route to green, which can be a real fix, a special case for the test input or a change to the test itself. A tired developer on a deadline takes the same shortcuts. The agent takes them faster, and without the guilt.

So the useful question is no longer who wrote the code. It is who owns it now.

How to spot slop, whoever wrote it

The tells are the same for people and tools. These are the ones worth looking for in review, and none of them depend on how the code was produced.

• The fix treats the symptom. The error is gone but nobody can say what caused it. Ask for the cause in one sentence. “Not sure, but it works now” means it is not fixed.
• No test reproduces the bug. A bug fix without a test that failed before and passes after is a guess with a commit message.
• It duplicates something that already exists. A new date formatter next to the ones the codebase already has. New team members and tools both do this, because they did not know the existing one was there.
• Errors disappear instead of surfacing. Broad catch blocks, early returns on null without a log line, retries with no limit.
• The diff is bigger than the problem. A one-line bug with a 400-line pull request means something else came along for the ride.
• The owner cannot explain a line. This is the check that catches the rest.

The last point is the rule our whole review process hangs on. We wrote up how it works day to day, including the owner checklist in our pull request template, in AI-assisted, human-reviewed: how we ship faster without shipping slop.

Fix the conditions that produce slop

Banning tools does not remove slop, because the tools were never the cause. Slop comes from conditions: work that has to ship today, a review that is a formality, and nobody responsible for the code after it merges. Change those and it matters much less who or what typed the first draft.

• Every change has one named owner. An agent can open a pull request. It cannot own one. The engineer who asks for review owns the diff as if they had typed every line.
• Bug fixes come with a failing test. It proves the cause was found, and it makes a quiet edit to the test itself stand out in review.
• “Later” gets a ticket or it does not exist. A shortcut is fine when it is written down with a reason and a point where it gets revisited. A shortcut with only a TODO comment is slop with good intentions.
• Small pull requests, even when generation is cheap. Especially then. If a diff cannot be read properly in one sitting, it gets split.
• Agent output is a first draft. Useful, often good, and never merged on the strength of green tests alone.

None of this is new. It is the discipline good teams applied before AI. What changed is that skipping it now costs more, and the bill arrives sooner.

The question to ask any team

If you are choosing who builds your product, “do you use AI?” is the wrong question. Most teams do, and a team that does not can still ship slop the old-fashioned way. Ask what stops a copy-paste fix from reaching production, who owns a change an agent wrote, and when “we’ll refactor later” actually happens.

A team with good answers to those had them before AI too. If your codebase has a few years of “later” in it and you want a second opinion, send us a short brief.

Frequently asked questions