Platform engineering has reached a critical inflection point. The original model - built around developer experience and golden paths - is hitting structural ceilings as AI workloads, autonomous agents, and rising infrastructure costs reshape what platforms must deliver. This post distills a conversation between two platform engineering experts on what comes next: Platform Engineering 2.0.

Main insights

• Platform engineering adoption is now near-universal at 90%, but the app-developer-centric model no longer meets today's demands for AI support, multi-persona experiences, and embedded cost management
• Five pillars define Platform Engineering 2.0: AI-native infrastructure, multi-persona experience, embedded FinOps, security shift-down, and composable architecture
• Agents will soon outnumber human developers, creating unprecedented scale challenges that platforms must address now
• Organizations must set 12-month AI-native platform milestones today - the window is shorter than it appears

Sam Barlien organizes the Platform Engineering Community, manages Platform Weekly, co-hosts PlatformCon, and drives the community Ambassador program. Pankaj Dhingra serves as Senior Director of Private Cloud Solutions at VMware by Broadcom, bringing deep expertise in modern applications, Kubernetes, AI workloads, and platform architecture. Together, they make the case for why platform teams must evolve - and how.

You can watch the full discussion here if you missed it.

Platform engineering has moved beyond adoption

The data tells a clear story: platform engineering is no longer a question of "if." According to recent research, 90% of organizations have already adopted platform engineering, 76% have dedicated platform teams, and 80% view AI integration as critical for their internal developer platforms.

"We're not in a territory now where we're thinking about, oh, what is this platform thing? Should we adopt it? That conversation is over," Sam explains.

The challenge has shifted from adoption to evolution. Three years ago, the community debated what platform engineering was. Today, most organizations have built platforms, are actively building them, or have maintained them for years. The question now is: are those platforms equipped for what's coming?

Why the traditional model hits a ceiling

The original platform engineering model emerged from DevOps burnout. It focused almost exclusively on reducing cognitive load for application developers through golden path standardization and shifting security left into pipelines. That approach delivered real value - but it was built for a 2022-2023 world.

Sam identifies several critical gaps in the traditional approach:

• No AI support: The original model predates the AI revolution and provides no framework for GPU provisioning, model serving, or agent infrastructure
• Single persona focus: Platforms indexed heavily on application developers while ignoring data scientists, ML engineers, security teams, and other critical roles
• Reactive evolution: Many platforms grew through ad-hoc problem-solving rather than proactive product thinking
• Golden cages: Opinionated paths often became restrictive rather than enabling
• Outdated compliance posture: Built before today's regulatory environment, including frameworks like the EU Cyber Resiliency Act and EU AI Act

"Many platforms built on those models from a few years ago don't really respond effectively to all of this stuff coming against them," Sam notes.

Five forces demanding platform evolution

Platform teams face pressure from multiple directions simultaneously. Five forces explain why evolution is urgent rather than optional:

1. AI-driven coding acceleration has increased code production by 10-30x in many organizations, with more than 90% of developers now using AI tools
2. Autonomous agents represent an entirely new non-human persona that platforms must support - open source agentic projects are growing faster than almost any project in history
3. Cloud and AI cost pressure creates what Sam calls a "FinOps reckoning," with average public cloud utilization sitting at just 8% CPU, 20% memory, and 5% GPU according to Cast AI's 2026 State of Kubernetes Optimization report
4. Multi-persona organizations require platforms to serve data scientists, ML engineers, security teams, SREs, and even non-technical teams spinning up micro-apps
5. Sovereignty regulation introduces new compliance requirements that platform teams are uniquely positioned to address

The five pillars of Platform Engineering 2.0

Pankaj is clear on one point: "Platform Engineering 2.0 is not a reset. It is an evolution of platform engineering 1.0." The core principles remain - treating platforms as products, increasing developer productivity, improving efficiency. What changes is how platforms operate, which personas they serve, and what goals they pursue.

Pillar 1: AI-native infrastructure

Platforms must support AI workloads natively - whether building, governing, or protecting them. This requires infrastructure that didn't exist in the original model: GPU and TPU provisioning, model serving, model registries for security and compliance, AI gateways, MCP (Model Context Protocol) servers, and pipelines with appropriate guardrails.

Beyond supporting AI workloads, platforms must treat AI agents as first-class citizens. "Agents are basically LLM-powered agents who are able to reason, plan, use tools, and execute tasks in a bounded scope," Pankaj explains. Organizations will deploy two types: customer-facing agents that streamline processes, and platform-optimizing agents that handle incident triage and environment provisioning.

The long-term vision is autonomous platforms where agents, control loops, policy engines, and telemetry work together for self-healing, self-optimizing, and self-scaling infrastructure. Platforms must also consolidate support for containers, VMs, and AI workloads under a single operational model - delivering consistent policy, security, and compliance across all workload types.

Pillar 2: Multi-persona experience

This pillar binds Platform Engineering 2.0 together. The original model served two personas: application developers and platform engineers. Platform Engineering 2.0 expands to serve six additional personas, each with distinct requirements:

• Data scientists and ML engineers need self-service GPU provisioning, model registries, and experiment tracking
• Security and compliance teams need policy-as-code and continuous compliance rather than point-in-time checks
• Engineering and business leaders need FinOps transparency, predictability, and DORA metrics
• AI agents need APIs, RBAC permissions, MCP servers and gateways, governance, audit logging, and strong guardrails

