Platform engineering can be a slippery term because it means different things depending on where you sit. For some teams it means golden paths, paved roads, and internal platforms. For others it means the group that owns all the infrastructure glue no one else wants to think about. And somewhere in the middle is developer experience, which may or may not be a separate function depending on the size and maturity of the organization.
In this episode of Day Two DevOps, Kyler and I spoke with Annem Shah about how she thinks about platform engineering, DevEx, infrastructure as code, and the growing role of AI in day-two operations. Annem is a cloud platform engineer with experience in government, consulting, and product-led engineering, and that range gives her a useful perspective on what good platform work actually looks like in practice.
What I appreciated about this conversation is that it never drifted into hand-wavy theory. Annem kept bringing it back to the practical realities of supporting engineers, choosing tools, and making systems easier to operate without locking everyone into bad decisions forever.
One of the strongest themes in the episode was that platform engineering is not just about tooling. It is also about creating a safe and useful interface between the platform team and the engineers using that platform.
Annem talked about setting up an infrastructure guild inside her organization as a way to spread knowledge across engineering teams. Rather than treating infrastructure as something mysterious or locked away behind a ticket wall, the guild creates a regular place for engineers to learn, discuss architecture, and work through system design ideas together.
I especially liked her use of an “engineering Kafka,” which is essentially a fictional architecture exercise. Instead of arguing over the current state of a production system and all the ego or baggage that can come with that, the team works through a hypothetical scenario together. In the episode, Annem described a sandwich shop with online ordering and lunchtime traffic spikes. From there, the group explores questions around scaling, latency, APIs, payments, and architecture choices.
That is clever for two reasons. First, it gives people a safe playground where there is no single correct answer. Second, it builds shared language and trust that teams can carry back into their real systems. That is culture work as much as platform work.
Another theme that came through clearly is Annem’s view that software engineers, engineering leads, managers, and on-call responders are all internal customers of the platform.
That sounds obvious when you say it out loud, but not every platform team behaves that way. Plenty of organizations still operate with an old infrastructure-request mindset where one team throws tickets over the wall and another team grudgingly fulfills them. That model rarely creates a good developer experience.
Annem described a much healthier approach when her team onboarded a new CI/CD workflow tool. Rather than selecting a tool in isolation and forcing it on everyone, she worked directly with the engineers who would be using it most heavily. She gathered feedback on what mattered day to day, what features they relied on, and what would actually help them provision and manage infrastructure more effectively.
That kind of working group matters. If you have ever had a beloved tool ripped away and replaced by executive fiat, you know how much friction and resentment that creates. When engineers are invited into the decision-making process, they are much more likely to trust both the tool and the team introducing it.
When the conversation turned to AI, I think all three of us lit up a little bit because this is where platform engineering gets especially interesting.
There is a lot of marketing noise around AI writing code from scratch, building entire applications, or somehow eliminating the need for expertise. That is not the part of the workflow I find most compelling. What stood out in Annem’s examples was how AI helps with the ugly middle: imports, migrations, bootstrapping scripts, feedback loops, and deciphering inscrutable errors.
Annem talked about using AI assistants to accelerate the painful process of migrating infrastructure definitions and writing supporting scripts. She also described experimenting with MCP-style workflows and giving an AI assistant access to enough context to generate GitHub Actions pipelines that mimic the human-friendly experience of HCP Terraform.
That is a more grounded use case than “AI will run your platform now.” It is about reducing toil.
One idea I mentioned on the episode that probably warrants more thought is that SaaS vendors have a good reason to be nervous about AI.
Historically, a managed platform could keep customers partly because reproducing its behavior somewhere else required a lot of specialized time and effort. But if AI makes it cheaper and easier to recreate useful workflow patterns, generate migration scripts, and stitch together replacement automation, then some of that lock-in weakens.
That does not mean every managed service is doomed. Managed platforms still provide a lot of value, especially when it comes to reliability, support, and abstraction. But AI does appear to be shortening the distance between “we depend on this product” and “we can probably build enough of this ourselves.”
If there was a single takeaway from this episode, it is that platform engineering is at its best when it combines thoughtful tooling, developer empathy, and a willingness to revisit earlier decisions. The job is not just to build the platform. The job is to make it usable, adaptable, and survivable on day two and beyond.
Platforms are for building after all. The shape of the platform dictates what can be built atop it. Being intentional and mindful of the platform accelerates development and empowers DevOps teams on day two and beyond.
Written with help from AI
The State of Platform Engineering and DevEx
April 13, 2026
February 4, 2026
January 7, 2026
January 2, 2026
