The problem isn't just generating code - it's knowing how to fix it when things go wrong

Key takeaways

• Domain knowledge gap is real. Current AI tools lack the functional expertise necessary for complex enterprise environments, requiring experienced engineers to validate output.
• Senior engineers are strategic adopters of AI. Their approach of "break it first, then adopt it" proves more effective than junior engineers' immediate embrace of positive scenarios.
• Production debugging crisis is coming. As AI-generated code becomes more prevalent, organizations will face increasing challenges debugging code they didn't originally understand.
• Incident management needs AI. Growing customer expectations for comprehensive incident documentation present a significant opportunity for AI-powered solutions.
• Domain-specific tools are the future. The industry is moving toward specialized AI tools that understand particular business contexts rather than general-purpose assistants.
• Experience shapes AI adoption. Having lived through the 60-hour incident makes every subsequent decision about tooling and processes more thoughtful and prevention-focused.

About

I'm an engineering manager at Zoom, managing teams across the US, India, and China, focusing on contact center solutions like virtual agents, chatbots, and workforce management. I've been at Zoom for three years, but my AI journey started before that.

Before Zoom, I was head of engineering at an AI startup called Solvvy, which was adopted by major enterprise customers. When Zoom acquired Solvvy three years ago, I brought my deep AI experience to Zoom's engineering organization.

What was your “aha” moment with AI?

Like many people, my big revelation came with ChatGPT's emergence. But what struck me wasn't just the technology itself - it was how it completely changed my perception of what was possible and how quickly things could happen.

I realized that experiences I thought would take years to develop could now happen in hours or minutes. It was a fundamental shift in understanding about the pace of AI development and what these systems could accomplish on their own.

"I think just ChatGPT's evolution was my aha moment. It came out of left field and surprised everyone. It was very enlightening because you just didn't know that systems can do this on their own."

Tell us about your journey with AI adoption in your enterprise?

My approach has been driven by a practical problem: how do you increase team velocity without burning people out? There's always more work than people, and there's a limit to how many engineers you can add to a team.

So I started looking at where time was being spent and where it was being lost unnecessarily. AI became a way to potentially gain back some of that lost time and deliver more value with the same team size.

"There is always a threshold of how many people you can add to the team to actually deliver something that you can afford. But then you are trying to figure out where is the time being spent and where is the time being lost potentially that you can kind of gain back and deliver more."

Over the past six months, I've done POCs (Proof of Concepts) on 6-7 different AI solutions. I've looked at everything from code generation to test case generation, API testing, product requirement generation, and even process documentation.

All of this exploration has been done carefully, considering security constraints and protecting proprietary code. I'm not just jumping on every new tool - I'm systematically evaluating what actually adds value.

"We have been looking at all of the AI coding tools mainly because I think it's a very straightforward application. Last six months we have been doing that and we have actually explored around six to seven solutions."

What is a gap that you see in AI systems currently?

This is where my experience gets really interesting. I've found that AI tools are great at generating code, but there's a major gap when it comes to understanding what happens after deployment.

The problem isn't just generating code - it's knowing how to debug it when things go wrong. If you don't understand how the code was generated in the first place, you're in trouble when you need to fix it in production.

"Everyone is deploying code, but they don't know how to understand after deployment what has happened, how do you debug it? And because if you're not aware of how the code was even generated, you don't know how to debug it if something bad happens."

The biggest gap I've identified is domain expertise and functional knowledge. Current AI tools are very procedural - they'll generate code based on your input, but they don't really understand what they're doing in the context of your specific business or domain.

You still need experienced engineers with domain knowledge to monitor and validate what the AI produces. The tools are good at following patterns, but they lack the deeper understanding that comes from years of working in a particular field.

"It doesn't have the subject matter expert or domain excellence, it's still missing from these tools because they just don't know. These are very procedural - the output is as good as input in these cases, and it will just generate the code for you. It doesn't really know what it is doing."

How do seasoned and junior engineers approach AI differently?

I've noticed a fascinating pattern in how engineers of different experience levels adopt AI tools. Senior engineers tend to be much more skeptical and strategic in their approach.

Senior engineers will deliberately try to break the tool first, giving it prompts they know probably won't work well. They want to understand the limitations before they trust the tool. Junior engineers, on the other hand, tend to focus on the positive scenarios - they're happy when the tool generates syntactically correct code without obvious errors.

"The seasoned engineer is trying to break the tool first by giving it prompts that they know that it's probably not gonna generate the code that they want. Senior engineers are very particular in trying to break it first, then adopting it."

Have you seen AI-generated code creating a lot of production incidents?

Yes, I've already encountered a few incidents where AI-generated code created debugging challenges. In these cases, engineers found themselves wishing they had just written the code by hand because then they would have understood how to debug it.

While these incidents haven't fully hit our production systems yet, I can see this becoming a bigger issue as AI-generated code becomes more prevalent across the industry.

"We have seen a couple of incidents where this has already happened, where you just don't know, okay, what has this done? It would have been better if I had just handwritten that code because then I would have known how to debug it."

Where do you see the biggest opportunity for AI in software engineering?

One area where I think AI could make a huge impact is incident management. I believe most companies spend way too much time on incident management, and this problem is getting worse as customers become more demanding about explanations.

Enterprise customers now expect detailed root cause analysis, explanations of what went wrong, and plans for prevention. Engineers end up spending massive amounts of time going back months to trace how features were built and writing detailed post-mortems.

"One of the things that most companies I believe are spending time on is incident management. There is a lot of time being spent on incident management because nowadays even customers are getting very particular about 'tell me what happened and why this happened and how are you gonna avoid it?'"

I predict that AI tools will become much more domain-specific over time. Instead of general-purpose coding assistants, we'll see specialized tools for different industries and use cases.

In six months to a year, I expect to see things like "Cursor for finance" or "Cursor for customer experience" - tools that understand the specific context and requirements of particular domains.

What are customer expectations when you hit an incident today?

Customer expectations have become much more demanding, especially for enterprise customers. They expect systems to never fail, but that's just not realistic - systems will fail. When they do fail, customers want comprehensive documentation of everything that went wrong.

This means engineers have to do extensive forensic work, sometimes going back six months to understand how a feature was implemented, and then write detailed analysis including 5-whys or 10-whys exercises. It's necessary work, but it takes a lot of time.

"They expect your system to never fail and that's not the reality. The system is gonna fail. When that happens, they want you to document everything that went wrong when the system arrived at that error or issue."

What’s your most memorable on-call experience?

I was in a 60-hour continuous incident response six years ago. My entire team was working around the clock with minimal sleep, trying to figure out a system failure that could have been avoided with better due diligence.

This experience completely changed my approach to incident prevention. Now, every decision I make is guided by the question: "How do I avoid putting anyone on my team through 60 hours of continuous incident response?"

"I think we were on call for around 60 hours non-stop. Everyone slept for two hours or less. It was an issue that could have been avoided, and it was a great learning experience. My every approach now from that point on is how do I avoid 60 hours for anyone in my team, including myself."