Presentation: Platform Engineering in the Age of AI

Stéphane Di Cesare, Davide de Paolis, Stephen Cihak, Camila Macedo, Renato Losio · rss · 2026-09-08 source ↗ Reader 🖥️

practical · mixed — A moderated multi-panelist roundtable (expository Q&A in structure) that is ultimately practical/argumentative in content: the panelists converge on claims about what platform teams should do differently — and what they should not change — as AI reshapes software delivery.

Structure

Key terms

• Guardrails vs. "the middle of the road"
  Stephane distinguishes hard boundary constraints (guardrails, which only stop you from going too far wrong) from positively stated architecture and principles ("the middle of the road") that tell agents and developers what good looks like, not just what's forbidden.
• IDP (Internal Developer Platform)
  Stephane insists the IDP is broader than a developer portal (e.g., Backstage); the portal is one surface of the platform, which also includes centralized information (documentation, compliance/security knowledge) and backend capabilities agents can call directly.
• Autonomous SDLC Autonomous SDLC
  Cihak's term for a software delivery lifecycle redesigned so agents plan, code, test, and deploy end-to-end, with systematic permissions and governance embedded in the pipeline that automatically produces auditable evidence — replacing periodic manual approval gates like a weekly Change Advisory Board.
• Machine speed (vs. human speed)
  Cihak's shorthand for the qualitative tempo shift platforms must support once AI compresses code-authoring time: not just "faster," but a different operating regime that manual, human-paced review and approval structures cannot sustain.
• Reusable context
  Davide's term for platform-managed, shared AI-agent inputs — coding conventions, PR-writing skills, ticketing-system integrations — that the platform team stores, distributes, and secures on behalf of developer teams, analogous to how it already manages reusable infrastructure modules.

Propositions

• explicitAI benefits platform teams in three areas: tactical (previously neglected work like documentation, boilerplate, and recurring Infrastructure-as-Code changes becomes cheap to do), operational (AI-driven discovery and aggregation across a complex, large-scale infrastructure landscape), and strategic (AI, via internal MCP servers/agents, can answer first-line developer questions, reducing the support burden on the platform team).conf: high
• explicitcorroboratedAI does not change what platform engineering fundamentally is — its principles, and the need for clear service intent and APIs, still apply — what changes is scale, because platform teams now serve workloads coming from agents as well as humans.conf: high
  supports ←2024_final_dora_report · p6 — Both sources treat platform-engineering fundamentals (here, developer independence; there, service intent/APIs) as unchanged in kind by AI — AI shifts magnitude of effects, not the underlying discipline.
• explicitcorroboratedAs AI shortens the time needed to generate code, the bottleneck in software delivery shifts to the 'outer loop' — the deployment loop, security scans, and governance gates — putting pressure on platform teams to speed up self-service deployment.conf: high
  supports ←Presentation: APIs for Agents: Rethinking API Programs in the MCP Era · p6 — The roundtable predicts the outer loop (deployment, security scans, governance gates) becomes the new bottleneck as AI speeds up code generation; this talk's deployment-gates section is a concrete implementation absorbing exactly that pressure.
• explicitFaster AI-assisted code generation increases the volume of security issues that need to be found and triaged, leaving open-source maintainers feeling perpetually behind.conf: medium
• explicitInternal developer platforms are evolving from onboarding/provisioning workflow engines toward a strong CMDB, and backend agents built on top of an IDP can autonomously handle recurring maintenance (e.g., patching known vulnerabilities across services) and surface it to developers as a single approve-and-deploy action.conf: high
• explicitDeciding what to centralize on a platform versus leave to team autonomy is platform engineering's perennial, still-unanswered question, and this is true independent of AI.conf: high
  extendsHow Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery · p2 — The panel's 'never answered question' (centralize vs. autonomy) is the same tension golden-bricks addresses via composable bricks vs. prescribed paths; this roundtable broadens the question into AI-specific territory (context, tooling, licensing) without taking a side.
