I was attending a Zoom presentation recently about Platform Engineering 2.0 and how infrastructure needs to evolve for the AI era. The session focused on something that I think many infrastructure engineers, cloud architects, and platform teams are already feeling: Platform Engineering 1.0 got us this far, but it will not be enough for what is coming next.
The presentation was titled “The Platform Engineering 2.0 – Evolving Your Infrastructure for the AI Era”, delivered for the vExpert community by Pankaj Gupta, and it framed Platform Engineering 2.0 as the next major evolution of internal platforms, especially as AI, automation, FinOps, compliance, and multi-persona operations become normal parts of enterprise infrastructure.
Platform Engineering 1.0 Solved an Important Problem
Platform Engineering 1.0 was mainly about reducing cognitive load for developers.
Instead of asking application teams to understand every detail of Kubernetes, networking, storage, CI/CD, security scans, secrets, deployment templates, and infrastructure provisioning, platform teams created internal developer platforms, golden paths, and self-service workflows.
That was a big step forward.
The promise was simple:
Give developers a paved road so they can deploy faster, safer, and with fewer tickets.
And to be fair, this worked. Internal Developer Platforms, golden paths, self-service infrastructure, and platform-as-product thinking helped many organizations move away from slow TicketOps and toward more automated delivery.
But the presentation made a very important point: the same golden paths that helped standardize delivery can also become golden cages.
When platforms become too rigid, they start blocking experimentation. When they only serve developers, they ignore the needs of security teams, ML engineers, data scientists, FinOps teams, business owners, and now AI agents. When compliance is treated as a snapshot instead of a continuous control, the platform starts drifting away from what the business actually needs.
Why Platform Engineering 2.0 Is Needed Now
The biggest shift is AI.
AI is changing how code is written, how applications are deployed, how infrastructure is consumed, and how operations teams troubleshoot. Developers are producing more code with AI-assisted tools. That means more pull requests, more pipelines, more deployments, more environments, more logs, and more infrastructure demand.
The bottleneck is moving.
In many organizations, the bottleneck is no longer writing code. The bottleneck is now:
- delivering code safely,
- provisioning infrastructure quickly,
- securing AI-enabled applications,
- governing cost,
- supporting GPU-based workloads,
- exposing APIs for automation,
- and preparing platforms for agentic operations.
This is where Platform Engineering 2.0 comes in.
Platform Engineering 2.0 is not a replacement for Platform Engineering 1.0. It builds on it. The idea of platform as a product remains important, but the platform itself must become more intelligent, more composable, more secure, and more business-aware.
The Five Pillars of Platform Engineering 2.0
The presentation described five major pillars:
- AI Native Platform
- Multi-Persona Experience
- Embedded FinOps
- Security Shifts Down
- Composable by Design
These five areas are very relevant to VMware Cloud Foundation environments because they all depend on the same foundation: infrastructure.
You can have the best AI strategy in PowerPoint, but if your platform cannot provision GPU resources, enforce policy, provide observability, manage cost, expose APIs, and support secure automation, then AI will remain disconnected from real operations.
1. AI Native Platform
The first pillar is the AI native platform.
This does not simply mean “add a chatbot to the portal.” It means the platform must be able to support AI workloads as first-class citizens.
That includes things like:
- GPU provisioning,
- model serving,
- model registries,
- ML pipelines,
- MCP servers,
- guardrails,
- audit trails,
- and policy enforcement.
The presentation also discussed AI agents as future platform citizens. This is a very important concept. Today, most platforms are designed for humans clicking buttons, raising requests, or running pipelines. But tomorrow, platforms will also be consumed by AI agents.
That means the platform needs strong APIs, scoped permissions, audit logging, and clear policy boundaries.
In other words, AI agents should not be treated as magical administrators. They should be treated like any other platform consumer: authenticated, authorized, audited, and governed.
Quick VMware Explore Advert
This topic is also very close to what I will be presenting at VMware Explore 2026 Las Vegas.
AI-Powered VMware Cloud Foundation: How I Cut a 4-Hour Task Down to 4 Minutes
Session ID: CODEQT1326LV
Generative AI is not just a boardroom conversation; it is changing how infrastructure engineers work right now.
In this Quick Talk, I will walk through how I integrated Claude CLI, Cursor, MCPs, and GitHub Actions into my VMware Cloud Foundation operations to automate capacity planning, accelerate troubleshooting by correlating PagerDuty alerts with Splunk logs, generate user stories, and deliver real-time Slack notifications.
The result was dramatic time savings, fewer human errors, and a workflow that lets me focus on what matters.
Built on VMware Cloud Foundation and Private AI Services, this is private AI put to work practically, securely, and at scale.
Primary Track: Innovation
Secondary Track: Cloud Infrastructure
Session Type: Quick Talk
Level: Technical 300
Product: VMware Cloud Foundation
Additional Product: VMware Cloud Foundation Private AI Services
You can find the session in the VMware Explore catalog here:
https://event.vmware.com/flow/vmware/explore2026lv/content/page/catalog?tab.sessioncatalogtabs=1747347809815001igUo&search=tarnawski
2. Multi-Persona Experience
Platform Engineering 1.0 was mostly developer-focused.
Platform Engineering 2.0 needs to serve more than developers.
Modern infrastructure platforms need to support:
- application developers,
- platform engineers,
- security and compliance teams,
- data scientists,
- ML engineers,
- engineering leaders,
- business leaders,
- FinOps teams,
- and AI agents.
Each persona needs a different experience layer.
A developer may want a self-service deployment template.
A security team may want policy-as-code and continuous compliance.
A FinOps team may want real-time cost attribution.
An ML engineer may want self-service GPU provisioning.
An AI agent may need API-driven access with scoped permissions and audit logs.
The mistake would be to expose the same platform interface to everyone.
A good Platform Engineering 2.0 strategy should provide the right abstraction for the right persona.
3. Embedded FinOps
This was one of the most practical parts of the presentation.
FinOps cannot remain a monthly report that appears after the cloud bill has already arrived. Cost must become a first-class signal inside the platform.
That means developers and operators should see cost impact before provisioning resources, not weeks later.
In a Platform Engineering 2.0 model, FinOps becomes embedded directly into the platform through:
- real-time cost attribution,
- showback and chargeback,
- cost per deployment,
- cost per request,
- team budgets,
- pre-deployment cost gates,
- automated cleanup of unused infrastructure,
- resizing recommendations,
- and AI-specific cost tracking such as GPU time, token usage, and inference cost.
This is especially important as AI workloads grow. GPU-backed workloads and inference-heavy applications can become expensive very quickly. If platforms do not provide cost visibility and guardrails, organizations will struggle with unpredictable bills and poor resource utilization.
The key point is simple:
Infrastructure is where cost originates, so infrastructure is where cost should be governed.
4. Security Shifts Down
For years, we talked about shifting security left.
Shift-left security is still important. Developers should still have security scanning, dependency checks, image scanning, secrets detection, and secure coding practices in their workflows.
But the presentation made a strong argument that shift-left alone is not enough.
Developers are already overloaded. AI is increasing delivery speed, creating more code, more services, and more attack surfaces. Asking developers to own every part of runtime security is not realistic.
This is why security also needs to shift down into the platform.
That means security capabilities should be embedded deep into the infrastructure and runtime layer:
- least privilege by default,
- micro-segmentation,
- mTLS,
- secrets rotation,
- runtime policy enforcement,
- continuous compliance,
- drift detection,
- contextual RBAC,
- AI anomaly detection,
- and auto-remediation for known misconfigurations.
This becomes even more critical for private AI.
AI introduces new risks such as prompt injection, model poisoning, shadow AI usage, and inference data leakage. Traditional SAST and DAST tools were not designed to understand live inference streams or model behavior.
The answer is not simply more developer tools. The platform itself must become the trust boundary.
5. Composable by Design
The final pillar was composability.
This part resonated with me because many enterprise platforms become too tightly coupled over time. One tool depends on another. One pipeline depends on a specific implementation. One portal workflow depends on a custom integration written three years ago by someone who has since left the company.
Composable architecture tries to avoid that.
The idea is to build platform capabilities as modular, API-first, independently deployable building blocks.
The presentation described platform layers such as:
- experience layer,
- orchestration layer,
- capabilities layer,
- integration layer,
- infrastructure layer.
Each layer should be independently evolvable. For example, you should be able to introduce GitHub Actions alongside Jenkins, or replace one observability tool with another, without breaking the entire platform.
This is very important for long-term platform sustainability.
The future of platforms is not simply build versus buy. It is compose.
Use best-of-breed services where they make sense. Build only what differentiates your organization. Keep APIs clean. Keep contracts clear. Avoid locking every workflow into one monolithic platform implementation.
What This Means for VMware Cloud Foundation
For VMware Cloud Foundation customers and platform teams, this direction makes a lot of sense.
VCF already provides a private cloud foundation across compute, storage, networking, lifecycle management, and operations. As AI workloads become more common, the platform needs to become more than just a place where workloads run.
It needs to become the control plane for secure, cost-aware, policy-driven, AI-ready infrastructure.
That includes support for:
- VMs,
- containers,
- AI workloads,
- private AI services,
- automation,
- governance,
- observability,
- and security controls.
The important part is consistency.
A single platform for traditional applications, modern applications, and AI workloads can help reduce operational fragmentation. Instead of every team building their own isolated stack, the enterprise platform can provide common policy, security, compliance, and operational controls.
My Takeaway
The biggest takeaway for me is that Platform Engineering 2.0 is not just about developer experience anymore.
It is about creating a strategic infrastructure platform for the AI era.
Platform teams are no longer just building portals and templates. They are building the operating model for how the business consumes infrastructure, deploys applications, manages AI workloads, controls cost, and enforces security.
That is a much bigger responsibility, but also a much bigger opportunity.
Platform Engineering 1.0 helped developers move faster.
Platform Engineering 2.0 needs to help the whole organization move faster, safer, cheaper, and with more intelligence built into the platform itself.
For infrastructure engineers, this is exactly where things get interesting. The AI conversation is not only happening at the application layer. It is coming directly into infrastructure operations, platform automation, security, FinOps, and private cloud.
And that is why I think Platform Engineering 2.0 is going to be one of the most important infrastructure topics over the next few years.
