What AI slop is, and how to fix it

“AI slop” is the code an assistant produces that compiles, passes a glance, and reads plausibly, but is wrong underneath. It is not broken in a way a demo will show you. It breaks later, in production, when a path no one tested finally runs. The phrase sounds dismissive, but the problem is real and specific, and it has a fix that is more about reading than rewriting.

What it actually looks like

Slop has a recognisable shape once you know the tells:

• Duplicated logic. The same validation or the same fetch-and-map appears in five places with small differences, because the model regenerated it instead of reusing it.
• Defensive padding. A try/catch around everything and null checks on values that can never be null. It hides the real failure instead of handling it, so the bug surfaces somewhere far from its cause.
• Type escapes. Casts to any, as unknown as, # type: ignore. The types compiled because the model silenced them, not because they line up.
• Tests that mirror the code. They assert that the function does what its body does, line for line, so they pass forever and catch nothing. A real test asserts the outcome a user cares about.
• Narration comments. A comment on every line restating the code. Volume, not insight.
• Inline secrets and config. API keys, connection strings, and magic constants pasted straight into the source.

Why it happens

An assistant completes the most plausible next tokens for the prompt in front of it. It has no memory of your architecture, no stake in the system surviving a year, and no view of the other twenty files. Plausible-looking is exactly what it optimises for, and plausible-looking is precisely what slop is. None of this is a reason to stop using AI to write code. It is a reason to put a verification step between the assistant and production, which is the step that was skipped.

How to find it before it bites

You do not need to read every line. You need to run the checks the model skipped and look in the places no human has:

• Run a linter, a type checker in strict mode, and a dependency audit. Each one surfaces a category of slop in seconds.
• Open the tests and ask whether any of them would fail if the feature were quietly broken. If not, you have coverage theatre, not coverage.
• grep for the obvious keywords: any, broad except, hardcoded keys, TODO, FIXME.
• Find the files that grew fastest and were touched only by the assistant. That is where the density is highest.

How to fix it, in order

The order is the whole trick. Rewriting before you understand makes it worse.

1. Read before you rewrite. Map what the code actually does and where the real seams are. You cannot safely change what you have not understood.
2. Add tests that assert behaviour. Before you change anything, make sure you have tests that describe the expected behaviour. If there are none, start by making them.
3. Draw boundaries. Split the fused mass into modules with clear inputs and outputs, so a change in one place stops rippling into five others.
4. Eliminate the obvious risks first. Get secrets out of the repository and its history, and enforce authorisation at the API, not just in the frontend.
5. Measure. Put the static analysis and tests into CI so the next slop is caught on the way in, not in production.

Done in that order, the codebase gets safer at every step, and it gets harder for the agent to sneak a shortcut past you.

When to call in a professional

If the code already carries real users, or you are about to scale it or hire a team around it, an outside read pays for itself: the person who wrote it (or prompted it) is the last to see what it is missing. A short, honest assessment of what is solid, what is fragile, and what to fix first turns “it works on my machine” into a plan you can rely on.

That is what a Review is. You come away with a written picture of the code and a quote for the rest, and you decide what happens next.