• explicitIn the AI era, managing and safely distributing reusable context (coding conventions, PR-writing skills, ticketing-system integrations) is a new platform-team responsibility, alongside FinOps management of AI tool licensing/token overages and governance over which MCP servers agents may use.conf: high
  extendsHow Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery · p3 — Extends 'reducing developer cognitive load is the primary purpose of a platform' to cover a specific new mechanism — platform-distributed AI context/skills — not addressed in the golden-bricks piece.
• explicitAI agents should be governed with the same security principles already applied to people — least privilege, clear permissions, strong policy, and strong auditing — rather than a wholly separate framework.conf: high
• explicitFor a bank, the bottleneck AI needs to address is not coding speed but compliance and security review, so part of the platform's job is to centralize compliance/security information so it can be used correctly by agents.conf: high
• explicitAI has leveled the historical expertise gap between platform engineers and developers (e.g., platform engineers used to simply know Terraform better) — both groups now start from a similar footing with AI tools, making a collaborative contribution model more necessary than a platform-team-knows-best model.conf: high
  extendsPresentation: Platform Engineering for Everyone - Success Can’t Be Coded · p3 — Supplies a causal mechanism (AI-driven expertise leveling between platform engineers and developers) for why voluntary, collaborative platform adoption becomes more necessary, not just nicer, in the AI era.
• explicitAI is not yet trustworthy enough to make autonomous decisions in a regulated, high-stakes domain like banking; current benchmark accuracy for AI code generation (cited as Anthropic Opus 5, 25%-65%) is too unreliable to hand over decision authority.conf: medium
• explicitAn Internal Developer Platform is broader than a developer portal; Backstage-style tools are the portal, one surface of a platform that also includes centralizing organizational information such as documentation.conf: high
• explicitThe panel foresees an 'autonomous SDLC' in which agents plan, code, test, and deploy changes with systematic permissions and governance embedded in the pipeline, because periodic manual approval processes (e.g., a Change Advisory Board meeting once a week) cannot keep pace with AI-driven change volume.conf: high
• explicitBusiness or 'citizen' developers using AI to build their own systems need high levels of platform automation (e.g., automatically figuring out infrastructure sizing for them) or they will be slowed down and the organization will not realize the benefit of AI investment.conf: high
  supportsAssumptions as code: SiriusXM's approach to platform prioritization · p8 — Independent practitioner corroboration of the claim that platforms must expand their user definition beyond software developers as AI enables non-developers to build.
• explicitAgents are not fully autonomous decision-makers: a human is always accountable for deciding intent, even as execution becomes faster and more automated; AI changes the scale of work, not who ultimately decides what the platform or product should do.conf: high
  supportsYour AI strategy has a trust problem, not a tooling problem · p6 — Independent corroboration, from a platform-engineering context, that AI agents distribute execution but cannot substitute for human agency in setting intent/goals.
• explicitAs individual developers use agent orchestration to run spec-driven work across many tickets in parallel, the resulting surge in pull requests strains shared platform infrastructure (e.g., CI runners), shifting scale pressure from human pace to agent pace.conf: high
• explicitOnly now that agents need explicit, well-structured documentation and context to avoid hallucinating or missing context has the organization found the will to build the knowledge base/documentation that engineers already knew they needed for years.conf: high
  supportsAssumptions as code: SiriusXM's approach to platform prioritization · p10 — Independent corroboration, from a different organization, of AI forcing the rigorous externalization of organizational knowledge that was previously under-prioritized.
  extendsThe boring skill that decides how much AI can help you · p1 — Applies the personal-file 'AI amplifies existing structure' thesis to organizational scale: undocumented orgs now suffer visibly because agents (unlike people) fail hard on missing context.
