1994
Design Patterns arrived in October 1994, roughly two decades after the practice it described. We started writing the AI era down in year one, on ground that has not stopped moving since.
From the closing paragraph of Part 1:
I’m not sure the boundary I’m describing is permanent. AI systems are developing their own forms of evaluation and judgement, and what’s hard today may not stay hard. That has been true at every shift. And at every one of them I was standing inside the layer that was about to be absorbed, reasonably confident that what I knew was the durable part.
Here is the more uncomfortable version. Every time, the industry wrote down what it thought it had learned. And every time, some of what it wrote down was not a lesson at all. It was a description of a temporary problem, recorded as though it were a permanent feature of the world.
The book that arrived late
Design Patterns was published on the thirty-first of October, 1994. Four authors, twenty-three patterns, and a book that reorganised how a generation of programmers talked about their work.
The thing worth noticing is the timing. Object-oriented programming was not new in 1994. Simula had been around since the sixties, Smalltalk since the seventies, C++ since the early eighties. By the time the book appeared there were roughly two decades of accumulated practice underneath it, which is precisely why it worked. The authors did not invent those patterns. They noticed them. Composite and Observer and Strategy were already out there in working systems, discovered independently by people who had no idea they were discovering anything, and the book’s contribution was to name what was already true.
Now run the counterfactual. Imagine the same book, with the same confidence, published about the web in 1994. Certified Web Architect. Twenty-three canonical patterns for hypertext systems. A body of best practice codified in the same year Netscape was founded, before anyone knew whether the web was a publishing medium, a shopping mall or a fad.
It would have been useless, and worse than useless, because people would have followed it.
We are living that counterfactual. The certification industry, the pattern catalogues, the frameworks with their canonical architectures: all of it has arrived in year one.
I want to be careful here, because there is a cheap version of this argument that says the people doing the writing-down are charlatans. They are not. Codifying practice is a good instinct and mostly a generous one, and every field that matured did it eventually. The problem is not the motive. It is the clock.
Two lines moving in opposite directions
Look at the same three shifts from the first half, but ask a different question of them. Not what happened to the work. What happened to the writing-down.
The web took roughly a decade to harvest. The first widely useful patterns for building web systems came out of years of people building web systems badly, and the codification was mostly bottom-up, written by practitioners who had already been burned.
Cloud was faster and came from a different direction. EC2 launched in 2006. The twelve-factor app appeared in 2011. Five years, and much of the codification was vendor-led rather than practitioner-led, which turns out to matter.
AI’s codification industry arrived in year one, before anyone had run a system in production long enough to be burned by it.
So codification speed is accelerating across the three. Now put the second line beside it. HTTP and TCP/IP were essentially fixed while the web’s practice matured; the substrate held still and let the patterns settle onto it. Cloud primitives moved, but slowly, and mostly by addition. Model capability now changes materially every few months, and the changes are not additive. A technique that was necessary in one release is redundant in the next.
Two lines, moving in opposite directions. We are writing practice down faster than we ever have, onto ground less stable than it has ever been. That is the whole argument, and everything else here follows from it.
What premature codification actually costs
The cloud era gives us the control case, and it is worse than wasted effort.
Lift-and-shift became the default enterprise cloud pattern for the better part of a decade. Take the thing you have, move it somewhere else, call it a migration. It was codified early, promoted hard by vendors with an obvious interest in volume, and it was wrong in a way that took years and a great deal of money to unlearn. Organisations did not merely fail to benefit. They rebuilt their existing constraints in a more expensive place and then had to undo it.
Premature codification does not sit there being harmlessly incomplete. It directs traffic.
The test
If the ground will not hold still, the only sane thing to write down is the part that does not depend on the ground.
So the question I now ask of any pattern, framework or piece of received AI wisdom is this: does it get stronger or weaker as the models improve?
If it gets weaker, it was never a pattern. It was a workaround for a limitation that somebody is currently being paid to remove. Codifying it is a bet against the entire industry’s roadmap, and that is a bet you lose on a schedule.
If it gets stronger, it is describing something structural, and it is worth the ink.
Three things I think are temporary
The test is only worth having if it makes predictions, so here are three, written in July 2026 and dated on purpose.
Multi-agent role hierarchies. The researcher, the critic, the planner, the manager, each with its prompt and its place in an elaborate org chart. Most of that scaffolding compensates for weak long-horizon reasoning and short context, and both are being fixed. I expect much of it to collapse back into one capable agent doing the work directly.
I should be specific about the cost of being right, because I built one of these. IRIS orchestrates fourteen agents for security analysis and it won my company’s inaugural MCP hackathon. I still think the architecture was the right call for the models available when I built it. I also think it is a transitional form, and that the durable part was never the agent choreography. It was the typed contracts between the components, the ability to see what each step did, and the ability to re-run one of them. None of which is about AI. All of which is distributed systems, wearing a costume.
Token-cost-driven architecture. Summarisation chains, aggressive context pruning, the whole craft of spending fewer tokens. These are optimisations against a price that keeps falling. I have seen this film: we spent the nineties writing clever code to save memory and bandwidth, and almost none of that cleverness survived contact with cheap memory and fat pipes. What survived was the code that was clear.
RAG, but not the way people are saying it. The claim doing the rounds is that RAG is dead and it is all about agent-to-agent protocols now. That is a category error, and the error is the reason I am writing this. A2A, which Google released in April 2025 and handed to the Linux Foundation that June, is an interoperability standard: it describes how agents advertise capabilities and exchange work. RAG grounds a model in a corpus. They do not solve the same problem, and saying one replaces the other is like saying HTTP replaced databases.
What is actually happening is more interesting and fits the first half of this piece exactly. Retrieval is not disappearing. It is relocating behind an interface. If you can ask a specialist agent that already owns a domain, you stop assembling your own retrieval stack and start consuming someone else’s. So the bespoke stack each team currently builds probably does die, along with all the chunking craft around it, which was small-context compensation from the beginning. Retrieval as a function carries on, owned by somebody you never see. And provenance gets more important rather than less, because it was never a capability workaround. It is a trust property, and fluency raises the price of not having it.
Which means “RAG is dead” is not a technical observation. It is what absorption feels like from the inside. It is the same sentence my rack knowledge would have written about itself in 2006.
The pattern in the pattern
Notice what survived each of those three. Typed contracts. Observability. Reproducibility. Provenance. Clarity.
The patterns that survive are the ones that were never really about the model.
There is a tell for a field standing on moving ground, and it is the death notices. Nobody spent the stable decades announcing that SQL was finished every eighteen months. A discipline that kills and replaces its canonical practices this quickly is telling you something about its substrate, and the correct response is not to write faster. It is to write less, and to be much more careful about which parts you commit to.
I do not think any of this makes me perceptive. It is the third time I have watched this film, and the third time you watch a film you stop following the plot and start noticing the structure. That is attendance, not insight.
The only claim here I would still defend in three years is the test, and it should survive me being wrong about all three of those predictions. If multi-agent choreography turns out to be permanent, the test was still the right question to ask. That is the difference between a pattern and a guess, and it is the thing I wish somebody had written down in 1994, instead of the twenty-three patterns.