Is Platform Engineering Already Obsolete?

We recently spent some time with the VMware leadership to get an inside track on its thinking, and we firmly came away with a perspective that the industry is witnessing a necessary maturation of the platform engineering discipline. What we are observing is that the initial wins of the last five years, such as establishing internal developer platforms and golden paths, have created a stable substrate. However, this substrate is currently being strained by a new reality. our analysis is that the core issue is not the failure of initial platform designs, but their inadequacy in the face of rapid AI-driven change.

The assumption that platform engineering serves only a narrow population of application developers is quickly fading. We are now seeing platforms designed to function as centralized governance layers for the entire enterprise. Traditional Virtual Machines (VMs) continue to serve as the baseline compute model, accounting for 40.0% of all current workloads, followed by containers at 27.9%, bare metal at 15.1%, and serverless at 12.2% (according to HyperFRAME Lens: State of Infrastructure and Operations - 2Q 2026).

We find that VMware Cloud Foundation (VCF9) explicitly treats VMs and containers as equal citizens to simplify modern application deployment. Because VMs (40.0%) and containers (27.9%) together command the vast majority (67.9%) of the current enterprise compute footprint, Broadcom is aligning its platform directly with this real-world operational mix to prevent Platform Engineering teams from having to switch between disparate interfaces.

This shift is not merely about adding features; it is about expanding the scope to address complex challenges like cloud cost attribution for AI models, strict data residency requirements, and the specific needs of ML engineers and data scientists.

Based on our observations, five specific forces are driving this evolution. First, AI-driven coding assistants have increased code velocity so dramatically that delivery pipelines built for human-paced work are failing. Second, the rise of autonomous agents requires platforms to handle advanced infrastructure needs, including GPU and TPU management, which were not prioritized in earlier cycles. Third, the explosion of tokenomics has rendered traditional cost-reporting tools largely invisible to the real expenses of LLM usage. Fourth, regulatory pressures around AI safety and data sovereignty have placed new security burdens directly onto the platform. Finally, the need to serve diverse personas, from FinOps to security teams, requires a far more composable approach than we previously saw.

Our perspective is that organizations should treat these five pillars not as individual projects, but as a compounding framework. Teams that continue to view these as disparate tickets will likely struggle with structural debt. Those who view them as an interconnected evolution of their platform as a product will find the path forward much clearer. The goal is to move from simply removing friction for developers to enabling organizational agility at scale.

We are seeing a distinct movement where infrastructure is being reclaimed as a first-class platform concern. In the early days, platform engineering focused heavily on developer experience, often treating the underlying infrastructure as a utility that was managed separately. That is no longer sufficient. To succeed in the AI era, platform teams must have deep control over the infrastructure layer to manage the complexities of modern, agent-heavy applications. This is designed to ensure that platforms can host the next generation of enterprise software without being bypassed by teams frustrated with slow or rigid systems.

As we noted in Broadcom’s recently issued paper, the most underrated limitation in PE 1.0 is persona scope. Most platforms left security teams, data scientists, AI agents, and FinOps analysts to build their own toolchains, producing shadow IT at scale. A platform that serves one persona in a multi-persona organization serves a shrinking fraction of its potential value. PE 2.0 addresses this structurally. We summed up our perspective when we commented: Platform engineering is no longer a software delivery discipline.

It is becoming the operational foundation for the enterprise’s agentic future. The teams that built golden paths and self-service IDPs now hold the substrate for AI-native infrastructure and autonomous agent governance. This is the largest mandate the discipline has ever held, and a defining opportunity for IT leaders willing to act now.

VMware’s Strategy

Broadcom is aligning its core private cloud offering directly with these new requirements through the continued evolution of VCF9. This infrastructure platform treats virtual machines and containers as equal citizens to simplify modern application deployment. Which is key for Platform Engineering teams who just want to orchestrate and operate IT systems rather than switch between interfaces with all of the downstream issues that this leads to.

The system is explicitly architected to manage mixed compute environments by balancing central processing units for agent workflows alongside GPUs for model inference. VCF9 aims to deliver advanced security features like automated microsegmentation to protect distributed workloads without adding operational hurdles for developers.

Moreover, the strategy includes comprehensive cost transparency tools designed to give engineering leaders a clear view of total data center and software expenses. By providing native self-service capabilities and declarative operations, the platform closely mirrors the automation principles found in public cloud setups. This focus on local data control and cryptographic authority directly addresses the strict data sovereignty needs of highly regulated industries. We see this strategy as a direct attempt to provide a unified foundation that prevents engineering teams from routing around enterprise IT.