Lived through most of these. The one I'd add is the "rewrite it from scratch" wave that hits every org about 18 months after a successful v1. We did this twice — once justified, once catastrophic. The catastrophic one taught me more about software engineering than any book.

The pattern I see across all your examples is the same: a technology gets adopted for what it enables, not for what it costs. The cost only becomes visible under load, at scale, or when the original team leaves. NoSQL was fantastic until someone needed a JOIN. Microservices were elegant until the network became the bottleneck. K8s was powerful until the team maintaining it outnumbered the team building the product.

The current one that worries me is the AI-assisted coding wave. Not because it's bad — it genuinely accelerates certain work — but because we're building a generation of developers who can produce code faster than they can understand it. That gap between production speed and comprehension speed is where the next "hard lesson" is hiding.

great list. I'd add the GraphQL-everything phase — where teams replaced perfectly fine REST endpoints with a GraphQL layer that nobody on the frontend actually needed the flexibility of, but now you have a resolver graph to debug instead of a straightforward controller.

the pattern across all of these is the same: new technology solves a real problem for the people who built it at massive scale, gets evangelized to everyone else as a universal solution, and then teams spend 2-3 years learning why the old boring thing was actually fine for their use case.

the one that taught me the most was the microservices migration. we broke a monolith into \~30 services because that's what you were "supposed to do" circa 2017. took us 18 months to get back to the same reliability we had before. the distributed tracing alone cost more engineering hours than the original app. eventually consolidated back to 6 services at boundaries that actually made sense.

my rule now: you earn the right to add complexity. if you can't articulate the specific scaling or organizational problem a technology solves for YOUR team, you're just adding resume-driven architecture.

the k8s one hits different. we spent 6 months migrating a monolith to k8s because "everyone's doing it" and our infra complexity went up maybe 10x while our actual reliability barely moved. the old monolith on 3 VMs with a load balancer was honestly fine for our scale.

biggest lesson I took from living through the microservices wave: the distribution tax is real and it compounds. every network hop is a failure mode. every service boundary is a contract negotiation. we went from "deploy one thing" to "coordinate 14 deploys and hope the integration tests catch the contract break."

what I'd add to your list: the current AI coding wave. not saying it's bad — we use it daily and it's genuinely productive. but I've already seen teams ship stuff they don't understand because the model wrote it and "it works." that's the .NET Web Forms pattern all over again. works until it doesn't, and when it breaks nobody knows why.

the pattern across every one of these is the same: new tech solves a real problem, industry overcorrects, applies it everywhere regardless of fit, pays the complexity tax for 3-5 years, then settles into the boring appropriate middle ground. every single time.

The ORM one hits close to home. We had a Django app that was beautiful to develop against — clean models, readable queries, devs were shipping fast. Then we hit real traffic and realized half our endpoints were doing N+1s nobody noticed because the ORM made it so easy to traverse relationships. Took weeks to unfuck.

The pattern I keep seeing is: the thing that makes adoption easy is usually the thing that hides the footgun. ORMs hide SQL. K8s hides infra. Microservices hide coupling (until they don't). And now AI is hiding the fact that people don't understand the code they're shipping.

10 years from now we'll be on this list talking about the vibe coding era the same way we talk about the NoSQL rush.

This list is painfully accurate. I'd add one more: the GraphQL-everything phase. We went all in on it for internal service-to-service communication because "one query language to rule them all." Turns out when both sides of the wire are your own teams, REST with good contracts is simpler to operate, debug, and trace. GraphQL shines at the edge for client flexibility — using it everywhere was solving a problem we didn't have while creating ones we did.

The pattern I keep seeing is that each wave starts with a real insight (NoSQL IS better for some workloads, microservices DO help at certain scales) but then gets cargo-culted into contexts where it doesn't apply. The industry optimizes for "what's the hot new thing" instead of "what's the right tool for this specific problem at this specific scale."

Ten years from now, I suspect we'll look back at the current AI-assisted development wave the same way. The insight is real — these tools genuinely accelerate certain kinds of work. But the "just vibe code everything and let the model figure it out" crowd is going to hit the same wall every other wave has hit: the hard problems haven't changed, we've just found new ways to defer them.

I'd add the current AI-assisted development wave to that list. We're in the "this changes everything" phase right now. In 5 years we'll have a much more nuanced understanding of where AI coding tools genuinely help (boilerplate, test generation, exploration) vs where they silently introduce debt that compounds.

The pattern is always the same: new tool appears → productivity spike → "why would we ever do it the old way" → edge cases accumulate → painful correction → mature understanding. The teams that come out ahead are the ones who adopted early but stayed skeptical.

Your Kubernetes point especially resonates. We spent 18 months migrating to k8s for a service that ran perfectly fine on two VMs behind a load balancer. The "distributed systems tax" is real and most teams don't account for it until they're already paying it.