The question worth asking before anything else
I have worked across every major enterprise computing era of my career. Twenty-seven years of building, operating, and migrating systems.
The single most reliable lesson across all of them is this: be prepared for change. Continuously learn and adapt. The landscape keeps evolving.
That sounds obvious. It is not. The hard part is not accepting that change will come. The hard part is recognising it when it arrives, before it is obvious, before your competitors see it, before the analysts declare it inevitable.
To understand why that is hard, it helps to understand what these transitions actually looked like from the inside.
What the mainframe era actually felt like
Enterprise technology in the early years of my career was nowhere close to what it is today.
The internet existed. Companies could buy commercial T1 and T3 connectivity. Consumers were already coming online. But it was not the always-on, mobile, broadband, cloud-connected world we take for granted now.
Enterprise systems were heavy, expensive, and institutionally controlled. Compute was desktop-heavy outside the data centre. Laptops existed but they were expensive and underpowered compared to what teams expect today.
If you needed to store large amounts of data, you went to a mainframe running DB2, or to a Unix-based system running DB2 Universal Database, or to Teradata. These were not choices you made lightly. A mainframe was a commitment. You could partition and share capacity, but you did not have cloud-style self-service units where a developer could start small, scale gradually, and shut it down when the experiment ended.
The upfront cost was enormous. Only large corporations could afford it.
The platforms were also silos. Mainframes, AS/400 systems, large Unix systems did not talk to each other easily. If your organisation ran on one of these pillars, you built deep expertise in that pillar. Cross-pillar work was expensive. You hired experts on the specific platform you ran. Standardisation was weaker than what we expect now.
The transition I personally worked on
The first major transition I was directly part of was mainframe to Unix.
It was not that the mainframe was incapable. Mainframes are remarkably capable systems. They still process the majority of the world's most critical financial transactions today. The issue was not capability. It was economics.
Unix-based systems changed the cost structure. You did not have to make the same all-or-nothing commitment upfront. You could start smaller, expand more gradually. The barrier to entry dropped, and the addressable market expanded.
I witnessed the same pattern in Teradata-to-DB2 UDB transitions. Teradata was not inferior technology. In the environments I saw, the cost profile was simply prohibitive for many enterprise teams. DB2 UDB offered a more accessible entry point for distributed enterprise workloads.
What the web era got right, and the prediction that went wrong
The dot-com era is worth examining carefully, because what happened then is happening now with AI.
Companies poured money into web-based businesses in the late 1990s expecting quick returns. It did not pay back on that timeline, with that capital. The bust was real.
But here is what I think people get wrong about it. The web itself was not wrong. What was wrong was timing, capital discipline, and too much money moving too fast ahead of the infrastructure.
The web succeeded when the foundations caught up. HTML, CSS, JavaScript, browser behaviour, server-side languages, databases, and deployment practices matured over time. The W3C, ECMA, browser vendors, and the broader developer community did the slow work of turning a fragmented environment into something organisations could reliably build on.
The browser compatibility problems of the early web were a direct consequence of immature standards and uneven implementation. Every company was doing its own thing. You built a web page and then spent additional effort making it work across different browsers. It was complicated, fragile, and expensive.
What resolved it was not a better hack. It was agreement. Standards. Contracts. Convergence. A shared understanding of how things should work. That agreement is what made the web scale.
Cloud: the most important economics shift I have witnessed
Of all the transitions I have seen, the shift from on-premises to cloud changed the most.
AWS launched infrastructure services such as S3 and EC2 in 2006. What it did was decisive. It made the entry price extremely low. An individual developer could spin up an EC2 instance for cents per hour. To do the equivalent on-premises required significant upfront cost: hardware, networking, data centre space, power, procurement, capacity planning, and operations.
The economics were not just different. They were a different category of economics.
Startups from 2010 onwards increasingly ran entirely on cloud. Not because cloud was technically superior in every dimension. There are workloads where on-premises infrastructure is still more cost-effective at scale. But cloud let a team get an idea to market with almost zero capital on the infrastructure side. The constraint that had previously required institutional backing was removed. That changed who could build, not just how things were built.
Open source was a parallel force. Nginx changed web serving and reverse proxy patterns. Docker changed how software was packaged and deployed. Postgres became an enterprise-grade database that any organisation could adopt without a proprietary database contract. These were not toys. They were production-grade systems that reduced dependence on expensive proprietary alternatives.
Cloud native: when infrastructure became code
The cloud native era is where the architectural thinking caught up with the economic shift.
Kubernetes and containers changed the operating model for software delivery. Infrastructure became code, version-controlled, reviewable, deployable through the same pipelines as application code. Deployment became continuous. SRE emerged as a discipline to define reliability in measurable terms.
The organisations that built well in this era created platforms capable of supporting AI-native workloads that would follow. The ones that did not, that ran cloud infrastructure with on-premises thinking, that accumulated technical debt in the name of speed, that skipped the unglamorous work of observability and incident response, are now discovering that their AI ambitions have an infrastructure ceiling.
AI: the pattern is repeating
What is happening with AI follows the same pattern I have watched across every transition.
The economics are shifting. Capabilities that previously required specialist teams are becoming accessible to much smaller teams. A product team can now add natural language interfaces, summarisation, code generation, document analysis, or decision support without building a model company from scratch. That is the same dynamic as mainframe to Unix, and on-premises to cloud.
The dot-com parallel is worth keeping in mind. Companies are pouring money into AI hoping it will pay back quickly. Some of it will. Some of it will not. The verdict is still out for many of these investments. But the lesson from the web is not that the investment is wrong. It is that the payback requires the foundation to be built correctly.
I have worked on production AI features. Specifically, building MCP servers and agent harnesses on AWS Bedrock, adding AI interface layers to existing product APIs, and thinking through governance and security requirements for AI features in multi-tenant SaaS products. What I observe is that most teams are still at the demo stage. The demo works. The architecture is not yet production-ready.
What "nothing disappears" actually means
One observation from 27 years that surprises people: almost no technology truly disappears.
Python existed long before it became the default language of data science and AI tooling. In the late 1990s it was already around, but it did not yet command the centre of gravity it holds today. Java is still in production systems everywhere. C and C++ are still there. .NET evolved and opened. PHP lost mindshare in many engineering circles but did not vanish. Large parts of the web still run on it.
What disappeared was not the technology. What disappeared was each large company maintaining its own pseudo-standards, its own proprietary contracts, its own incompatible implementation of the same idea. What replaced it was agreement: intercommunicable standards, clearly defined contracts, openly accessible implementations.
This matters for AI because the same consolidation is coming. The current fragmentation of AI tooling, model providers, agent frameworks, vector databases, evaluation methods, governance approaches, and deployment patterns is a feature of early-stage transitions, not a permanent state. MCP is an early signal of the kind of protocol agreement that may precede stabilisation.
The through-line
Looking back across mainframe to Unix, Teradata to DB2 UDB, on-premises to cloud, cloud native, and now AI, the pattern does not change.
Economics shift. The barrier that made the previous platform exclusive is removed. The new platform reaches a wider market. Standards form, sometimes slowly, sometimes painfully, but they form. Talent follows. Tooling matures. Adoption becomes inevitable.
The organisations that do well are not always the first movers. They are the ones that recognise the signal early enough to adapt before the transition is fully priced in, and build on the new foundation with the discipline that production systems require.
The organisations that struggle are the ones that wait for certainty. By the time a technology transition is certain, the advantage of moving early has already been captured by someone else.
What this means for engineering leaders right now
The AI transition is real. The economics are shifting in ways that are already visible. The standards are beginning to form. The tooling is maturing rapidly.
The question is not whether to adapt. The question is whether your infrastructure is ready to support AI features in production, not just in demonstration. That question has a specific answer for your specific product, and the answer depends on which AI pattern you are building and where your gaps are across product clarity, compute, data, delivery, model evaluation, lifecycle, security, governance, cost, and operating model.