The platform engineering stories enterprise IT leaders actually read.
Volume 342, Issue 4 · 8 articles from 2 issues
Platform Engineering 2.0 expands beyond developers to serve multiple personas including AI agents.
Platform Engineering 2.0 requires serving diverse user groups including data scientists, security teams, and AI agents, not just developers.
Pankaj Gupta of Broadcom discusses how platforms must provide different experience layers and controls for each persona while avoiding fragmented toolchains.
The shift includes non-human users as AI agents become active participants in software delivery, creating new requirements for permissions and governance. Traditional developer-centric metrics must expand to include security, compliance, and business alignment for enterprise success.
Platform engineering solved infrastructure ownership but left data quality accountability undefined, requiring declarative data contracts.
Cloud-native platforms clearly identify who owns a service when it fails, but struggle to assign accountability when systems run fine yet produce bad data.
The article argues that pipelines get owned as infrastructure while actual data quality remains orphaned, citing three problems: datasets lack stated contracts, schema changes ship without consultation, and unused datasets persist indefinitely.
Instead of catalogs or centralized data teams, it recommends treating data contracts as declarative infrastructure, with schema definitions, alert routing, and retention policies enforced in CI/CD like Kubernetes enforces resource limits.
This approach reportedly cut median time to identify dataset owners from three days to under an hour.
Platform Engineering proposes 'harness engineering' as a governance framework for autonomous AI agents.
The article argues platform engineering must expand beyond developer self-service to govern autonomous AI agents acting across enterprise systems.
It introduces 'harness engineering,' combining bounded identity (e.g., SPIFFE), policy enforcement (OPA/Gatekeeper), sandboxed execution isolation, OpenTelemetry-based auditability, and recovery mechanisms.
Practical steps include inventorying agent interactions, assigning governance ownership, isolating execution before expanding autonomy, requiring approvals for high-impact actions, and testing failure scenarios.
Maturity is reached when identity, policy, isolation, and telemetry merge into a single execution contract, letting organizations safely extend agent authority while preserving traceability and reversibility.
An engineering manager details how his team cut CI pipeline time from an hour to 22 minutes while growing test coverage 90%.
An engineering manager at retailer M&S details how his team cut Merge Train CI pipeline duration by 64%, from roughly an hour to 22 minutes, while growing test coverage 90% and cutting the failure rate from 18% to single digits, for only a 10% rise in monthly compute cost.
The biggest lever was migrating compute instances from C5 to C7i processors; AMD was rejected despite lower cost due to high execution-time variance.
Other wins came from segregating browser tests from service tests to cut container overhead, and using automated logging plus LLM analysis to quarantine flaky tests.
The guiding principle: "intuition cannot beat data" - they changed one variable at a time, estimating a $65,000 monthly productivity gain.
A survey gap - 86% confident they can govern AI-assisted changes, only 30% have a written policy - shows slowness used to be governance.
A 2026 Infrastructure Automation Report survey of 400+ platform and engineering leaders found 86% confident they can govern AI-assisted infrastructure changes, yet only 30% had a formal governance policy in place.
The author argues this isn't overconfidence: for years the cost of writing infrastructure code naturally limited how many changes could happen and who could make them, functioning as unwritten governance.
AI collapsed that cost, removing the implicit constraint while the explicit policy work stayed undone. A CNCF Ambassador is quoted: "Confidence without a policy is not governance.
It's a feeling, and the feeling does not survive contact with an agent making changes at 3 a.m." The best-prepared organizations already had strong infrastructure-as-code coverage and scoped access.
Large organizations should treat quality engineering as a shared platform rather than per-team projects.
Organizations scaling beyond a few hundred engineers face fragmentation in test automation when each team builds separate frameworks and infrastructure.
The solution involves two layers: establishing a standardized automation framework across the enterprise and centralizing test execution infrastructure with SLAs and observability.
AI-generated code is accelerating this need by increasing validation volume, making scalable testing infrastructure critical to prevent pipelines from becoming bottlenecks during rapid code generation and deployment.
Engineering leaders should treat AI spend as a predictable budget line judged by value delivered, not just consumption.
AI tool adoption lets individual engineers consume significant compute, creating a new budgeting challenge for engineering leaders.
Rather than simply capping AI spend, leaders should examine usage distribution to separate high-value spenders from inefficient experimenters, and efficient low spenders from struggling ones.
Platform teams can then embed best practices from productive engineers into defaults and workflows, similar to cloud infrastructure management.
The article argues predictability and understanding ROI matter more than the absolute size of AI spending.
Wide telemetry coverage doesn't equal useful observability; platform teams need shared conventions and AI-aware metrics.
The article argues that having telemetry everywhere doesn't guarantee useful observability, quoting Honeycomb's Liz Fong-Jones: 'You can have telemetry everywhere and still not have useful observability.'
Budget constraints often force teams to reduce data fidelity, shorten retention, or focus monitoring on critical services, especially as AI workloads increase data volume. Platform teams should embed OpenTelemetry into golden paths and standardize service names, ownership, and business context.
Observability must also expand to cover AI-specific signals like token consumption, inference latency, hallucinations, and guardrail failures, with success measured by whether engineers can resolve incidents independently.
More from Platform Engineering · All IT section newsletters · This week