Before they had a name
You write a class that must exist only once in the whole program. Then an object that has to notify three others every time its state changes. Then a piece of code that must work with four different algorithms without knowing which one it will get. And at some point you stop, because you have written these shapes before. You do not remember where, but your hands do.
For the first decades of software this was the normal state. The same structures came back in the programs of people who had never spoken to each other, everyone rediscovered them from scratch, and nobody had a word for them. If you wanted to explain to a colleague what you were doing, you drew it on a whiteboard. Every time, from zero.
The word came from outside, from a place that had nothing to do with computers.
In 1977 an architect, Christopher Alexander, published A Pattern Language: two hundred and fifty-three entries on the recurring shapes of houses and cities. A courtyard open on one side, because the ones closed on four sides stay empty. Windows on two walls of a room. A street narrow enough that two people crossing it can say hello. Alexander never wrote a line of code, and the book does not mention software once.
It caught on for a precise reason: those were not blueprints to copy. Each entry described a context, the forces pulling in opposite directions, and a shape that held them together without fully resolving them. People who wrote programs recognized their own craft in it. There too the work is not finding the right answer, it is holding contradictory constraints together, and knowing what you are giving up.
In 1987 Kent Beck and Ward Cunningham took the step: they presented at a conference a small set of patterns for Smalltalk interfaces. They took an architect's word and carried it into code. It looks like a detail for historians. It is the moment when a young craft noticed it already had habits, and decided to look at them.
1994
Seven years later Design Patterns came out, signed by four authors everyone would later call the Gang of Four. Twenty-three patterns. Singleton, Observer, Factory, Strategy, Decorator, Visitor and the rest.
The book invented nothing. Those structures were already inside the programs people wrote every day, often without noticing. What the book invented was a vocabulary.
This is where the story gets interesting, because a pattern is not code. You cannot compile it, you cannot run it, you will not find it anywhere in the binary. It exists only in the heads of the people who recognize it. It is a shared fiction, in the most literal sense: something that is real because enough of us decided to believe in it together. And that is exactly why it works. Two developers who have never met can say "Observer" and mean the same thing.
Try to measure the saving. One word instead of twenty minutes at a whiteboard. One word that carries not only the shape, but also its known flaws, its alternatives, the reason it is sometimes a bad idea. Software grew beyond the size of a single head the same way cities did: not by finding smarter people, but by inventing words that let strangers coordinate.
Then the patterns domesticated us
Success stories rarely stay innocent for long.
The vocabulary became a syllabus. The syllabus became an interview ritual. The interview ritual produced a generation that could list the twenty-three names and recognize maybe three of them in real code. Meanwhile, in the two thousands, the enterprise industry took the catalogue as a shopping list and built cathedrals of abstraction where three functions would have done. In the libraries of that period there really is a class called AbstractSingletonProxyFactoryBean. It is not somebody's joke: it is official documentation.
The question that stays is the same one you can ask about agriculture. Did we domesticate patterns, or did patterns domesticate us? Wheat promised more food and delivered longer days and bent backs. The catalogue promised less work and delivered, for a good decade, a lot more code to maintain.
I do not think the book is to blame. The authors wrote about forces and trade-offs, and kept repeating that every pattern has a cost. But a name travels faster than the reasoning that justifies it, and it travels further. After a few hands, only the name is left. That is how a word stops being a tool and becomes a password.
Where they went
If you look at a modern project, the twenty-three names seem gone. They are not: they were absorbed.
Iterator became a for loop in the language. Strategy is a function passed as an argument. Command is a closure, or a message in a queue. Observer is an event stream, or a signal, or a primitive the framework gives you for free. As early as 1996 Peter Norvig pointed out that sixteen of the twenty-three patterns become invisible or much simpler in a dynamic language. Not because the problem disappears, but because the language stopped charging you for that shape.
From here comes the reading I find most useful of all: a design pattern is a symptom of something the language or the platform does not give you yet. When it does, the pattern stops being a pattern and becomes a keyword, and nobody talks about it anymore.
Which also explains why they did not go extinct, they changed floor. When systems broke into services talking to each other over an unreliable network, the same recurring shapes came back one level up: circuit breaker, retry with backoff, idempotency key, outbox, saga, CQRS, sidecar. Different names, identical mechanism. Somebody solves the same problem for the twentieth time, notices they are redrawing the same thing, and gives it a name so the twenty-first does not have to start over.
A new 1994
Today we are at the start of the cycle again, and this time we are watching it live.
People building systems with language models started recognizing recurring shapes and naming them less than two years ago: prompt chaining, routing, orchestrator-workers, evaluator-optimizer, tool use, retrieval, guardrails. They are described in engineering posts, not in an authoritative book, and they change name every six months. In other words: we are at 1987, not at 1994. The catalogue has not been written yet, and the fun part is that nobody knows which of these names will survive.
There is one difference worth looking at closely, though. The classic patterns also existed for a practical reason: writing that code by hand cost time, and remembering it cost memory. Today the code that instantiates a known shape is cheap. The expensive part is somewhere else: knowing which shape you need, and what you pay for choosing it.
If a pattern is a name given to a trade-off, then when writing the code becomes free the value does not drop. It moves entirely onto the name.
What is left
I do not know how this ends, and I distrust anyone who tells it with too much confidence. I see three possible paths, and they will probably coexist.
The first is the past repeating itself: agent patterns will be absorbed by frameworks and runtimes, the way Iterator was, and in five years they will be a function you call with three parameters. That is the likely outcome for most of them.
The second is that the vocabulary survives even when the code underneath has completely changed, because it serves us, not the machines. Shared words are the only way we have to make decisions as a group without rereading the whole system every time.
The third is the uncomfortable one. Patterns were born from two human limits: we forget, and we have to agree with each other. If a growing share of the code is written and reread by something that does not forget and does not need to agree with anyone, that pressure eases. The risk is not that the names disappear. It is the opposite: that they stay in circulation long after the reason they were born has dissolved, repeated by whoever designs and whoever generates, with the same fidelity and none of the questions.
Against this I have one defense, and it is a small one.
Before using the name of a pattern, try to say what it solves and what it costs, in one sentence, without saying the name. If you cannot, you are not using a tool: you are repeating a word.
It holds for Singleton in 2004 and for orchestrator-workers in 2026. The useful question was never "which pattern is this". It is "which forces am I holding together, and what am I losing to do it". The name comes after, and it only exists so someone else can understand you quickly.