• explicitBuilding software that merely works is not the hard part; building software that stays maintainable and understandable over years is the hard part, and AI does not change this — documentation should live in the code and API itself, readable by both humans and AI, without sacrificing the deterministic character of the software.conf: high
• explicitAs AI lowers the bar to producing working code, the specialist operational/accountability judgment that platform engineers bring — recognizing what appears to work but is not actually maintainable — becomes more valuable, not less.conf: high
• explicitDoing something that solves a problem sustainably, over years, is different from doing something that merely works today; practitioners need a broad understanding of both infrastructure and development to bring real value in cloud/Kubernetes work.conf: medium
• explicitWithout codified rules or continued platform-team oversight, letting individual developers build their own infrastructure breaks down quickly; an inner-source model, in which interested developers contribute to platform-owned infrastructure rather than build parallel infrastructure, preserves both standardization and innovation.conf: high
• explicitProviding developer agents with the platform team's own internal MCP servers and skills, instead of letting agents pull generic snippets from public sources, increases developer confidence and lets the platform team trust that infrastructure is built the way it wants — but this requires added guardrails, such as AWS Service Control Policies preventing agents from destroying or tampering with resources at certain stages.conf: high
• explicitCurrent AI agents are useful for triaging problems — filtering logs, identifying issues, opening tickets, and acting as a base-of-knowledge support layer — but are not yet reliable at resolving issues correctly in a single pass; they typically require several interaction rounds to reach a good result.conf: high
• explicitAI's non-deterministic nature — the same prompt can produce many different implementations — increases the pressure for stronger platform standards and guardrails, because governance can make non-deterministic tooling more predictable even though the model's raw output cannot itself be controlled; ongoing post-production evaluation is needed to catch silent model drift.conf: high
• explicitGuardrails alone are insufficient; platform teams must also make clear what 'the middle of the road' is — the architecture and principles a team should aim for — not only the boundary constraints that stop them from going too far wrong.conf: high
  extendsGoverning AI in the Cloud: A Practical Guide for Architects · p10 — Adds a positive-direction-setting principle ('the middle of the road') to complement the 'secure = fastest = default' constraint-only design principle.
• explicitAI will take over platform engineering's toil (repetitive configuration checking, log-checking) but not platform engineering jobs, because governing agent behavior and maintaining the organizational context layer are new, higher-order responsibilities replacing the automated-away toil; this parallels an identity crisis developers face if they define themselves by writing code rather than solving problems.conf: high
• explicitJust as compilers abstracted away complexity without eliminating engineering jobs, AI is an evolutionary layer of abstraction that will not eliminate the need for people who understand, maintain, and are accountable for systems, even as AI becomes very good at generating code.conf: high
• explicitOver the next several years platform engineering will become more, not less, critical, because building and governing the full, well-structured system that lets an organization move at machine speed while still producing regulatory evidence is itself the necessary, hard work — captured in the metaphor of a governed highway/freeway system versus an ungoverned 'Outback.'conf: high
• explicitThere is no objective metric that proves platform engineering reduces cognitive load; the real, harder challenge is building enough developer trust — via psychological safety — that developers give honest feedback, since platform teams are often historically perceived as 'the team who says no.'conf: high
  supportsPresentation: Platform Engineering for Everyone - Success Can’t Be Coded · p12 — Independent corroboration that qualitative, trust-gated developer feedback outranks quantitative proxies as the real measurement layer for platform success.
  extendsHow Open Source Enables Collaboration in Creating a Platform · p3 — Adds that trust is a prerequisite not only for platform adoption but for collecting honest measurement data in the first place — the platform team must earn trust before developers will even report problems accurately.
• explicitNo career-long, reliably assertive metric for developer/team productivity exists; practical heuristics include bug/incident counts, onboarding time, and how long it takes someone new to detect AI hallucination.conf: medium
• explicitPractical proxy signals for platform success include time-to-production for onboarding a new service, the volume of back-and-forth communication in PRs and chat (a proxy for missing documentation/knowledge), and before/after comparisons of DORA metrics relative to when the platform team was introduced.conf: high
• explicitThe unifying principle for reducing cognitive load is to 'make it easy to do the right thing'; if a platform continually does this, cognitive-load reduction follows as a natural outcome, even without one clean metric to prove it.conf: high
• implicitA platform team's authority to set standards is not self-justifying; it must be continually re-earned through demonstrated expertise, trust, and voluntary adoption rather than assumed from an organizational position — and AI narrows the platform team's prior expertise advantage, exposing this dependency on earned trust rather than creating it.conf: medium
• implicitThe panel assumes that regulatory and audit obligations are a fixed constraint that will not loosen as AI-driven delivery velocity rises; every proposed answer (autonomous SDLC, embedded evidence production, graduated governance) works around this constraint rather than questioning whether the obligations themselves should change.conf: medium
• implicitCamila's banking anecdote assumes that AI benchmark accuracy on code-generation tasks (the cited 25%-65% figure) generalizes to trustworthiness for autonomous financial decision-making — a materially different task domain from the one the cited statistic actually measures.conf: medium