That last persona is the most significant shift. "This persona is going to outnumber the rest of the personas," Pankaj notes, referencing Microsoft's expectation of 20 million agents operating internally. Platforms must now support both human and non-human identities with appropriate controls.

Pillar 3: Embedded FinOps

Developer productivity has long been a first-class signal in platform engineering. In Platform Engineering 2.0, cost becomes an equally important first-class signal. Today's FinOps is bolt-on, reactive, and siloed - and the numbers reflect it. Beyond the utilization figures above, organizations are burning through token budgets at rates that outpace annual forecasts.

Embedded FinOps means building cost awareness directly into the platform: self-service FinOps by default, real-time cost attribution, and pre-deployment cost gates. Think of it like a corporate travel booking system - when you spin up a new environment, the platform shows comparative costs between public and private cloud and warns you when projected spend exceeds policy thresholds.

"When you embed FinOps into the platform itself, the platform moves from visibility to influencing decisions at the point of provisioning," Pankaj explains. That shift - from reporting to prevention - is what makes FinOps a platform concern rather than a finance team concern.

Pillar 4: Security shift-down

Shift-left security promised that developers would own security by embedding SAST, DAST, and SCA tools into pipelines. The reality fell short: it increased cognitive load on developers, and most vulnerabilities are still found in production because pipeline scans miss runtime context.

Platform Engineering 2.0 complements shift-left with shift-down security. "Shift left catches security issues early, and shift down catches everything else that shift left couldn't catch," Pankaj explains. This happens through two mechanisms: embedding security deep into the platform infrastructure itself, and enforcing policy at runtime.

Security embedded in the platform means making infrastructure secure by design - enforcing least privilege, enabling mutual TLS, creating stronger segmentation between workloads and agents, managing secrets properly, and achieving efficiency through policy-as-code. Critically, this security must become invisible and immutable: you cannot bypass it.

AI widens the security gap significantly. Every new AI component introduces new attack surfaces - shadow AI, prompt injection, model poisoning, and inference data leaks. "Platform engineering has to address that, and many of you are already seeing shadow AI sprawl in your organization," Pankaj warns. Strong model registry governance and enforced data isolation are immediate actions you can take today.

Pillar 5: Composable architecture

Composable architecture has been discussed for years, but Platform Engineering 2.0 adds a critical new emphasis: repavability. Platform capabilities are delivered as modular, independently deployable, and interchangeable building blocks connected through well-defined contracts, policies, and SLAs. "You should be able to evolve each layer independently without cascading those changes," Pankaj explains.

Repavability means you can swap one component for another - replacing Jenkins with Harness, switching CNIs, or adopting a different GPU series - and the platform adapts quickly. This builds on familiar foundations like modular design and API-first contracts, but adds CI/CD concepts like progressive rollout and progressive migration between components.

"We believe the future of the platform is not going to be build and buy. It's going to be composed," Pankaj states.

What to do starting Monday

For platform engineers: Start by defining distinct experience layers for each persona your platform serves. Adopt API-first, composable architecture if you haven't already. Examine every security and FinOps process connected to people and identify what you can embed in the platform immediately - container scanning, SAST, DAST, automatic reporting, or automatic dashboards. Then assess your readiness for agentic infrastructure. "I'm telling you this is going to come faster than you expect," Sam emphasizes.

For executives and senior leaders: Mandate this evolution as a business case. Tie platform investment to velocity changes, cloud cost reduction, and AI readiness metrics. Establish a platform P&L - if you treat your platform as a product, it needs profit and loss tracking like any product. Set a 12-month AI-native platform milestone. "12 months feels like a long time. It is incredibly short in this," Sam warns.

Your executives, business teams, and developers will spin up their own agents regardless of whether your platform is ready. The question is whether you control it, keep it safe and secure, and extract value from it - or not.

​

If you enjoyed this, find here more great insights and events from our Platform Engineering Community.

If you want to dive deeper, explore our instructor-led Platform Engineering Certified Professional course and connect with peers from large-scale enterprises who are driving platform engineering initiatives.

​

Key takeaways

• Platform engineering has evolved beyond adoption into execution: With 90% of organizations already running platforms, the conversation has shifted from "why platform engineering" to "how to evolve platforms" for AI, agents, and multi-persona support. Platform teams must move from reactive problem-solving to proactive product thinking.
• Five pillars define the next generation: AI-native infrastructure, multi-persona experience, embedded FinOps, security shift-down, and composable architecture form the foundation of Platform Engineering 2.0. These pillars work together with infrastructure as the common substrate, addressing the convergence of forces demanding platform evolution.
• Agents will outnumber human developers: Organizations must prepare now for agentic infrastructure with proper APIs, permissions, MCP servers, gateways, and strong guardrails. The scale challenge is unprecedented - Microsoft expects 20 million agents internally - requiring platforms to support both human and non-human identities with appropriate controls.
• Cost management becomes a first-class platform concern: With cloud utilization at 8% CPU, 20% memory, and 5% GPU, plus rising token costs, platforms must embed FinOps directly into provisioning decisions rather than treating it as bolt-on reporting. Real-time cost attribution, pre-deployment cost gates, and self-service FinOps by default move platforms from visibility to influence.