Transcript #
Renato Losio: In this session today, we're going to chat about platform engineering in the age of AI. In this roundtable we discuss how internal platforms are evolving, how AI is changing the next generation of platform engineering. My name is Renato Losio. I'm an editor at InfoQ. Today I'm joined by four experts coming from different areas, different backgrounds, different countries, that are going to give you their experience about platform engineering and how it's actually evolving. I'd like to allow each one of them to introduce themselves and share their journey in platform engineering.
Davide de Paolis: I'm Davide de Paolis. I am an engineering manager at Shine now, formerly at sevDesk. I'm leading the platform engineering team, the infrastructure team on AWS, leading 10 people and serving 25 teams across all Europe. I started my career more than 20 years ago with the infamous Flash websites, and then evolved into other tech stack, languages. I landed on AWS more than 10 years ago, started with Lambda, serverless is still my favorite. Then basically grew into the role of technical lead and engineering manager, mostly for platform engineering team. I'm also an AWS Community Builder in my fifth year, and blogger, and public speaker. I normally travel a lot around Europe, bringing my favorite topics.
Stephane Di Cesare: My name is Stephane Di Cesare. I work for DKB, who are a large online bank in Germany, serving about 5 million customers. I work for the infrastructure platform, working especially with platform experience, so we're ensuring our users are happy with the platform. Before that, I worked with DevOps consulting at Accenture, and I also did some infrastructure automation for VMware.
Camila Macedo: My name is Camila Macedo. I started to develop software when I was a kid, I was 12 years old. I started to work at 16 years. I have been doing that for more than 20 years. My career, in the first 10 years, more or less, was a lot of Java, JBoss, WebLogic, Oracle, Spring, Hibernate. In the last eight years, more or less, I have been working with Kubernetes and cloud solutions. My main focus is how to do toolings, automations, extend the Kubernetes itself, and to find ways to support the community, the developers, especially around the operator partner. That basically means to help the developers, how can they build Kubernetes native solutions for the delivery of their products for these environments.
Stephen Cihak: I'm Stephen Cihak. I started my career back in the '90s, actually, so it's been quite a while. I played about every role, engineering role, you can play in there. Last 15 years, I've been leading engineering and platform teams, both in highly regulated and retail and hospitality industries. Most recently at Choice Hotels. I was the Senior Director of Cloud Platform there, where I ran all of the DevOps, CI/CD, developer experience, cloud infrastructure for that company. Recently I joined Harness as a Field CTO. I'll be based out of London for the EMEA region.
Intersection of AI and Platform Engineering #
Renato Losio: How is AI already changing the way platform teams work today? What's your actual experience? How is it changing your organization?
Davide de Paolis: Definitely, AI is already changing how platform teams are working and supporting other teams. I see three areas where at least my team, from my experience, we benefit a lot. One is tactical. We know that there are a lot of tasks that are important, but never urgent and under the pressure of constant requests from the teams, roadmaps, OKRs, all these tasks that are like documentation, boilerplate, snippets of code, modules that have to be created for the teams, recurring Infrastructure as Code changes across multiple repos. All these things like diagrams, like documentation in general, all these things are normally neglected. Now with AI, it is actually very easy and cheap, relatively cheap in terms of effort to do them. This is where now I can see a great benefit. Everything that was neglected is now accomplished. Then on top of that, we have the operational part.
Normally, platform teams have to manage or to maintain or understand a very complex landscape. My team manages around 100 AWS accounts and overlooks hundreds of repositories with Terraform. We use AI to run this discovery, understanding the differences, finding the baseline, aggregating data, and deciding eventually what we want to work on. Strategically, it alleviates the burden on my team, because there are technical challenges on one side and organizational and communication challenges on the other side. By adding AI or some automation, or producing and providing internal MCP server or skills to the teams, we can avoid having this first line of support. The AI configured to use our own MCP server or our own agent can answer the first line of questions or produce immediately some code that otherwise we would need to do ourselves. This is how I see that.
Renato Losio: I'm particularly impressed that you mentioned the neglected part. The backlog that usually people are not taking care of. If I'm in a much more probably traditional environment, I'm curious if you see the same things in the banking sector, or if you have different experience of how AI is changing platform engineering.
Stephane Di Cesare: I think what we also see is what platform engineering is not changing. Because there are a lot of talks about now AI is coming and everything is different. I think what's important to realize is that platform engineering is still there. AI is just an extra tool that came up. Basically, it's a new way to do automation. Still, all the principles of platform engineering and of DevOps before still apply. It's just what changes is the scale is different. You're not only talking with workloads that are coming from humans, but also coming from agents. It's still important to think about the intent of your platform, of which services are you providing? What are they actually doing? This is actually becoming more important with AI to have a clear scope, to have clear APIs, but also to clearly define what are your services, what are they providing in which conditions, and so on.
Stephen Cihak: One thing on top of that is, as code generation, as the length of time it takes to create code reduces, it changes where the bottlenecks are. Before, they're releasing once a week, the bottlenecks now are changing to that outer loop, that deployment loop and the scans and all of the security pieces and the governance pieces that have to happen. It's really important to understand that platform teams have a lot more pressure to enable that self-service and quick deployment structure out to teams because the leaders are saying, we're investing all of this in AI tools that create this code. Why is that not getting out to production? How do we get that out there faster? It needs to operate at machine speed versus human speed. A lot of platform paved paths have manual phase gates and things like that that really slow down the process. I think the moving at machine speed is really driving some changes in platform engineering as a whole.
Camila Macedo: I think what everybody said is very interesting. As me, as a software engineer, I would like to share that I completely agree with Davide. I think AI is changing how we work, and we have no way to go back. The thing that Stephen actually said now, it's very interesting. Because he talked about the velocity of the release. Nowadays, AI is helping people find so many security issues. We need to do more pets. We are feeling like maintainers, I mean open-source maintainers, always behind, because it's very easy for someone using AI to find something. I think the most nice thing about AI, what it actually changed is how we handle unstructured data, because for the whole time, we need to have like a policy. We need to have data that is structured before we do something with that, before we are able to process. AI brings another perspective so that it helps the logs, help us debug the issues. For me, it's like a new layer that we are putting on top to help us human beings.
Adapting the Internal Developer Platform to the AI Era #
Renato Losio: Actually, I would like to go back to something that Stephen mentioned about the pressure of the team and the developers. I was wondering, as developers are increasing the use of AI coding assistants, agents, and whatever is new this week, I'd like to understand what capabilities should an internal developer platform provide to support them and eventually even which one should not provide. How do you draw the line and how do you help the team, and how to avoid that pressure?
Stephen Cihak: For us, we were looking at internal developer platforms as a strong workflow engine to really speed up the onboarding and provisioning of new services and infrastructure and automate a lot of those processes. I think that the end goal is ultimately, this could really be a strong CMDB for us. It could do better scoring on these systems. It could give developers more information and do more. That's still a very nascent goal. I think using the workflows in an IDP to help with that onboarding can really speed that process up and make sure that they're standardized right from the start. All the standards, everything that you need to set in the service when it starts up that people may have done over months of time can be done in minutes of time. IDPs become really important as time goes on in that provisioning, in that organization of those services, and then helping developers manage their day-to-day workflows.
If you extend that out, you can leverage agents on the backend, or platform teams can leverage agents on the backend to then help teams stay up to date with what Camila was talking around, the vulnerabilities that come out and we have to keep those up. Platform teams can build those agents and put it in there. Developers come in, they open up the portal. It says, I fixed 47 vulnerabilities across these services, please go deploy them. Those things can be really super helpful to teams as we continue to move forward. Renato Losio: Do you have a similar experience? Do you see the same pressure?
Davide de Paolis: Yes. Drawing the line and finding the balance between what you want to offer or what you want to centralize is the never answered question in platform engineering.
Renato Losio: It's not AI only.
Davide de Paolis: Yes. From our scale, at least what we do is trying to understand what are the pain points, the friction points in the teams and understand where there is a compounding cost in this inconsistency. If there are 15 teams doing a similar task, building a pipeline or onboarding a service on Fargate or Kubernetes, the role of the platform is understanding how we can abstract that and remove that from the team so that they can focus on really building the product, building the features. In terms of AI, I see a similar responsibility in terms of reusable context. There are a lot of teams that do similarly. They write code convention, like instruction for the code convention. They write skills to create PRs. They write skills to pull information from Jira, or Linear, or their ticketing system. Then they use AI to review and complete other tasks.
Managing this context can be done also from the platform or at least the platform team can manage how this context is stored and distributed, and also verify that this is done in a safe way, in a secure way. This brings me to the second topic that is the guardrails. You want to make sure that the agents can run safely and not go wild, go rogue, and take too much initiative when they hallucinate. Ultimately, but this is partially the case in my team and maybe another bigger organization is not the case, from the FinOps perspective, the platform teams regarding AI can manage and can decide, we use this tool and we manage the licensing, we manage the overages if you exhaust the tokens, and also apply some governance. What MCP server can be used by the agents? Do we want to block them or allow only some of them?
Renato Losio: I don't know if you want to share something about how you deal with what should be in the internal platform, what should not, and how do you support the developers?
Camila Macedo: For me, AI doesn't change actually the fundamentals. It's just more one service. In the same way that I have been trying to help and to contribute with the tools and software and frameworks that help the developers, I always try to think, what is the common need? That is something that you help the majority of people or the minority. The platform teams need to think about exactly the same. I think the common ground is what is common, what is the risk, and what is the cost? Because the teams should not need to reinvent the same solution if that is common for the whole organization. I think that is the place where the platform teams can help to provide any service, any integration, and not only about AI itself. About security, like they are saying, I believe for me it's exactly the same how we need to manage it for people, AI or agents, no matter, we need to think like we do for people. Things like least privilege, clear permissions, a strong policy, and to have a very good auditing is still more essential than ever.
Stephane Di Cesare: I quite agree with Camila. It's important not to get carried away by just AI, but look at what are the actual bottlenecks that our users or developers are having. Very often, what AI improves is you can basically code faster. What we see is that in many cases, the bottleneck is not the coding itself. For us, we are a bank, so of course, compliance, security are specific issues for us, and the bottleneck for us is more there. I think what's important for us is to enable AI users to work better with topics like that. I think part of the job of the platform is to centralize information about compliance, security, so that it's easier to use by agents. One interesting thing as well, which is a new challenge for platform teams, is, in the past, platform teams were working with topics like infrastructure, and normally, platform teams were better at Terraform than developers in general.
It was easier. Now, with AI, the thing is we're all on an equal footing. We have to help the developers with AI, but developers and platform teams are all starting with AI. I think it's more important than before to work together, to have a contribution model, because we are not always the one who are going to have the best solution first. We will have to work with developers to understand what they are doing and come together to the best solution.
Camila Macedo: I just would like to say for Stephane that I'm very happy that the bank is not trying to use agents to take the decisions. Because one day I can get up and see my bank account, I'm rich. The other, I'm poor, because it's not deterministic. I'm very happy that they are considering that with security, legal, and compliance. I have a lot of concerns about agents being free to take the decisions without a human being. If you check Anthropic, for example, we don't have so much data and statistics about that. Anthropic from Opus 5, the benchmark is like 25% to 65% of accuracy with regards to code. We cannot really trust in the decisions that are taken by AI.
Example Developer Platforms (Internal/Open-Source) #
Renato Losio: Do you use Spotify's Backstage as a developer platform or you have a custom one? Who has any experience with Spotify or, in general, any open-source solution or any other solution, or if you buy a developer platform, you start from scratch internally.
Stephen Cihak: We used Harness's IDP, which is based on Backstage. It plugs into all of the Backstage plugins you can get. Then there's some other ones that Harness is using and developing. I'm sure that product will continue to evolve and grow over time. It's open source. I'm very excited to see where that goes. I know there's other products out there as well, but it fit into our ecosystem. That was very important from a platform first mentality.
Stephane Di Cesare: I just wanted to clarify that there are IDPs and IDPs, and IDP can mean portal or platform. In that case, so I think Backstage is the portal and the portal is part of the platform. The platform is broader than just the portal. As I was explaining before, I think also part of the platform is not only providing the tool, but also centralizing the information, for example, so documentation and so on. We can have a lot in the portal, but it's not only the portal.
The AI and Human Aspects of Developer Platforms #
Renato Losio: Actually, I wanted to ask something slightly different. We mentioned before the human aspect, but I think that until now, we have developer platforms that were designed to serve human developers. We start to see apart from the AI aspect or a developer using AI tools, that we start to have agents, so not humans, consuming the platform directly. I was wondering if that is going to change something or it's just one extra layer, but at the end, nothing changed from the platform. I don't know who has any opinion on that.
Stephen Cihak: I really foresee that in the near future, if not now, we're going to need more of an autonomous SDLC where you've built into that flow, into that deployment flow or all the pipelines, all of the guardrails, all of the governance, it produces evidence and it constrains the agents appropriately. You've got systematic permissions set up to ensure that the agents that are used in those flows do not go overboard. A lot of this isn't just because we need to operate at machine speed versus human speed, but it's because the flow of services and changes are going to be extremely rapid, and we're just not going to keep pace if you still have a CAB that meets once a week to decide what's go out. That's not going to be fast enough to manage all the change. I also foresee a point where you have agents that are going out and making decisions about, there's a bug that was found, there was an error, the agent takes the error, it looks at the code, it figures out the fix.
It builds the fix. It submits the PR, and you have other agents that go through the process of then deploying and ensuring there's no vulnerabilities and that it's working right. You've got tests, and all of that is all set up. It's going to be super important that we have very strong governance that it's producing evidence around the decisions it makes and that's out there and available for any auditing. That autonomous SDLC is going to be really important. On top of just agents doing it, you're going to have your business developer or citizen developer, whatever you want to call them that are not engineers but are using these tools to go create systems and applications that make their jobs better, and they're going to want to deploy them. You need high levels of automation to help them through that, because, frankly, they're not going to know how much CPU they need on a piece of infrastructure. AI is going to have to be used to figure that out for them or it's just going to, again, slow them down and you're not going to be able to get the benefit of all the high costs of all these tokens that are being spent.
Stephane Di Cesare: What I think is we shouldn't forget as well that agents are not completely autonomous. There's always a human behind at some point. I think it's important especially for the developer side. You still have an intent of what you want to reach. You will be able to reach it in ways that are more automated and autonomous than before. What you want to reach is still your decision and not the agent's decision. Also, for even how autonomous agents are, this is part of your decision. I think that's the important thing that, in the end, the platform is still serving humans but through agents that are faster than before. The scale is changing, but it's still humans who should decide what the intent is.
Davide de Paolis: I wanted to connect to something that both Stephane and Stephen said. The first thing is about the scale. What definitely changes is the scale. Stephane mentioned that before, our platform had to sustain the load of a human pace. Now, if a developer is very advanced and uses agent orchestration, so he's able to run spec-driven development on multiple tickets at once, we have this bottleneck of a lot of PRs. In our case, my platform team is responsible for the GitHub runners where the pipelines are running, and we need to sustain that load. The second thing that I want to mention, which is ironic, is Stephane said that one role of the platform teams is to create this knowledge base, this documentation that the teams can do and that you share in the company. What I find ironic recently is that we all knew since ages that we need proper documentation, proper processes, to make proper specifications for the developers to do their job properly.
Only now that we have agents, only now that we have agents hallucinating or missing the context, we are focusing on improving the documentation, making the knowledge graph, so that the agents can work properly. This is ironic, but it's still a good thing, because we can spend now the time to help agents and humans at the same time.
Renato Losio: The topic about performance is really quite an interesting one, because you can see starting from GitHub down the entire road, how outages are part of life at the moment. There's nothing wrong on their side, but it's just what a human does is different from what the agent does.
Camila Macedo: I really agreed with the folks. In my opinion, when the use of AI is a tooling, is a help doesn't change too much. Because at the end of the day, human beings need to operate that system. At the end of the day, human beings need to understand that system. As a software engineer, I think one of the hardest parts is build software, not generate the code. That is not the hard part, but to build something that is sustainable over time, that people will understand, that you can maintain for long. The challenge is that usually you take some time, two, three, or five years to discover if your decision was good or bad. When you think about doing the solutions with AI, about the documentation, I think in software in general, AI brings another challenge because, ok, I believe that the documentation should be in the code, should be in the API, should be where you see the people, where you see the developer, and also where you see the AI. I think the AI can help us to improve our standards, to improve our standardizations, but to not remove the deterministic aspect of the software, but to help you improve all fundamentals and concepts that we have been working on over the years.
The Changing Role of Devs and Platform Engineers in the Age of AI #
Renato Losio: Do you see developers today doing tasks that in the past would have been platform engineer work and now is done by the developers? If yes, how is your platform engineering role changing in response to developers doing more in the infra platform space on their own?
Stephane Di Cesare: I think it's a general topic with AI. It's not only with infrastructure. It's that AI has lowered the bar to be able to do technical work in general. You have more people who were previously not in technical roles who start to build things with AI. Where we as platform engineers can help is that we have the operations background. For many of these people, they don't realize from the beginning that the challenge is not only building, but the challenge is being accountable for what you maintain. Building things is very easy with AI. Recently, I was working with frontends for the first time. Last time I worked with frontend was with Visual Basic. I was assisted by AI. The AI was doing some very crazy things that even for a quite incompetent developer in frontend as I am, I could see that probably including HTML directly in frontend components is not a good idea. I think that that's where you still need specialists to be able to look at that and to see, it works, but is it really something that you can maintain afterwards?
Camila Macedo: I would like to share that the question is very interesting. I totally agree. Doing something that works is one thing. Doing something that actually solves the problem and can grow, for long periods of years, it's another thing. How many times do we see a team saying, ok, let's throw all up and start from scratch, in our profession. You spoke about development infrastructure. In the last years with Kubernetes came DevOps. It's a developer that knows something about operations as well. That is my focus, like how to extend Kubernetes. How to help the developers. It is a big challenge because you need to learn a lot of things about how infrastructure works to do a nice job. Also, if someone came from infrastructure, they need to learn how development works as well. I think nowadays, if you want to work with cloud, with Kubernetes, you need to have a broad understanding of the pieces, at least the fundamental and the concepts, to be able to bring more value on the table as a professional.
Stephen Cihak: I just want to mention briefly, when you think about platform teams and why you have them, it's because you're trying to centralize and standardize on whatever it is, infrastructure, deployments, whatever that is. If you have all the developers going out and starting to create their own infrastructure, that breaks down very quickly. You either need to codify all of your rules around this piece of infrastructure and how it runs and how it works and how it's set up so that everybody follows that, or you still maintain some strong oversight into the infrastructure that's used. You don't want to tamp down innovation. You want people to innovate. You need to give them some freedom to do that. That's where I think Stephane mentioned this earlier about that inner-source model, where developers that are interested in building new infrastructure or what infrastructure is out there isn't solving their problem, work with those platform teams and come up with a new way to do that. That standardization is, I think, supremely important because of all the variation and all the potential for issues and problems as that random infrastructure gets deployed out.
How AI is Changing How Platforms Are Built #
Renato Losio: How is AI actually changing the way the platform teams build and maintain the platform? How is AI changing how you build your own platform?
Davide de Paolis: This connects with the very first question, somehow. We use AI to have a platform for ourselves that allows us to be faster, to elevate ourselves and boost our performance.
Renato Losio: To do what was neglected before is part of it.
Davide de Paolis: Yes. I can give you an additional answer that also connects to the previous one, because we are also receiving a lot of requests from the developer teams saying, "Why can't we deploy or write our own Terraform code? It's easy now." It's true. What we use AI for, for our work, is to simplify, to get a little bit in that direction, to get closer to the teams by providing skills or internal MCP server that allow the agents of the developers to do the right thing. If they want to write some Terraform code, they are not getting the answer from Claude or Kiro, pulling some snippet from Stack Overflow or from the documentation. The agent will use our skill, our Kiro power, and the agent knows that we have a specific repository with some modules and how to use those modules. This allows the developer to have more confidence in what they are doing and us having the confidence that they are doing the same as we would like it to be. This is how I see that moving forward. Of course, that requires guardrails and more governance so that things don't go wrong. We need the platform to provide sandboxes where the agent can run. We need to work on, for example, the AWS SCPs to prevent that, for certain stages, some resources can be destroyed or tampered with.
Camila Macedo: I just would like to share, for example, some very nice practical examples that I see with AI, is the support. I think the folks spoke about that, that you have a base of knowledge and answer people. The other thing is like, in the platform, when we are looking in the cloud or whatever, server, no matter, we have a lot of logs. AI can help us to filter the data, can identify the problems. I think an agent is very nice to open issues, not to solve the problems. We can use as a developer, but we need many interactions, and to have a nice result using the agent. I think they are not good enough to solve the issue in a very nice way, once. They can open the issues for us to analyze and to help us initially, at least to get started to address the problems. Those are three things that I think is very cool with the use of AI.
Standards, Governance, and Guardrails with AI #
Renato Losio: Actually, I want to go back to something that Davide just mentioned that is guardrails and maintaining standards. It can be as well just in terms of cost, FinOps, whatever. It's like, I don't know if it's in every company, every project that I see, whatever is adopting new models, whatever is adopting one new shiny tool that maybe improves the way you develop the code, but is one more for the platform team to manage, take a look at it, see if it's compliant, see where the data resides, and so on. What's your experience with setting guardrails and maintaining standards? What's the hardest part that came up with AI? I don't know if something changed or is that as before?
Stephen Cihak: I think AI is putting a lot of pressure on to drive more standards, just because we're seeing a lot more variability. The non-deterministic nature of these tools, you can put the one prompt in and it's going to come up with 14 different ways to do it. I think it's becoming more and more important to have those guardrails, to put that governance in, to make sure that there's those checks as you deploy things out, to validate. It's about making your non-deterministic tooling more predictable by putting that governance and guardrails in the system that it runs within. That's how you manage that because you're never going to be able to manage the non-deterministic nature of a model response, but you can put those guardrails in to make sure that it's following the rules that it needs to. Then you can add the AI evaluations on top of it to understand if there's model drift or there's response drift that is happening within that model.
I've seen it where the model is changed underneath you silently. If you're not monitoring those responses on a regular basis, you can get various results that you were not expecting because that third party is tweaking their model and not really talking about it that much. You do have to be very careful, and that's where the governance and the guardrails and those post-production evaluations are super critical.
Renato Losio: I'm pretty sure that in the banking sector as well, guardrails and maintaining standards is quite a central part of the world. I was wondering if AI has changed that, made it worse, made it simpler?
Stephane Di Cesare: I agree with what Stephen said. The scale is increasing, so it makes it more obvious that it's needed. I think it's not only about the guardrails, it's also about making clear to the agents what is your architecture, what are your principles. I remember someone saying, you don't drive a car by bumping into the guardrails, which I think is a good image. It's important to make clear not only what the guardrails are, but where is the middle of the road as well. It's always been there when building a platform, but it becomes more obvious than before now.
AI and The Future of Platform Eng #
Renato Losio: One obvious follow-up is, I see how AI has been the central focus of what we've discussed today and what we're discussing, not just for platform engineering, for entire developer experience in general. I was wondering what you expect to be in a few years' time. If I look higher, do you see AI making the entire internal platform more central, that as we say now for guardrails, is they become even more important, so the platform became just even more important today, or basically, some agent will take more of the work that the platform used to standardize, so will be out of the question.
Davide de Paolis: Definitely, AI will steal some of the platform work, not jobs. There is a lot of work that we do daily, which is toil, which is repetitive work, which is something that we can delegate to AI. All these parts will go away, and I don't see that much of a problem in that, because there is still a lot of complexity. We will have more complex, more challenging problems that the skilled engineers that we have in platform and infrastructure teams can solve, rather than fixing this configuration or checking through logs. If we even consider some of the agents that have been released by AWS recently, like the security agent or the DevOps agents, all these analyses, all these AI tools that alleviate all of this work, take away something, but we have on top all the work that we need to add as a platform team for the governance and for the context layer.
That part can go, and we have newer challenges how to make sure that the agents behave in the way that we want. In general, I see this identity crisis similar to those of engineers. If we consider ourselves as, yes, I write code, or I write the configuration of the infrastructure, yes, that might be a problem with AI. If we consider ourselves as solving problems within the company, enabling other people, this is not going to go away.
Camila Macedo: I'm laughing because a lot of engineers say, AI will take our job. I don't believe in that. In the same way that the compilers didn't take the engineering developer jobs, I don't think AI will do the same. Compilers abstracted a lot of complexities as well. In reality, the world needs more and more people working with technology, having more roles, more things to do. I think AI is evolutionary, but is just another solution. It's another layer of abstraction. People that actually understand the code, are still required. Indeed, in the future, AI will be very good in generating code. I think you will still require people that can understand, can maintain, and can keep things running, and be able to actually deal with the problems. Other positions are starting as well with AI. We see many other kinds of jobs that are related to this new technology.
Renato Losio: Where do you see platform engineering going in the next five years?
Stephen Cihak: Five years? That's a crazy horizon right now. If we think about the future of this, I don't necessarily see job displacement as opposed to task displacement in platform engineering. I think platform engineering becomes more and more critical as the world continues to move into the space. Because we will need to drive to that full autonomous SDLC where somebody has an idea and the outcome is a system that's running in production. Platform needs to play a huge role in ensuring that that whole process, that full SDLC, and the agents that are running within it and making those decisions are well governed. They're producing evidence, especially for regulations, because they're not going to keep up with an AI sped world. You have to produce that evidence. Making sure that that pipeline is well structured and governed. You think about like the highway system versus the freeway system.
Highways, you can go 55, 60 miles an hour because they're little two lanes, you go off the road and you're in a ditch and rolling over. Then they built these freeways where traffic is separated and you can go significantly faster. You have to build stronger, larger structures to allow things to go faster. People are going to need to spend time figuring out what those structures are. It's just going to take a lot of effort to get there. I do believe that we will. If you don't have that, then it's like driving through the Outback and you're going to hit bumps and rolls and you're not going to be able to go as fast. You have no idea which way you're going anymore because you'll just get careened off in the wrong direction. It's really important to have that platform team that's there, and structured, and building that autonomous SDLC that's really well governed to allow you to go at machine speed.
Measuring the Success of an Internal Platform #
Renato Losio: What metrics do you prioritize to prove that platform engineering is actually reducing the cognitive load for engineers? I assume it's not tokens used.
Stephane Di Cesare: I have to say that I don't have the answer, but it's the main challenge I'm working on as working with platform experience because, at the end of the day, this is something subjective. We are good with objective metrics. It boils down to, are the developers satisfied with the platform? Are they confident that they can be accountable for lots of what they are doing through the platform? It's something you can ask for qualitatively, because you always know a few developers who are very good at giving feedback and you can work with them. At the end of the day, management is going to ask you, I'm not just interested in what three people think, but everybody. Our challenge at the moment is to increase the trust of the developers into giving us good feedback, because we've seen that developers have had the tendency to see the platform team as the ops team and also as the team who says, no.
I would like to do that, and, no, it's not supported. I think it's very important for us to think about psychological safety, to make sure that the developers want to tell us what their problems actually are. It means that everybody in the team must take them seriously. Even if the answer is going to be no, you need to get developers to trust that you are interested in them becoming more effective, even if you can't help them right now. I think that it's something you can only fix in the long term.
Camila Macedo: I'm actually very interested in what the folks that work with more management side, also think about that. Because in all my life, all my career, I never found anything that actually is very effective about how to measure the work of the development, if it's good, if you really have a good velocity. It has many methodologies, but nothing actually seems to me plays a very assertive role. For me, it's not more features. I usually try to think about how many bugs, how many incidents, how long it takes for someone new to onboard to the team and to understand that the AI is hallucinating and to generate. How long all these things take, and how they are doing that.
Renato Losio: How do you measure if your platform internally is successful?
Davide de Paolis: We are working on that. Providing data to my director and to management about the value that we are providing is still something that I'm figuring out. I agree with what Camila just said. Our main role is to enable people and allow them to be faster. The simplest way to understand if we are really helping is with onboarding. How long it takes for a team to go from idea to production. What do they have to go through in terms of setup, configuration, deployment, what pipelines they use? This is easily measurable. If there are multiple teams that need to take three weeks to deploy something on a Kubernetes cluster or on Fargate, and we can remove that work and provide a reusable solution, a ready-made solution that brings that down to one hour, this is definitely less cognitive load, less effort on the team. The team can focus on building the idea, not where it runs and how.
Something else is how many requests, this is both quantitative and qualitative. Like how many requests we are having either on Slack or in messages that go back and forth. If there is a back and forth in the PRs, if there is a back and forth in the messages or in the comments, it means that the communication is not clear, that something is missing in terms of documentation, in terms of knowledge, and we can maybe improve that. Then we can proxy some of the DORA metrics as well, before and after the platform team was created.
Stephen Cihak: The main thing I'd like to reiterate, Davide said it earlier, which is, make it easy to do the right thing. If you're doing that and you continually do that, you'll reduce cognitive load. To measure it, again, it's that ideal outcome that Davide mentioned. Completely agree with everybody else's comments as well.
See more presentations with transcripts