In an InfoQ roundtable titled “Platform Engineering in the Age of AI,” four practitioners argued that AI is not replacing platform engineering so much as changing its scope, speed and pressure points. The panel agreed that platform teams are being asked to support AI-assisted development, agent-driven workflows and faster release cycles while still preserving the standards, guardrails and governance that make internal platforms useful in the first place.
Platform engineering in the age of AI
The discussion brought together Davide de Paolis, Stéphane Di Cesare, Stephen Cihak and Camila Macedo, with InfoQ’s Renato Losio moderating. Across the conversation, one theme came up repeatedly: AI is adding a new layer of automation, but the core purpose of platform engineering remains the same. Platform teams still exist to reduce friction, standardize common work and help developers ship safely.
What is changing is the scale. Where platform teams once optimized primarily for human-paced development, they now have to think about code-generation tools, autonomous agents and the operational load created when AI speeds up the creation of pull requests, deployments and support requests.
What AI is already changing for platform teams
Davide de Paolis said AI is already helping platform teams in three practical areas. First, it makes it easier to tackle “important but never urgent” work such as documentation, boilerplate, code snippets, reusable modules, recurring Infrastructure as Code changes and diagrams. Tasks that often slip down the backlog can now be completed more cheaply and quickly.
Second, AI is useful operationally. De Paolis described a platform environment spanning around 100 AWS accounts and hundreds of Terraform repositories, where AI helps with discovery, comparing differences, identifying baselines and aggregating data to decide what to improve next.
Third, AI can reduce support load by giving teams access to internal MCP servers or skills that can answer common questions or generate code in line with company-specific practices. That shifts some first-line support away from platform engineers and toward systems that are trained on internal context.
Stéphane Di Cesare added that AI should be seen as a new automation tool rather than a replacement for platform engineering principles. He said the important questions remain the same: what services does the platform provide, what problem is it trying to solve, and how clearly are those services defined? In his view, AI makes clarity more important, not less.
The new bottleneck is not always coding
Stephen Cihak argued that faster code generation moves the bottleneck elsewhere. If teams can create code more quickly, the constraints shift to deployment pipelines, security scanning, governance and release controls. That means platform teams face more pressure to make self-service paths faster and less manual.
He said AI tools make it easier for executives to ask why code generated so quickly is not reaching production just as fast. In his view, platform engineering must adapt to “machine speed” rather than assuming the human pace of the old release cycle will remain the standard.
Camila Macedo stressed that AI is also changing how engineers work with unstructured data. In her view, AI can help make sense of logs, assist debugging and surface issues faster. But she said it should be treated as a layer that helps humans, not a replacement for deterministic systems or human oversight.
Where internal developer platforms fit
The panel also explored what an internal developer platform should provide in an AI-enabled environment. Cihak described internal developer platforms as workflow engines that can speed up onboarding, provisioning and service setup. He said they can standardize the essentials from the start, cutting work that used to take months down to minutes.
He also said such platforms could evolve into a stronger CMDB-like system, with richer scoring and more context for developers. In the nearer term, platforms can use backend agents to help keep services updated, for example by identifying vulnerabilities and prompting teams to deploy fixes.
De Paolis said the hard part is still deciding what to centralize and what to leave to teams. That has always been a platform engineering question, he said, and AI does not remove it. Instead, it adds a new kind of shared context to manage: code conventions, PR-generation skills, integrations with Jira or other ticketing systems, and rules about how agents should use that information safely.
He also pointed out that platform teams may need to manage licensing, overages and the approved AI tools themselves, including what MCP servers agents are allowed to use. In other words, platform ownership may extend deeper into AI governance and cost control.
Guardrails matter more as systems become less deterministic
Security and compliance were recurring concerns throughout the panel. Macedo said the fundamentals have not changed: least privilege, strong permissions, clear policy and solid auditing remain essential whether the actor is a person or an agent.
Di Cesare, speaking from a banking context, said platform teams in regulated environments must still centralize compliance and security information so it is easy for both humans and agents to use. He argued that platform work is increasingly about helping AI systems understand the organization’s principles and architecture, not just about restricting behavior.
Cihak emphasized that non-deterministic tools need guardrails to make their behavior more predictable. He said teams cannot control model outputs directly, but they can control the environment those models operate in by adding validations, governance checks and post-production evaluations. He also warned that model providers can change underlying models without much notice, which makes ongoing monitoring essential.
Agents do not remove human responsibility
One of the panel’s most consistent points was that agents do not eliminate the human decision-maker. Di Cesare said agents are not truly autonomous because a human intent still sits behind them. That intent determines what outcome is wanted, even if the path to get there becomes more automated.
Cihak took the idea further, saying the industry may need an autonomous SDLC in which agents can fix bugs, submit pull requests and move work through deployment, but only inside a tightly governed system that produces evidence for audits and compliance. He said the old weekly CAB-style model will not be fast enough for an AI-accelerated world.
De Paolis added that the rise of agents is also exposing how much organizations have neglected documentation and process. He called it ironic that companies are now improving knowledge bases and specs partly because agents need better context, when humans have needed the same thing all along.
How success is measured in an AI-driven platform
The panel ended by returning to a familiar problem: how to prove that platform engineering is working. Di Cesare said the best signal is still developer trust and satisfaction, even if those are harder to quantify than infrastructure metrics. He stressed psychological safety, noting that developers must feel comfortable telling the platform team what is actually wrong.
De Paolis said onboarding time is one of the clearest measures. If a team can go from idea to production in hours instead of weeks, that is a strong sign the platform is reducing cognitive load. He also suggested watching support traffic, PR back-and-forth and even proxy metrics such as DORA measures before and after platform improvements.
Cihak summed up the panel’s practical advice simply: make it easy to do the right thing. If the platform consistently does that, cognitive load should fall naturally, regardless of whether the workload comes from people, copilots or agents.
Source: Original report
Was this helpful?
Explore more: DevOps Services More Cloud & DevOps Tech News
Last Modified: September 8, 2026 at 10:32 pm
11 views
