Operations | Monitoring | ITSM | DevOps | Cloud

As a baseline, engineering leaders need their teams to adopt AI tools to speed up velocity and ship faster. Most organizations have already rolled out AI coding assistants or are evaluating them, but there's a really big difference between buying a tool and successfully scaling it across an engineering organization. If you layer AI on top of a chaotic codebase or a disorganized service catalog, you accelerate the creation of legacy code.

Modern software systems are more distributed, complex, and business-critical than they've ever been. A single misconfigured service can take down an entire platform. Teams are aiming for production readiness, which is the state where your services are secure, reliable, observable, and owned. Production Readiness Reviews (PRRs) are one of the key mechanisms to get there.

You're in a planning meeting when someone asks a simple question. How long does it actually take your team to ship a feature? You've got spreadsheets, Git logs, and Jira exports scattered across three tabs, and you still can't give a confident answer. It's a question you should be able to answer instantly, but the data lives in too many places to stitch together on the fly.

Pragya Jazwal, Platform Engineering Lead at Paxos, compared standing up an internal developer portal to buying a gym membership during her talk at IDPCON 2025. Purchasing the software is one thing, but convincing a team of busy engineers to change their daily habits is a much bigger monster to tame. Pragya says the platform team at Paxos learned this lesson the hard way.

Throughout 2025, we watched AI transform from a novelty into a non-negotiable requirement for engineering teams. Leaders moved quickly to roll out coding assistants, driven by the promise of unprecedented velocity. But as we settle into this new reality, it’s becoming clear that there is a massive difference between buying a tool and successfully scaling it. You can't just drop AI into a complex organization and expect it to work without a solid foundation.

In the late 2000s, the big question in database design was SQL or NoSQL. While relational databases had long held their ground, document and key-value stores were emerging as serious alternatives. Many predicted a zero-sum, winner-take-all outcome. But when we look at how organizations are using database technologies today, no single tool or category has dominated the landscape.

These days, engineering leaders find themselves caught between a rock and a hard place. On paper, AI adoption looks like an unqualified success. Developers are shipping more code faster than ever, pull request volumes are up, and teams report feeling more productive. Their leaders rush to LinkedIn to share their plans to scale adoption because their teams are just so much more efficient. But then, the incidents and bug reports start piling up.

There's a moment every engineering leader hits when implementing AI where they realize that no one really knows what they're doing. Not your competitors. Not the consultants. Not even the executives pressuring you to show results yesterday. Everyone is figuring this out in real time, and beneath the confident vendor pitches and LinkedIn thought leadership, the truth is messier than anyone wants to admit.

This blog is based on Haylee Millar's talk at the Symfony 2024 conference. Haley is a Product Engineer at Upsun. We utilized AI tools for transcription and to enhance the structure and clarity of the content. When faced with an aging system that needs new features, many development teams find themselves at a crossroads. Do you patch the old system and risk technical debt, or do you take the leap into microservices architecture?

You've set up the Cortex MCP and connected it to your AI assistant and IDE. You ask about service ownership, check a Scorecard or two, and it works. You're impressed by how much faster this is than clicking through the web UI. Now you're wondering what else you can do with it. I'm willing to bet we've hit a nerve with that "hypothetical" scenario. The Cortex MCP works exactly as designed, but it's deceptively difficult to know which questions to ask and when to ask them.