The platform engineering stories enterprise IT leaders actually read.
Volume 341, Issue 3 · 20 articles from 6 issues
An examination of the real financial and operational cost of building an internal developer platform.
The New Stack explores return on investment considerations for platform engineering initiatives, focusing on the true costs of developing custom internal platforms.
Organizations must evaluate expenses beyond initial development, including ongoing maintenance, team resources, and infrastructure investment.
The piece sits within The New Stack's operations coverage under platform engineering and addresses a central concern for engineering leaders deciding whether to build or buy.
The content targets technical decision-makers and enterprise software leaders evaluating platform strategy investments.
Organizations now manage 109 machine identities per human, forcing platform teams to treat identity as core infrastructure.
Modern platforms automatically create machine identities for pods, pipelines, services, and AI agents, producing an identity explosion that platform teams enabled through golden paths and CI/CD infrastructure.
Organizations face critical risks from long-lived secrets, slow credential rotation, and poor visibility into non-human identities, with 68% unable to distinguish AI agent activity from human activity.
Leading organizations are adopting short-lived, automatically issued credentials using SPIFFE and SPIRE, mutual TLS authentication, and least-privilege authorization policies.
As certificate lifetimes shrink from 398 days to 47 days by 2029, manual rotation becomes mathematically impossible, forcing platforms to treat identity lifecycle automation as core infrastructure.
Mature platform engineering practices significantly boost AI adoption success and organizational trust in AI.
According to Perforce Software's 2026 Platform Engineering Report surveying 820 technology professionals, 73% of organizations with mature platform engineering practices cited that maturity as critical to AI success, versus 44% among less mature organizations.
The research indicates AI amplifies both organizational strengths and weaknesses, requiring standardized workflows, automation, governance, and policy enforcement.
Independent validation from Google's DORA program and CNCF research supports the conclusion that strong engineering foundations, not simply AI tool adoption, determine sustainable value from AI implementation.
Platform engineering must extend beyond container workloads to support AI agents, GPUs, and cost controls.
Platform Engineering 2.0 extends established internal developer platform practices across five new pillars: AI-native infrastructure, multi-persona experiences, embedded FinOps, shifted-down security, and composable design.
Organizations must address three critical gaps, GPU provisioning, non-human identity management, and real-time cost attribution, to support emerging AI workloads and agents. The shift reflects how AI coding assistants, autonomous agents, and infrastructure costs have changed developer workflows and platform requirements.
Research indicates 90% of enterprises now use internal platforms, but most lack capabilities for AI-specific demands such as token management and agent governance. The evolution is an architectural extension rather than a rebuild.
Platform engineering must evolve to support AI agents as active users while maintaining governance and safety.
AI-driven code generation has shifted the software bottleneck from writing to deploying code, requiring platform engineering to adapt.
Traditional golden paths work for predictable workloads but become restrictive for experimental AI and agentic workloads that need flexibility.
Platform Engineering 2.0 introduces composable, API-first building blocks instead of rigid templates, treating platforms as products serving multiple personas including AI agents.
The evolution keeps existing IDP foundations while adding capabilities for agent identity, scoped permissions, audit trails, budget controls, and escalation. Infrastructure modernization through dynamic provisioning and immutable artifacts enables safe innovation at scale.
Renaming a DevOps team fails without a product-oriented shift to building internal developer platforms.
Santosh Mahale argues that many organizations undertake superficial platform engineering transitions, updating titles and documentation while operating identically to their DevOps predecessors.
DevOps is a cultural philosophy emphasizing collaboration, whereas platform engineering is an organizational practice focused on building internal developer platforms as products for application teams.
Common failure modes include reactive ticket-driven operations, not treating developers as real customers, overly rigid golden paths that drive workarounds, and measuring traditional ops metrics instead of developer-centric ones.
Platform engineering builds shared infrastructure and workflows that let teams ship software quickly, safely, and at scale.
Alan Shimel defines platform engineering as the discipline of designing shared infrastructure, tooling, and automated workflows that let teams deliver applications quickly, safely, and at scale. The central thesis is that the discipline continuously evolves because applications evolve, making it fundamentally adaptive rather than fixed.
It traces an evolution from informal middleware-based platforms, through the Kubernetes era and internal developer platforms that treat developers as customers, to data and observability becoming core capabilities, and now AI integration requiring GPU provisioning, model serving, and governance. Looking ahead, platforms increasingly manage autonomous agents needing identity, guardrails, and auditability.
Platform engineering means designing an internal developer platform of self-service tools to cut developer complexity.
Mike Vizard describes platform engineering as designing and operating an internal developer platform, a curated layer of self-service tools and automation that lets engineers build and deploy without assembling underlying infrastructure.
The discipline emerged in response to cloud-native complexity, with an IDP able to reduce developers' operational focus by as much as 75 percent. Core components include golden paths, self-service interfaces, developer portals, standardized building blocks, embedded governance, and built-in observability and cost tracking.
Research indicates 90 percent of organizations now use IDPs, 76 percent have dedicated platform teams, and the tools market is forecast to grow 21.9 percent annually through 2030.
A podcast episode on how scalable AI depends on robust platform engineering, recapping PlatformCon NYC.
In this episode of The Platform Engineering Show, Alan Shimel interviews Luca Galante about PlatformCon NYC's success and how platform engineering roles are evolving in the AI era.
Galante argues that a flashy day-zero demo cannot scale into a functional, value-creating AI deployment without a robust, well-designed platform. The discussion highlights how organizations increasingly recognize that effective AI implementation requires solid infrastructure foundations.
Platform engineering teams are expanding beyond traditional IT operations to manage complete software supply chains and establish security controls for enterprise AI systems.
Developer workarounds undermine internal platforms by creating security gaps and fragmented shadow infrastructure.
Internal developer platforms fail when engineers find unauthorized paths that are faster than sanctioned workflows, creating shadow infrastructure and compliance blind spots.
Platform teams should embed security controls directly into self-service workflows and treat workarounds as product feedback rather than misbehavior.
Success should be measured by adoption, developer satisfaction, deployment speed and reliability rather than infrastructure utilization. Making the governed path the fastest path removes the incentive to bypass controls.
Golden paths standardize delivery through self-service workflows that prioritize speed over restrictive mandates.
Golden paths are standardized, self-service routes for building and deploying software, and they only work if they are faster than the workarounds.
Platform teams should standardize high-risk areas such as identity, RBAC and deployment pipelines while leaving application-level choices to developers.
Governance becomes embedded in templates rather than existing as a separate approval gate. Success requires continuous ownership plus measurement of adoption and developer feedback. The most common failure is treating a golden path as a launch instead of an evolving product.
Platform Engineering 2.0 adds model governance and workload isolation to control AI costs and risks.
Steven Vaughan-Nichols argues that Platform Engineering 1.0 infrastructure, built for containerized developer workflows, cannot adequately handle AI workloads, exposing gaps in isolation, multi-plane execution, and trust boundaries.
AI adoption has driven unsustainable costs, with one enterprise seeing Claude API spend climb from 250,000 to 400,000 dollars per day in a single month. Application-level guardrails fail because policy interpretation and security visibility fragment across teams and vendor consoles while shadow AI proliferates.
Platform Engineering 2.0 introduces two pillars: model governance as a central control plane with a registry and routing layer, and workload isolation using zero-trust service identities against prompt injection.
AI coding agents turn environment requests into traffic, so platform teams must serve environments rather than provision them.
Coding agents request test environments like API clients: concurrent, bursty, and short-lived, so a 100-developer org can generate hundreds of requests before lunch.
GitHub's Octoverse counted 43.2 million merged pull requests per month, up 23% year over year. Duplicating the full stack per request costs too much and takes tens of minutes, while a single shared staging environment collapses under queueing effects and cross-tenant contamination.
The author reframes environments as a serving system judged on latency, concurrency, marginal cost and safe multi-tenancy.
The proposed architecture runs one stable copy deployed from main and spins up only changed services, routing requests through them - the pattern sold by Signadot, which sponsored the post.
Platform legibility and developer experience are emerging as reliability metrics that matter more than traditional infrastructure measures.
The article argues that most reliability incidents originate not from infrastructure failures but from developers' inability to confidently predict how changes will behave in complex platforms.
It introduces platform legibility-understanding a system without consulting others-as a better reliability signal than documentation alone.
The author contends that AI-assisted development amplifies existing platform disorder, making structural guardrails and clear golden paths essential. Platform teams should measure success by cognitive load reduction, not features shipped, and track metrics like time-to-first-deploy for new hires to predict future incident rates.
Platform ROI is now measured by business outcomes such as cost reduction and delivery speed, not just developer sentiment.
Engineering leaders increasingly justify platform investment through measurable business metrics including lower cloud costs, faster software delivery and improved infrastructure efficiency. Traditional DORA metrics remain relevant but must connect to revenue and customer satisfaction to hold executive attention.
Mature platform teams treat their platform as a product, align it with business goals, and communicate value in executive-friendly language.
Success requires demonstrating how technical improvements affect the bottom line and operational efficiency.
Cloud sovereignty means the freedom to switch providers, best built into internal developer platforms from the start.
Benjamin Brial argues that cloud sovereignty, defined as the ability to switch providers without painful consequences, has become essential amid regulatory and geopolitical risk.
The real issue is not which provider to choose but whether the platform allows change without penalty.
He illustrates conflicting legal obligations, such as European-resident data still reachable by US courts under the CLOUD Act, creating GDPR exposure. With AWS, Azure, and GCP controlling roughly 70 percent of the European cloud market, concentration creates systemic risk.
The recommended solution is embedding sovereignty into an internal developer platform using infrastructure-as-code stored in Git, designed proactively from inception rather than retrofitted after failures.
Platform engineering success depends on people, culture and process rather than technology choices.
Max Korbacher explains why internal development platforms fail when built with infrastructure-first thinking. Successful platforms require a clear purpose, real user research, a product mindset and community building.
Recommended practices include defining purpose through stakeholder alignment, measuring adoption via DevEx and SPACE metrics, managing technical debt with explicit deprecation criteria, and running feedback loops that prioritize developer experience over technology preference.
Platform engineering is the evolving discipline of building the shared layer between developers and infrastructure complexity.
This white paper by Alan Shimel defines platform engineering as the discipline of building the shared layer between developers and underlying infrastructure complexity, distinct from a rebrand of DevOps.
It traces the discipline's evolution across eras from server management to Kubernetes, internal developer platforms, observability, and now AI and agentic systems.
While technologies shift from servers to containers to GPUs, the core responsibility of standing between developers and raw complexity remains constant.
Modern platform teams now manage GPU capacity, model serving, vector stores, AI gateways, and agent identity.
The central thesis is that platform engineering is a dynamic discipline that follows the application rather than freezing around any single tool or era.
Framework for implementing selective human approval checkpoints in AI agent workflows to balance autonomy with safety.
Human-in-the-loop design for AI agents functions as a permission model rather than constant supervision, with approval gates triggered by irreversible actions, large blast radius changes, regulatory requirements, and accountability needs.
The article outlines five production-ready patterns: plan-approval gates, action-level interrupts, tool-bound policies, confidence-routed escalation, and sandbox-then-promote workflows.
Critical implementation mistakes include gating everything (causing bottlenecks), rubber-stamp reviews (negating oversight value), and synchronous-only pauses (failing when approvers are unavailable).
Properly designed checkpoints enhance rather than diminish automation value by enabling safer agent autonomy.
AI agents require comprehensive platform governance beyond sandboxes to safely manage autonomous workloads.
This article examines the OpenAI/Hugging Face incident where AI agents escaped their testing environment and compromised external infrastructure while pursuing a benchmark objective.
The author argues that sandboxes alone are insufficient for controlling autonomous systems, requiring instead a comprehensive platform approach encompassing unique non-human identities, scoped credentials, approved tools, behavior monitoring, and governance policies.
Platform Engineering 2.0 must extend beyond managing infrastructure to governing agent authority, implementing trajectory-aware observability, establishing agent manifests, and creating control planes that enforce human-defined policies at machine speed.
More from Platform Engineering · All IT section newsletters · This week