What is an anti-pattern?
Engineering culture and software practice
An anti-pattern is a commonly used approach to a recurring problem that looks reasonable, or is adopted for understandable reasons, but reliably makes things worse than a known alternative. The term was coined by Andrew Koenig in 1995 as the mirror image of a design pattern. To count as a true anti-pattern, an approach must recur, appear sensible, and have a documented, better refactored form that experienced people already know.
What this means
Engineers name recurring good ideas as patterns so they can be reused and discussed. An anti-pattern is the same trick applied to recurring bad ideas: a way of tackling a problem that keeps getting chosen, keeps seeming plausible, and keeps ending badly. Giving these failures names lets people recognise them early and talk about them without blaming whoever fell into one.
The key is that an anti-pattern is not just any mistake. It has structure. It recurs across many teams and projects, it looks like a sensible answer rather than an obvious error, and, crucially, there is a known better way, a refactored form, that people can move towards. That last part is what separates a named anti-pattern from a mere gripe.
Because so much of the folklore in engineering culture is really a catalogue of these named traps, anti-pattern is the umbrella term that sits above many of the individual terms in this theme. Learning the concept helps you understand why engineers name their mistakes at all.
Why it matters
For a non-engineer, the practical value is understanding what is being claimed when someone in a meeting says that is an anti-pattern. They are not just saying they dislike an idea. They are asserting something specific and testable: that this approach recurs, that it looks sensible but reliably goes wrong, and that a better, documented alternative exists. You are entitled to ask them to show that better alternative.
The idea also travels well beyond code. The original catalogue deliberately covered management and organisational traps as well as technical ones, which is why leaders find it useful. Recognising management anti-patterns, such as a decision process that appears thorough but reliably stalls projects, gives you a shared, blame-light language for fixing them.
It is directly relevant to AI adoption, where several recurring traps already have informal names: pilot purgatory, where organisations run endless trials that never reach production; tool-first thinking, where a technology is chosen before the problem is understood; and the single-champion problem, where one enthusiast carries the whole effort and it collapses when they leave. Naming these helps a leadership team spot them early rather than living through them.
Finally, the concept protects you against its own misuse. Because anti-pattern sounds authoritative, it can be used to shut down debate. Knowing the real definition lets you tell a genuine anti-pattern claim from a rhetorical one.
How it works
Where the term came from
The word antipattern was coined by the programmer Andrew Koenig in an article titled "Patterns and Antipatterns" in the March/April 1995 issue of the Journal of Object-Oriented Programming, volume 8, number 1, pages 46 to 48. His definition is precise: an antipattern is like a pattern, except that what it offers only looks like an answer to the problem and is not one. The coinage was a deliberate counterpart to the hugely influential 1994 book Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, the group known as the Gang of Four, which had given software a shared vocabulary for good recurring designs. Koenig's article was later reprinted in Linda Rising's The Patterns Handbook, published by Cambridge University Press in 1998.
The concept was popularised three years later by the 1998 book AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis, by William Brown, Raphael Malveau, Hays McCormick and Thomas Mowbray, published by Wiley. It catalogued around forty anti-patterns across three areas, and the community wiki known as the C2 wiki, or Portland Pattern Repository, spread the catalogue further. That book set out the two elements that distinguish a real anti-pattern from a mere bad habit: some repeated action or structure that at first appears beneficial but ultimately produces more harm than good, and a refactored form that is clearly documented, proven in practice and repeatable.
Pattern, anti-pattern and smell
Three related ideas are often confused. A pattern is a reusable good approach. An anti-pattern is a recurring approach that looks good but reliably ends worse than a known alternative, and it comes with that better alternative attached. A code smell, a term from Martin Fowler and Kent Beck popularised in Fowler's 1999 book Refactoring, is different again: it is a surface hint that something might be wrong, a quick sniff rather than a diagnosis. A smell says look here; an anti-pattern says this specific approach is the trap, and here is the way out.
The three areas of the 1998 catalogue
The AntiPatterns book grouped its entries into development anti-patterns, which are coding-level traps; architectural anti-patterns, which concern how systems are structured; and managerial anti-patterns, which concern how people and projects are run. This breadth is the reason the concept is useful to leaders and not only to programmers: many of the most expensive traps are managerial, such as processes that look rigorous but reliably cause overruns or cancellations.
Why naming helps, and how to check a claim
Naming a trap lets a team argue about the approach rather than the person, which lowers the temperature of a disagreement. But the label carries authority, so it can be misused to end debate. The check is to run the definition: does this approach genuinely recur across situations, does it look sensible rather than being an obvious blunder, and can you point to a documented, proven better alternative. If there is no known better way, you may have a hard problem or a judgement call, not an anti-pattern, and every rule has exceptions.
Examples
A professional services firm keeps launching AI trials that impress in a demo and then quietly stall before anything reaches everyday use. An adviser names this as pilot purgatory, a recurring adoption anti-pattern, and points to the documented better approach: define in advance what would make a trial worth scaling, and commit to a route into production. Naming it lets the partners discuss the process rather than blame the team that ran the last pilot.
A retailer's project reliably overruns because every decision must pass through a review board that looks thorough but stalls the work, a classic managerial anti-pattern from the 1998 catalogue's people-and-process category. The fix is the refactored form: reserve heavy review for genuinely irreversible decisions and let routine ones proceed, which is a known, repeatable alternative rather than just a complaint.
A council department relies entirely on one enthusiastic member of staff to run its new AI tool. When that person is on leave, everything halts. An adviser identifies the single-champion anti-pattern and recommends the documented alternative of spreading knowledge across several people, so the approach that felt efficient does not become a single point of failure.
Common misunderstandings
An anti-pattern is just any mistake. It is not. Koenig's definition and the 1998 book require that the approach recurs, that it looks like a sensible answer rather than an obvious error, and that a documented, proven better alternative exists. A one-off blunder with no known better way is not an anti-pattern.
An anti-pattern is only about code. It is not. The 1998 catalogue deliberately spans development, architecture and management, and many of the costliest anti-patterns are organisational rather than technical.
An anti-pattern is the same as a code smell. It is not. The existing Code smell article describes a surface symptom, from Fowler and Beck, that merely suggests something might be wrong. An anti-pattern names the specific trap and comes with a known refactored way out; a smell points, an anti-pattern diagnoses and prescribes.
Calling something an anti-pattern settles the matter. It does not. Because the label sounds authoritative it can be used to shut down debate, yet the definition requires a demonstrable better alternative and every rule has exceptions. A claim without a shown alternative is unproven.
Anti-patterns and the individual terms are the same thing. Not quite. Big ball of mud, spaghetti code, gold plating, cargo-cult programming and cowboy coding are specific named anti-patterns; this article is the umbrella concept that explains what makes any of them qualify, rather than describing one particular trap.
Risks and boundaries
The principal risk is rhetorical inflation. Because anti-pattern carries the authority of a named, catalogued concept, it is easy to slap the label on any approach you dislike and thereby end a discussion you should be having. The discipline that keeps the term honest is its own definition: a genuine anti-pattern recurs, looks sensible, and has a documented better alternative. Without that alternative, the claim is just disapproval dressed up.
There are real boundaries. Some approaches that look like anti-patterns are in fact reasonable trade-offs for a particular context; the folklore can outrun the evidence, and what is a trap in one setting can be the least-bad option in another. The concept also does not tell you which alternative is right for your situation, only that one should exist and be demonstrable. And because so many informal AI-adoption traps are now called anti-patterns without the rigour the term implies, it is worth checking whether a named trap has a genuinely proven better form or is merely a popular grumble. The live tension is between the usefulness of a shared vocabulary for mistakes and the temptation to weaponise that vocabulary.
What to do next
Run the definition when you hear the claim. When someone says that is an anti-pattern, ask whether the approach genuinely recurs, whether it looks sensible rather than being an obvious error, and above all what the documented better alternative is.
Ask for the refactored form. Treat any anti-pattern claim as incomplete until the person can point to a proven, repeatable alternative. If there is none, you may be facing a hard problem or a judgement call instead.
Use the language to lower blame. Name recurring traps as patterns so your team can debate the approach rather than the individual who chose it, which makes hard conversations easier.
Watch for the managerial ones. Remember that the original catalogue spans management as well as code, and that expensive traps such as review processes that reliably stall work are anti-patterns you can name and fix.
Apply the lens to AI adoption. Learn the common adoption traps, such as endless pilots, choosing tools before problems, and relying on a single champion, so you can recognise and interrupt them early rather than living through them.
FAQs
Who coined the term anti-pattern?
The programmer Andrew Koenig, in an article titled Patterns and Antipatterns in the March/April 1995 Journal of Object-Oriented Programming. He defined it as something that looks superficially like an answer to the problem but is not one.
What makes something a true anti-pattern rather than just a mistake?
Two things, according to the 1998 AntiPatterns book: a repeated approach that first appears beneficial but ultimately does more harm than good, and a documented, proven, repeatable better alternative. Without both, it is not really an anti-pattern.
How is an anti-pattern different from a design pattern?
A design pattern is a reusable good approach to a recurring problem, from the Gang of Four's 1994 book. An anti-pattern is the mirror image: a recurring approach that looks good but reliably ends worse than a known alternative.
How is an anti-pattern different from a code smell?
A code smell, from Fowler and Beck, is a surface hint that something might be wrong. An anti-pattern names the specific trap and comes with a known way out. A smell points; an anti-pattern diagnoses and prescribes.
Are anti-patterns only about programming?
No. The 1998 catalogue deliberately covered development, architecture and management, and many of the most expensive anti-patterns are about how people and projects are run rather than about code.
Can the label be misused?
Yes. Because it sounds authoritative, anti-pattern can be used to shut down debate. The safeguard is to insist on the definition, especially a demonstrable better alternative, and to remember that every rule has exceptions.
What are some AI adoption anti-patterns?
Commonly named ones include pilot purgatory, endless trials that never scale; tool-first thinking, choosing a technology before understanding the problem; and relying on a single champion who becomes a point of failure.