Platform engineering has won the argument. 90% of organizations have adopted it, 76% run a dedicated platform team, and nobody serious is still debating whether to build an internal platform. Everything's perfect then right? Well, as we all know tech never stays stable for long. The platform you already built, the one that won that argument, was designed for a world that is being blown up in real time. Simple containerized workloads. Human-paced development. A simple mandate of serving developers. Annual cycles of change. Every one of those assumptions is now wrong.
That is the gap our new report is about. Today we are launching Platform Engineering 2.0: An evolution for the AI era, co-authored by Pankaj Gupta at Broadcom and myself. It is a multi-year directional framework for platform teams and the executives who fund them, grounded in data from our State of Platform Engineering and State of AI reports, DORA 2025, and dozens of expert interviews across our 280,000-strong community.
Evolution, not revolution
Let's kill the most likely misread up front. Platform engineering 2.0 is not a reset, and it is not a rebuild. It is an evolution. So you can delete the social media headline, "platform engineering is dead." As we are very far from that.
The foundations the discipline laid down between 2019 and 2025 are far from obsolete, and your investment in them is not wasted. Platform as Product, golden paths, shift-left security, and self-service Internal Developer Platforms (IDPs) are the substrate everything else stands on. The discipline does not restart at each phase. It accumulates. What changes in 2.0 is who the platform serves, what it has to do, how it gets built, and how deliberately it treats infrastructure as a first-class platform concern. In the AI era, infrastructure is not just the substrate beneath the platform. It is one of the main determinants of how far the platform can evolve.
So why does a foundation that good need extending at all? Because over the past two years, five forces have piled onto platforms that weren't designed to carry them. Left unanswered, your platform doesn't just fall behind. It becomes the exact bottleneck that you built it to eliminate, and the teams it was meant to serve start ignoring or routing around it.
"What started as a developer productivity function is now the centralised governance layer for the enterprise - enforcing cost discipline, security posture, and AI readiness across every team. The platforms that can absorb that scope without structural debt aren't the ones built around fixed architectures. They're the ones built to be composable from day one. 1.0 solved the developer problem. 2.0 solves the enterprise problem. Both built by same teams, but with a different mandate." - Atulpriya Sharma, Co-Organiser, CNCF Platform Engineering Technical Community Group
The five forces forcing the issue
Let's start with the obvious. AI-driven coding acceleration. I've spoken on almost 2 dozen panels, roundtables, and webinars in the last 6 months and the core topic every single time was this - 90% of developers now use AI coding assistants, code volumes are up 2 to 10x, and the bottleneck has moved from writing code to shipping it. A platform tuned for human-paced delivery can't keep up with this new reality, and it was never designed for this version of the job.
Then there is a new user who's showed up far faster than anyone ever imagined. Autonomous agent. They need GPU and TPU allocation, MCP gateways, bounded-autonomy guardrails, audit logging, and policy enforcement for the decisions they make on your behalf. Platforms that cannot host agents will not host the next generation of enterprise applications, and will likely be devoured by the organisations that do. It really is that blunt.
Cost is the third force. The industry still wastes around 35% of its cloud spend, and AI infrastructure is pouring fuel on that fire. On top of the inferno, sits the tokenomics of large language models, the per-token cost of every prompt, every retry, every coding-assistant call, every time your junior dev uses Fable when they probably could have just used Sonnet, growing token spend (and cost) exponentially and invisible to almost every cost-reporting tool you own.
The fourth force is sovereignty and a security frontier that keeps widening. The EU AI Act, US executive orders on AI safety, sector rules in financial services and healthcare, and hardening data residency requirements all land in the platform's lap. And AI has opened attack surfaces that neither just shifting-left nor your 1.0 architecture was built to catch with new challenges like shadow AI sprawl, prompt injection, model poisoning, inference data leaks.
The fifth is a new multi-persona reality. Your ML engineers want self-service GPU provisioning. Your data scientists want experiment tracking and pipeline orchestration. FinOps wants cost attribution, security wants policy-as-code, leaders want ROI they can actually see. The platform that served application developers brilliantly now has to serve the whole organization, or it serves a shrinking slice of the value it could.
Understand however, that these are not five problems to survive. They are five opportunities, and no discipline is better placed to capture them. The data points the same way from every direction: the foundational layer for enterprise AI success is platform engineering. While other disciplines spend this year asking whether they still matter in an agentic world, platform engineers are staring at the single biggest expansion of mandate the field has ever seen.
A first look at the five pillars
The whitepaper extends the platform engineering foundation across five pillars for the AI era. Each one answers one or more of the forces above and closes a specific gap in today's platforms. Picture Platform as Product at the base, with five pillars rising out of it.
The point worth carrying into the deep dive is this. These are not five separate projects. They compound. A single AI workload landing on a modern platform pulls on all five at once. Teams that treat the pillars as five faces of one evolution capture that. Teams that treat them as five disconnected tickets do not.
Where to start
Platform engineering 2.0 is a direction, not a destination. It is a 3 to 4 year arc running through 2030, and you absolutely do not need to evolve all five pillars at once. Audit your platform against them, then start with the pillar that hurts most today, because that is exactly where you will find executive sponsorship and clear ROI. Begin where the pressure is highest.
The teams that move now will define what platform engineering means for the next decade. The ones that wait will spend that decade behind the curve.
At the same time, remember that infrastructure was the discipline's first foray beyond DevEx. It was the first thing platform engineers ever mastered, and it's where a huge amount of the opportunity now sits. The team that masters infrastructure for the AI era is the team that masters the AI era, and that starts with treating infrastructure as a first-class platform concern rather than the thing under the floorboards.
You can read the full whitepaper, Platform Engineering 2.0: An evolution for the AI era, here, and a dedicated deep dive into the five pillars is coming next. If you want a hand in where this framework goes from here, the conversation is already live in the platformengineering.org community Slack, and it will spill onto the stage at PlatformCon.
