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.

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.

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.

For decades, engineering leaders have struggled to measure the productivity of their developers. Metrics such as number of PRs merged, lines of code changed, hours worked, and tickets closed were always flawed. They incentivized the wrong behaviors and ignored code quality and best practices. Ultimately, they were the perfect formula to make Goodhart's Law a reality. Measures became targets, which meant they ceased being good measures.

Every December, Spotify launches its infamous Wrapped campaign, which sends millions of users into a frenzy about their listening habits. They become pseudo data scientists and analyze how frequently they listen to their guilty pleasures, their kids' terrible playlists, or the music they love that nobody else has heard of yet. We love this tradition, so we're bringing it to Cortex.