Operations | Monitoring | ITSM | DevOps | Cloud

Most engineering leaders have a very known and very annoying "normal error." It's the log entry or deployment glitch that has been around so long that it is simply accepted as part of the status quo. Jeff Schnitter, a Solution Architect at Cortex, describes this as a form of organizational Stockholm syndrome. This mindset is unsustainable for several reasons.

I remember the first time I used an AI coding assistant. I watched the cursor dance across my screen and generate a hundred lines of code in seconds. It felt like I had finally found a cheat code for software engineering. That initial rush of productivity is a dopamine hit that's intoxicating and makes you think you can do anything with just a simple prompt or two.

Anyone who has ever attempted to learn the guitar knows the lure of buying high-end gear. Surely, an expensive guitar and a best-in-class amplifier will hide the fact that you only know a few chords and maybe the lead line to that one song you keep hearing on the radio. What most players find out, however, is that spending thousands of dollars on gear doesn't change the fact that you're not that good yet.

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.