Why AI Coding Needs Anti-Patterns

Something shifted in software over the last couple of years, and most teams felt it before they found the language for it.

First your editor started finishing your thoughts. Then a chat window started returning working code. Then the expectation changed. A weekend prototype that used to require a small burst of obsession and several pots of coffee now looks like an ordinary Monday. The tools really are impressive. That part is not the problem.

The problem is that AI changed the failure surface at the same time it expanded the output surface.

Old-school bad code had the decency to fail loudly. It would not compile. It would crash immediately. It would make such a strange noise in production that even the least attentive person on the team could tell something had gone wrong. You learned judgment inside that feedback loop. The machine argued with you, and the argument made you better.

AI-generated code is often more dangerous precisely because it is more polite. It compiles. It runs. It passes the quick demo. It solves enough of the problem to create the feeling that the problem is now handled. It has the right shape, the right tone, and just enough correctness to slip past your normal defenses.

This is what the book calls slop: output that is generic, unexamined, and only loosely aligned with the problem it claims to solve. Not all AI code is slop. But when you accept the default output without much critical thought, it tends to have a recognizable quality — fluent, conversational, averaged from everything the model has seen before.

We need a shared language for these failure modes. That's what anti-patterns give us: names for the things we're seeing, so we can talk about them before they become disasters.