Earlier this year I described what I called DevOps theater: organizations that renamed their operations team, bought a CI/CD tool, and declared the transformation complete while the culture stayed exactly where it was. A few weeks later I wrote that IaC is a prerequisite for DevOps, not the destination, after watching team after team confuse having Terraform templates with having an operational practice.
Both posts diagnosed what was broken. This one offers a constructive model for what should replace it.
The team that accidentally built a platform
A logistics company we worked with in 2024 had the usual problems. Four product teams, each provisioning its own AWS accounts, writing its own Terraform, maintaining its own CI/CD pipelines. Two teams used GitHub Actions, one used CodePipeline, the fourth had a Jenkins instance that a developer who had since left had set up three years earlier and nobody dared touch.
When the CTO mandated AI coding tools across all squads in early 2025, the inconsistency became untenable. Claude Code generated infrastructure configurations that assumed a pipeline structure matching whichever team had written the most training data. Deployments broke in ways that were different for every team, and debugging required understanding four separate operational stacks.
The infrastructure lead did something unglamorous. She spent three months building a shared set of deployment templates, a common pipeline configuration, and a self-service portal where product teams could provision pre-approved infrastructure without filing a ticket. She did not call it a platform. She called it “making it so I stop getting paged at 3 AM because someone else’s Terraform didn’t work.”
Within six months, deployment failures across the four teams dropped measurably. The time from code commit to production went from days (variable by team) to hours (consistent). And the AI coding tools started producing infrastructure configurations that actually worked on the first try, because the underlying environment was consistent enough for the generated code to be predictable.
She had built an internal developer platform without knowing the term.
What platform engineering actually is
The vocabulary comes from Team Topologies, the 2019 book by Matthew Skelton and Manuel Pais that gave the industry a shared language for how teams should interact. Their definition of a platform team is specific: a team whose job is to reduce the extraneous cognitive load on stream-aligned teams by providing self-service capabilities.
Evan Bottcher’s widely cited definition sharpens this further: “A digital platform is a foundation of self-service APIs, tools, services, knowledge, and support which are arranged as a compelling internal product.”
“Self-service” means the consuming team can use the platform without filing a ticket, joining a call, or waiting for an approval. “Internal product” means the platform team treats its developers as customers, with a roadmap, feedback loops, and a product manager, the same way a SaaS company treats its users.
This is the distinction that separates platform engineering from the old centralized infrastructure team wearing a new badge. The old model was a service desk: you requested infrastructure, someone provisioned it, and the feedback loop was a Jira ticket status. The new model is a product: you pick from a catalog of pre-approved, self-service capabilities, and the feedback loop is whether developers actually use the thing voluntarily.
The relabeling trap
The biggest risk with platform engineering is exactly the pattern I diagnosed in DevOps Theater: renaming the team without changing the behavior.
Gregor Hohpe, whose Platform Strategy (2024) is the most detailed treatment of how organizations build and govern internal platforms, calls this “organizational debt”: accumulated structural decisions that no longer match the organization’s operating context. A platform team stood up by mandate, staffed with the same people who ran the old centralized infrastructure team, given no product manager, and measured by uptime rather than developer adoption is organizational debt wearing a new label.
The data confirms this is happening at scale. Humanitec’s State of Platform Engineering Vol. 4 survey found that 36.6% of platform engineering adoption is mandate-driven compared to 28.2% that is value-driven, and 29.6% of platform teams don’t measure their own success at all. A practitioner writing in August 2026 put it bluntly: “Platform teams became the new gatekeepers we said we hated.”
Charity Majors offers the diagnostic test: “A platform you can bypass is a road. A platform you must use is a wall.” If developers route around your platform, the platform has become a gate rather than a service. In one engagement we reviewed, more than half of developers had built their own deployment workarounds rather than use the official platform, because the platform’s approval process was slower than doing the work manually.
A portal, a catalog, and a “platform team” on the org chart do not add up to a capability if developers still file tickets to get anything done.
What separates a platform from a renamed ops team
Across the engagements where we have seen platform engineering deliver real results, five characteristics distinguish a functioning platform from one that is just centralized operations under a new name.
The platform has a product manager. Someone owns developer experience the way a product manager owns customer experience. They run surveys, track adoption, maintain a roadmap, and prioritize based on what developers actually need rather than what the infrastructure team thinks they should need. In the engagements I have seen, assigning product ownership is often the difference between a platform that developers adopt and a service desk with a portal.
Developers choose to use it. The platform offers golden paths, opinionated and pre-configured defaults for common tasks, and developers adopt them because they are faster and more reliable than the alternative. Mandating usage is the warning sign. Measuring adoption rate voluntarily is the health indicator.
The platform team ships, it does not approve. Consuming teams do not wait for the platform team to provision infrastructure, review configurations, or approve changes. The platform provides the guardrails (policy-as-code, automated compliance checks, pre-approved templates), and the consuming team operates within those guardrails autonomously. The platform team’s work is done before the consuming team starts, not after.
Feedback flows backward. When a developer hits a limitation in the platform, that limitation becomes a backlog item for the platform team. The feedback loop runs from consumer to provider, the same direction as any product feedback loop. In the old model, feedback ran the other direction: the infrastructure team told developers what they could have. That inversion is the behavioral change that separates the two models.
Cognitive load is measurable, and measured. The platform team knows which tasks consume the most developer time, which workflows generate the most support requests, and which golden paths have the highest adoption. They measure cognitive load reduction the way a SaaS product measures time-to-value. If the platform team cannot articulate what cognitive load they removed this quarter, they are maintaining infrastructure, not running a platform.
Why this matters more in an AI-accelerated environment
DORA’s 2026 report, The ROI of AI-assisted Software Development, frames AI as an amplifier: in teams with solid delivery practices, AI expands capacity; in teams with slow reviews, fragile tests, and undocumented architecture, AI amplifies the dysfunction that already exists. The report introduces a “verification tax,” the additional effort required to check whether AI-generated code is reliable, secure, and aligned with the system’s architecture. When that tax is high, the speed AI adds during coding gets consumed during review, testing, and incident response.
A platform directly lowers that tax. When the environment is consistent, the golden paths encode good defaults, and the guardrails enforce policy before deployment, AI-generated code has fewer assumptions to get wrong. DORA’s companion 2025 AI Capabilities Model identified internal platform quality as one of seven capabilities that amplify AI’s benefits, and the logistics company in my opening story is a small example of the same mechanism: once the environment was standardized, the AI’s output became predictable.
Puppet’s 2026 State of Platform Engineering report points in the same direction. Organizations that scored high on platform maturity self-reported 73% success with AI-assisted development workflows, compared to 44% for organizations with low maturity. The survey measured perceived effectiveness rather than delivery metrics, but the pattern is consistent: platforms lower the verification tax, and teams that pay less of it capture more of AI’s speed as actual delivery.
DevOps theater persists because the underlying operational model never changed. Platform engineering, done properly, changes the operational model by turning infrastructure from a service desk into a product. AI accelerates everything that runs on that model, everything. Organizations with a functioning platform get compounding returns from AI. Organizations performing platform theater get compounding complexity.
What healthy looks like
Gartner predicted that 80% of large engineering organizations would have dedicated platform teams by 2026, up from 45% in 2022. The adoption happened. Most of those teams still operate the way they did before the reorg.
Here is what I see in the organizations where the model is working.
The platform team is small. In the engagements where we have seen this work, five to eight people serve a hundred-person engineering organization, though the right number depends on the regulatory burden, the number of distinct service types, and how many golden paths the organization needs. They do not run production for the consuming teams; they provide the capabilities that let consuming teams run their own production. They maintain the golden paths, the policy-as-code guardrails, the self-service provisioning, and the observability baseline. They have a product manager who owns the developer experience backlog.
The consuming teams deploy without waiting for anyone. They pick a golden path (a pre-configured deployment template, a standard observability stack, a pre-approved database configuration), customize what they need, and ship. The guardrails are embedded in the pipeline, so policy violations fail the build rather than require a human review. Defaults do the work: a consuming team that follows the golden path inherits encryption, tagging, logging, and cost controls without configuring any of them.
Architecture reviews shift scope when a platform exists. The repeated infrastructure decisions, the ones that recur across every team, get reviewed at the platform level, where one review surfaces issues that would otherwise require reviewing every team individually. Service-specific decisions, the ones that depend on a team’s data model, failure modes, or customer-facing behavior, still belong with the team. When AI-accelerated teams need architecture reviews more than ever, the platform absorbs the common cases so the team-level reviews can focus on what is genuinely unique.
And the measurement is developer-centric, not infrastructure-centric. The platform team tracks adoption rate, time-to-first-deploy for new teams, support ticket volume (trending down is healthy), and the fraction of deployments that use golden paths versus custom configurations. Sustained bypass of a golden path is a product signal: something about the path does not serve the team, and the platform backlog should reflect that.
Where this breaks
Platform engineering can fail in all the ways DevOps theater did, and for the same reasons. A mandate without a product manager is a service desk. A portal nobody uses is a website. Golden paths that developers bypass are suggestions, not infrastructure.
AWS built its own platform-engineering-enablement product, Proton, and is deprecating it in October 2026. If the hyperscaler that sells the underlying infrastructure could not make its own platform product stick, the lesson is worth absorbing: a platform discipline outlasts any particular tool, and the organizations that confused the product for the practice will start over when the product is retired.
Getting this right requires understanding that the problem was never the tools. It was whether the adoption changed how people work, or just how the org chart reads.
The infrastructure lead from my opening story didn’t set out to build a platform. She set out to stop getting paged for problems that weren’t hers. The platform emerged because she treated the work as a product her colleagues needed, not a service they were required to use. Her platform worked because developers reached for it when they needed to ship, and that told her which parts were worth maintaining.
Ricardo