Arguments

Narratives

• Stephane recounts working with frontend code for the first time since Visual Basic, assisted by AI, and — despite calling himself an incompetent frontend developer — recognizing that the AI was doing 'some very crazy things,' like embedding HTML directly in frontend components, that would hurt maintainability.
  → Supports the proposition that AI lowers the bar to producing working code but not to being accountable for what you maintain — specialist operational judgment remains the differentiator even when someone is a novice in the specific technology.
• Camila jokes that she's happy her bank isn't letting AI make decisions, because non-deterministic behavior means she could check her account balance one day and be rich, the next day poor.
  → Dramatizes and supports her proposition that AI's current reliability is insufficient for autonomous decision-making in regulated, high-stakes domains.
• Stephen describes an eventual state where a developer opens the IDP portal and sees a message like 'I fixed 47 vulnerabilities across these services, please go deploy them,' generated by a backend agent working on top of the IDP.
  → Supports the proposition that IDPs are evolving toward a CMDB-like backend with agents doing recurring maintenance work, surfaced to developers as a simple approve-and-deploy action.
• Davide describes his own platform team's experience: a developer using agent orchestration to run spec-driven development across multiple tickets at once creates a bottleneck of pull requests that the team's shared GitHub-runner infrastructure must now sustain — connecting to the earlier discussion of GitHub outages being 'just part of life' now.
  → Supports the proposition that agent-driven demand spikes strain shared platform infrastructure in ways human-paced work never did, illustrating the 'scale, not principles' framing of AI's effect on platform engineering.
• Stephen closes the future-of-platform-engineering discussion with an extended metaphor: two-lane highways force you into the ditch if you go too fast, while freeways require heavier structural investment to let traffic move faster safely — and without that structure you're 'driving through the Outback,' liable to hit bumps and lose direction entirely.
  → Supports the conclusion that platform engineering becomes more critical, not less, as AI increases delivery speed — the structural investment (the platform) is what makes higher speed survivable rather than reckless.

Questions addressed

• ✅ How is AI already changing the way platform teams work today?
  Resolved via the tactical/operational/strategic framing (Davide) plus the bottleneck-shift argument (Cihak): AI clears neglected work, aids discovery across complex estates, absorbs first-line support, and shifts pressure onto deployment/governance rather than code creation.
• ⭕ What capabilities should — and should not — an internal developer platform provide in the AI era?
  Explicitly named as platform engineering's unanswered question, not resolved by the panel; they offer heuristics (friction-point analysis, reusable-context management, guardrails, FinOps/licensing oversight) rather than a definitive boundary.
• ✅ Does a developer platform's fundamental purpose change once agents, not just humans, become direct consumers of it?
  Resolved as no: humans remain the ultimate deciders of platform/product intent even as agents perform more of the execution; what changes is scale and pace, not who the platform ultimately serves.
• ⭕ What metrics prove that platform engineering is actually reducing developer cognitive load?
  Explicitly unresolved — Stephane states he does not have the answer; the panel converges on qualitative trust-building (psychological safety, continuous feedback) and imperfect proxies (onboarding time, DORA-metric deltas, PR/chat communication volume) rather than a clean metric.
• ✅ Will AI increase or decrease the strategic importance of centralized platforms?
  Resolved by panel consensus: platforms become more central, not less, because governance and evidence-production needs grow even as routine toil is automated away.
• ⭕ Can smaller or less-resourced organizations actually build the 'autonomous SDLC' and internal-MCP/reusable-context infrastructure the panel describes?

Gaps

