Platform engineering has a funny way of circling back to where it started. The first wave of platform engineering was born out of Kubernetes complexity. Kubernetes gave enterprises a powerful way to run modern applications, but it also dropped a lot of operational machinery into the laps of developers who never asked to become part-time infrastructure engineers. Suddenly, teams that wanted to ship software were dealing with YAML sprawl, clusters, deployment patterns, service meshes, ingress, observability, RBAC and a whole collection of cloud-native concerns that were both important and easy to get wrong.
That was the original opening for platform engineering. Platform teams became the layer that absorbed, organized and abstracted that complexity. They created the paved roads that let developers move faster without forcing every application team to understand every detail of the underlying infrastructure. In that first chapter, platform engineering was fundamentally about orchestration, management and abstraction. Kubernetes was the thing being orchestrated, but the deeper mission was always about reducing operational chaos and making it consumable.
Then the industry shifted toward IDPs. Backstage became the most visible symbol of that phase, and the language of platform engineering moved toward golden paths, service catalogs, templates, self-service workflows and developer experience. That was a necessary evolution. Large engineering organizations needed a front door. Developers needed discoverability. Teams needed consistency. Platform capabilities needed to be packaged in a way that humans could actually use without opening tickets for everything or reinventing the same operational patterns across every group.
The problem is that the market started to confuse the front door with the house. The portal became the story, when the portal was really just the human interface sitting on top of the deeper platform machinery. That distinction matters now because AI is pushing platform engineering into another transition. The next wave of complexity is not just infrastructure complexity, and it is not just developer workflow complexity. It is automation complexity.
This is the part I think a lot of the current conversation misses. The easy story is that AI will make IDPs smarter. Add a copilot. Add a chat interface. Let developers ask the portal questions. That may be useful, but it is not the big story. The bigger shift is that software delivery and operations are becoming increasingly automated, and in some places increasingly agentic. Workflows are starting to trigger other workflows. Security systems are recommending or initiating remediation. AI agents are beginning to interact with development pipelines, service catalogs, ticketing systems, cloud environments and operational data. Policy engines are being asked to make decisions in real time. Machine identities are becoming as important as human identities.
That world does not need a prettier homepage as much as it needs a trusted orchestration layer. It needs a way to manage which agents can do what, which workflows can trigger which actions, where humans need to approve changes, how policies are enforced and how the organization can audit what happened after the fact. That is not traditional developer experience work. That is operational control-plane work.
In other words, platform engineering is being pulled back toward orchestration, but the object of orchestration has changed. In the Kubernetes era, the platform team orchestrated containers and infrastructure complexity. In the portal era, it orchestrated developer access to standardized workflows and services. In the AI era, it may increasingly orchestrate automated operational systems that involve humans, agents, infrastructure, security controls, governance rules and business workflows all interacting with one another.
That is a much larger mandate than building an IDP. It also explains why the IDP language is starting to feel a little too narrow. The portal still matters, but it is not the center of the next story. The center is the orchestration substrate underneath it. Service catalogs become machine-readable maps of operational reality. Golden paths become executable workflows. Governance policies become active controls. Automation becomes something that needs to be supervised, bounded and observed, not merely enabled.
There is a certain irony in all of this. Platform engineering started as a way to protect developers from infrastructure complexity. Then it became a way to improve developer experience. Now AI is making the operational side impossible to ignore again. The platform team may once again be the group asked to make complexity safe for the rest of the organization, only this time the complexity is not just Kubernetes. It is the growing web of automated and semi-autonomous systems that will increasingly shape how software gets built, secured, deployed and operated.
That is why this moment feels bigger than the usual tooling cycle. If enterprises get this wrong, they will not merely end up with messy portals. They will end up with automated workflows no one fully understands, agents acting without clear boundaries, remediation systems creating new risks, and governance processes that cannot keep up with the speed of the machines they are supposed to control. That is not a developer productivity problem. That is an operating model problem.
Platform engineering is well positioned to own this next layer because the discipline has always lived at the intersection of infrastructure, developer workflows and operational governance. Good platform teams already think in terms of paved roads, guardrails, repeatability and safe self-service. Those same instincts are exactly what enterprises will need as AI-driven workflows become more common. The difference is that the platform will have to serve both human developers and machine actors. It will have to make automation useful without letting it become ungovernable.
The market will probably keep talking about AI-enhanced portals for a while because that is easy to demo. But the more important transition is happening underneath the UI. The real question is whether platform engineering becomes the control plane for automated software operations. If it does, the next era of platform engineering will look less like a portal project and more like a new form of systems engineering for the AI age.
Shimmy’s Take
The IDP was never the destination. It was a stage in the evolution of platform engineering, and an important one. But AI is forcing the industry to look past the interface and back down into the machinery that actually makes modern software delivery work.
Platform engineering began by abstracting Kubernetes complexity. It moved into portals and developer self-service because humans needed a better way to consume that abstraction. Now AI is pushing the discipline back toward orchestration, only this time the thing being orchestrated is far bigger than infrastructure. It is workflows, agents, policies, machine identities and automated operational decisions.
That is the real shift. Not smarter portals. Not another dashboard. Not another layer of AI sparkle on top of the same old workflows. Platform engineering is becoming the place where automated software operations are made governable. That may not be as easy to demo as a chatbot in an IDP, but it is where the future of the discipline is actually headed.