Design patterns are reusable approaches to common problems - anti-patterns are the same, but ineffective (and even counterproductive).
An example of a design pattern is the singleton - we often want to allow access to a resource, without incurring the cost of building it over and over. Computationally, this means restricting the instantiation of a class to a singleton, and then coordinating access to it where needed.
Anti-patterns can include code smells (like the infamous “spaghetti”), but are often less technical. Any process that inhibits effective development is cast as an anti-pattern. Long meetings, analysis paralysis, planning too much and planning too little - all this and more is categorized and enumerated as reasons for poor engineering outcomes.
Generalizing failures from producers to their ecosystem is a good thing. Yet this approach has a blind spot - nontechnical failures can also occur in purely technical contexts. And so I introduce a new engineering anti-pattern - superstition.