• incompleteCamila's claim that Anthropic's Opus 5 has a code-related benchmark accuracy of '25% to 65%' is stated without citation, methodology, or task definition, and is used to support a general claim about AI's untrustworthiness for autonomous decision-making in a different domain (banking). This mirrors a pattern already flagged elsewhere in the corpus — extract-korbacher-platform-engineering-product-mindset's unsourced, likely-garbled cognitive-load statistic.
  Read next: The primary Anthropic model card or SWE-bench-style benchmark report for the model in question, cross-checked against the corpus's more rigorously sourced AI-reliability data such as extract-dora-ai-team-profiles-and-capabilities.
• incompleteThe panel repeatedly asserts that platform teams must 'manage licensing,' 'govern MCP servers,' and 'provide guardrails/sandboxes' for AI tools, but no panelist describes a concrete mechanism — who decides, on what criteria, with what consequence for violation. The same gap is more directly addressed elsewhere in the corpus.
  Read next: extract-entur-ki-loypa-slik-vurderer-og-innforer-vi-ki-verktoy (a staged AI-tool governance process) and extract-fighting-tool-sprawl-ai-registries (concrete registry mechanics: discovery, versioning, certification, access control) — both specify process detail this roundtable leaves abstract.
• incompleteThe panel's central, explicitly named 'never answered question' — what to centralize versus leave to team autonomy — is acknowledged but never engaged with any decision framework; the panel does not decompose it along governance, composability, or team-readiness axes.
  Read next: extract-platform-engineering-golden-bricks, which proposes decomposing exactly this choice along governance/composability/team-autonomy axes (and whose own extraction flags the same decomposition as under-theorized).
• uninformedNone of the four panelists represent a resource-constrained or small-team perspective — every concrete example (100 AWS accounts, hundreds of Terraform repos, dedicated Field CTO tooling, a national bank's platform-experience team) assumes platform-team scale and budget most organizations lack, yet the prescriptions (autonomous SDLC, internal MCP servers, reusable-context management) are stated as though generally applicable.
  Read next: Team Topologies' 'Thinnest Viable Platform' concept, or other small-team platform-engineering literature, to test whether the same AI-era prescriptions hold at smaller scale.
• illogicalStephen argues both that platform teams must 'not tamp down innovation' and preserve developer freedom to build new infrastructure via an inner-source model, and that centralized, codified rules are 'supremely important' to prevent 'random infrastructure' chaos. The roundtable asserts both are needed but never explains how the inner-source boundary is actually drawn — who decides when a developer's local infrastructure becomes platform-owned versus stays local — leaving the same centralize-vs-autonomy tension unresolved in a different guise.
  Read next: Reader's own experience with inner-source contribution models, or corpus pieces on team-topology contribution boundaries, for a concrete adjudication mechanism.

Closes gaps elsewhere

• Entur AS' innlegg — KI-løypa: Slik vurderer og innfører vi KI-verktøy i Entur · g3 — Cihak's 'autonomous SDLC' argument (p13) directly answers the unaddressed speed-vs-governance tension: embed governance as automated, evidence-producing guardrails within the deployment pipeline itself, rather than enforcing it through periodic manual gates like a weekly Change Advisory Board, so speed and governance stop being traded off against each other.

Related documents

• Your AI strategy has a trust problem, not a tooling problem
• The boring skill that decides how much AI can help you
• Presentation: Platform Engineering for Everyone - Success Can’t Be Coded
• Achieving Compliance as a Platform Engineering Team by Helping Developers
  Golden Path Guardrails Organizational Legibility Platform Engineering
• Governing AI in the Cloud: A Practical Guide for Architects
  Agent Governance (Internal) Golden Path Guardrails Platform Engineering
• Why AI agents need a Context Lake
  Agent Governance (Internal) Organizational Legibility Platform Engineering
• Git real: AI agents aren’t just for solo developers anymore
  Agent Governance (Internal) Golden Path Platform Engineering
• Article: Securing MCP in Production: Defense-in-Depth Beyond the Gateway
  Agent Governance (Internal) Guardrails Platform Engineering
• Everyone wants to be AI-pilled. Most Companies Are Still Level 1
  Agent Governance (Internal) Organizational Legibility Team Autonomy
• How Open Source Enables Collaboration in Creating a Platform
  Golden Path Platform Engineering Team Autonomy