The platform engineering stories enterprise IT leaders actually read.
Volume 342, Issue 2 · 8 articles from 2 issues
Optimizing only the GPU misses the point: AI pipelines are CPU, memory, storage and network problems too.
AI platform engineering is presented as a heterogeneous infrastructure problem rather than a GPU procurement exercise.
Production inference pipelines chain interdependent stages -- data preparation, inference, post-processing -- each with distinct CPU, GPU, memory, storage and networking profiles
The author's rule of thumb is to follow the workload, not the GPU, and optimize the complete pipeline as one system. Kubernetes features such as Dynamic Resource Allocation help match specialized hardware to specific stages, while observability at every handoff point is what actually surfaces bottlenecks and wasted capacity.
Platform Engineering Needs Better Measures of Productivity
Platform teams focusing solely on deployment frequency risk creating instability while developers spend increasing time on repairs and workarounds.
Effective measurement requires tracking the complete change lifecycle including success rates, recovery time, and detection speed, not just deployment volume. Developer friction indicators such as support demand, workflow abandonment, and manual interventions reveal problems hidden by adoption metrics.
Leaders must pair speed measures with counterweights like reliability and rework to avoid incentivizing behaviors that shift problems downstream rather than eliminating them.
Platform Engineering and the Challenge of Tribal Knowledge
When production knowledge concentrates among senior engineers, their unavailability can transform manageable incidents into extended outages.
Rather than relying solely on documentation, organizations should capture expertise through incident reviews and convert repeatable knowledge into automation, policy as code, and service catalogs.
Platform leaders must measure success by tracking escalation patterns, incident recurrence, and resolution times rather than documentation volume. Machine-derivable information should come from systems, while documentation focuses on reasoning and context.
Most platform teams mistake standardized tooling for real self-service, and stall at interface maturity Level 2.
The piece reframes platform engineering maturity as an interface design problem rather than a tooling problem, laying out four levels from custom processes up to fully integrated services.
Most organizations plateau at Level 2, where the platform team stays a bottleneck for anything outside the golden path.
The core gap is between capabilities that exist and capabilities that are genuinely self-serviceable.
To advance, the author recommends parameterizing golden paths, treating interfaces as products, automating common scenarios, and distributing capability ownership to specialized teams while holding platform contracts steady.
Fairwinds CTO argues AI workloads turn mature Kubernetes into an unfamiliar operations discipline all over again.
Kubernetes itself has matured, but running AI workloads on it introduces GPU scheduling, bursty demand, and hard data-boundary requirements that make it feel like an entirely new operations discipline.
Andy Suderman of Fairwinds argues most AI teams eventually need Kubernetes in production yet arrive without clarity on who owns the platform or how it is governed.
The consequences of skipping that groundwork are expensive idle GPUs and avoidable service disruption. His advice is to settle foundational infrastructure and ownership models before production AI workloads land, not after.
Alan Shimel argues model access, agent identity, governance and cost controls belong in the internal developer platform.
Alan Shimel contends that AI is the next major platform engineering workload and that governed access to models, inference endpoints, agents, quotas and audit trails should come through the internal developer platform.
Futurum research shows only 18.1% of organizations have mature agent governance while over 84.5% say AI touches more than a quarter of their SDLC work.
Perforce data links platform maturity with AI success, though the author notes these are correlations. He calls for model catalogs, scoped agent identities, token quotas and AI gateways built into the paved road rather than policy documents.
An InfoQ roundtable discusses how platform teams are adapting to support AI-assisted engineering, tooling and guardrails.
InfoQ editor Renato Losio hosts a panel with Stephane Di Cesare (DKB), Davide de Paolis (formerly sevDesk), Stephen Cihak (Harness) and consultant Camila Macedo on platform engineering in the AI era.
Panelists describe AI helping platform teams clear neglected work like documentation and IaC changes, analyze sprawling multi-account environments, and provide first-line support via internal MCP servers and agents.
They discuss which AI capabilities belong in the platform, trade-offs between standardization and developer autonomy, and managing AI tooling, security guardrails and shifting workflows.
Broadcom's Pankaj Gupta tells Alan Shimel that AI workloads, AI agents and autonomy define Platform Engineering 2.0.
In episode two of The Platform Engineering Show, Alan Shimel talks with Broadcom's Pankaj Gupta about AI native platforms as the foundation of Platform Engineering 2.0.
The first pillar is native support for AI workloads, including GPU provisioning, model serving, model registries, MCP servers, ML pipelines and guardrails.
The second treats AI agents as platform citizens needing access controls, approvals and human-in-the-loop oversight.
The long-term third pillar is autonomous, self-healing and self-optimizing platforms, though the near-term priority is making AI workloads and agents safe and governed.
More from Platform Engineering · All IT section newsletters · This week