Transcript for "Engineering in the Age of AI:  2026 Benchmark Report": Hello. Hello. Welcome everyone to the podcast. I'm sure everyone is thinking about AI every day when you wake up, when you go to bed. We're gonna be talking about engineering in the age of AI today. Excited to have everyone. And with that, I will hand it over to Kara to kick us off, and we'll jump into intros here in a second and get into the weeds. Hi, everybody. I hope everybody's having a good morning, afternoon, night, depending on where you're tuning in from. I'm Kara Gillis. Welcome to the engineering in the age of AI webinar, where we will discuss the major themes that we found in the Cortex inaugural 2026 benchmark report. I am the VP of product here at Cortex. It's been such a fun ride, working on these challenges and building products that our customers love. And my fearless leader, Ganesh, why don't you introduce yourself? Yep. Hey, everyone. I'm Ganesh, one of cofounders and CTO of Cortex. Just a little bit of background about me. I was a software engineer before I started Cortex. I used to work in, fintech for a while. And I started Cortex because I saw the monolith to microservice journey as part of a team that pulled the first service out of a monolith and saw the the explosion to a couple 100 services by the time I left. We had a ton of challenges around everything from keeping track of services and teams and ownership and production readiness and all the things that, increased the chaos of, supporting such a large ecosystem of software and eventually decided I was tired of all the manual efforts we were doing to keep that stuff in check, like spreadsheets and Confluence pages. I started at Cortex six years ago. This has become even more exciting than ever before because, we were able to explode our software complexity as just humans writing our own code, and now we have AI writing even more code. And so the complexity is getting worse and worse. And so, very excited to talk even more about that today and how, how we how we should be thinking about that. Awesome. Thanks, Ganesh. So today, we'll be covering what engineering leaders shared with us that their biggest concerns with AI were, what issues they've already faced as they've adopted AI coding tools, as well as a plan to mitigate these challenges from the best practices that they told us, and also some of the things that our customers tell us every day. And so, you know, we're grappling with this ourselves as a software development tool. But it's gonna be a really fun conversational tone. And we're gonna leave at least ten minutes at the end for q and a. So definitely pop some questions in there as we begin the webinar or during the webinar. We'll try to get to them as much as possible. So just to kick things off a little bit, some of the key findings, you know, from the report that were quite illuminating. I'll mention two of them as we get into security and governance a little later in the hour. But the first one I like to call actually, the report calls it the productivity paradox, which is really when development velocity is up, but the quality is becoming a challenge. Obviously, like AI coding assistance, they're creating a massive amount of more code per developer, you know, with a 20% year over year increase in PRs for author, which I thought was, like, you know, really wild. But speed comes with quality issues and stability issues. And so the incidents per pull request increased by 23 and a half percent, which is higher than the productivity gain. And there was a 30% increase in change failure rate, which suggests that more bugs are making it into production. Right? So I think we we know that the foundations haven't really changed here and strong foundations for any software development tool, for any, you know, technology company and pretty much all companies today are technology companies. They have a differentiator because they are producing higher, you know, quality releases. They gain more trust with their customers. And some of the things that contribute to those strong foundations are testing and automation coverage, secure coding practices, clear ownership, right? Some of the incident response practices that they employ, you know, having really strong post mortem reviews, post incident reviews. They have maybe complete documentation. They have service catalogs. They have vulnerability management. They have, you know, great security scanners for their code. These are some of the things that we were seeing. And what we also saw in the report is that AI adoption is really widespread, but it's highly unstandardized. Right? So nearly 90% of engineering leaders are reporting that their teams actively use AI tools, but there's really no standard practices around how they're actually adopting that. So there's really a patchwork of AI tools that loo that leads to tool fragmentation. I come from the observability world. We saw this a lot as well. There's like a a highly variable amount of tools, for observability depending on the team and and a lot of the practices became non standard. And so as that that industry matured, we were able to see best practices emerge and we're seeing a very similar paradigm shift here with the adoption of AI. So, you know, to kick us off a little bit, Ganesh, was there anything in the report that surprised you from some of the percentages that were reported? I think the thing that surprised me the most is, such a close correlation between the velocity improvements and the instant increase. Like, it they're so tightly coupled in some way that it's it's very hard to argue that there isn't causation here to some degree. I mean, you could say, like, okay. Maybe AI adoption is correlated, but we're seeing very, very clearly in the data across, you know, tens of and and hundreds of organizations that it is very, very tightly correlated there. And so I think that was the thing that surprised me the most about that. Yeah. I do think though, AI has been pretty transformational. I mean, like, how quickly some of the things internally we've been able to spin up over the weekend. Like, you report, like, you just created a bunch of, Cortex on Cortex, you know, SLOs and and KPIs that we're tracking using our own scorecards just like something that you were able to put through Claude. Right? Like, that might have taken a lot more time. So there are a lot of benefits to AI. So it's it's like how do we maintain the productivity gains and reduce these incidents, reduce the regressions. And I guess I wanna kick off by saying to our audience, like, for this first poll, what's been your most valuable AI use case so far? And while we're waiting for those results, Ganesh, maybe you can talk a little bit about your favorite. Yeah. Absolutely. Like you mentioned, I think my favorite has been taking a lot of work that maybe would have been at the bottom of the priority list, but things are very important that we wanna do but don't do. And, like, this is your classic classic problems that maybe sometimes you're assigned to interns or you do at hackathons, but those things can be easily done in the evening. And so like you were mentioning earlier, one of the things that we've been talking about and trying to adopt more is getting more of our own metrics outside of Cortex into Cortex that we can use scorecards for it. And so this involved a lot of data munging and API wiring up. And so I was able to do a lot of that with Claude. I was using this library called superpowers, if you've heard of it. Really, really powerful set of skills. It's a plug in for Claude. Highly recommend it. But I was able to get it to hook up to LaunchDarkly and ingest feature flags and keep all that information up to date to parse out a Jococo test coverage report from XML, convert that into the right format, upload that to Cortex as custom metrics so I can track them over time. And it took me an evening to get all that stuff done, and this was a thing that was kind of a blocker for a while. And so finding these, like, high value but high toil type things has been really, really powerful. The other thing I would call out from our own internal teams has been debugging for for complex systems. Like, one of the things that's really good at is if you can export a heap dump from, like, the JVM, for example, piping that through cloud and using that to help you analyze large amounts of information about your about your deployments. Also, very good. So those are some things that we've we've been seeing are are very valuable use cases outside of, you know, writing code, of course. Well, it looks like a lot of people agree with you. Writing new code by far is the, number one favorite valuable AI use case. And in second place, it's documentation, which is interesting. I mean, especially Claude, I think is very good at documentation. They're like, the writing is pretty fantastic. And, you know, if you're short on technical writers, I think it's a great way to kind of input, you know, this is what I'm what I'm looking to describe. Put it in a way that's easy to read, and then it just like spits it out and then you can edit whatever you want. I agree with that. And then a couple people said, you know, one incident response vote and one other vote. I wonder what that other was. Alright. Back to the slides. So the security challenges related to AI adoption, you know, are by far the biggest concerns for engineering leaders. Right? 70% rank security and quality regressions as their top concerns. We are obviously in a period of time where security is becoming increasingly more important for all cost for all companies. I feel like every day I I learn that my data has been leaked to the dark by some random account that I opened maybe five years ago. And so the more that I can have trust in, you know, the the service the digital service providers, the more likely I am to continue to use those products. Right? And so, you know, it was really interesting to see that also secret data leaks concerns are also really high for engineering leaders. 45 said that they were concerned about this. And I would I would have thought more just from how often it occurs to me. But engineering engineering leaders also told us these fears are due to a couple of factors. Right? So like the tool fragmentation I I mentioned earlier, the use work of that patchwork of AI tools across an organization, it it multiplies security risk. Because then when there's no centralized governance over which tools can access sensitive code bases, and then if you don't have like policies in place that help design who and what can be accessed by these new tools, then you these traditional tools are not really these traditional policies, I should say, are not really built for the scale and scope at which AI coding tools now exist. So we need to almost rethink everything that we used to do. But at the core of it, I really think that it's the foundation that we need to just go back to. But it's it's about how do we evolve with these tools to reduce that incident, you know, percentage, reduce the regressions and still have those productivity gains. Anything here, you know, Ganesh, I know AI is not going anywhere. So figuring out how to navigate these challenges is kinda the focus of the rest of the webinar. But anything that surprised you here? Yeah. I think it's it's how early organizations are. I think one of the unique parts of this role is we get to work with a lot of customers across different industries and different scales. And I think what's really interesting is how varied the, the adoption of tools is, how how many tools are adopting. We work with some organizations who have selected a single vendor or have gone in all all in on it, and they have clear governance and things like that. We have worked with organizations who are still very much in the we're experimenting. You know, people can use whatever they want. We don't really have governance. And so I think I think that was really, really surprising given the scale of how much how much code we're producing as a result of AI. I do think everyone shares those concerns. Like you said, it was fairly consistent across the board. Like, 70% of engineering leaders agreeing with security and quality. It makes a lot of sense. And I think it's, you know, in the Dora report recently, we talked about, like, AI being an amplifier. Right? It makes your processes it just amplifies whatever you have today. So if you have issues with code quality, it'll probably make it worse because you're writing more code, and you don't have the frameworks to to to handle that. And so I think what we're seeing actually is, like, this poll is amplifying the concerns that people already had. People are already worried about security and and quality regressions, and it's getting worse because it's like, don't really understand my code. And so, yeah, I think, like, given that given that concern, it kind of aligns really well. Yeah. I also was interested to see that there's a worry that AI generated, you know, code or AI tooling for code leads to tech debt, or even a loss of, like, core software development, mentorship, and skill sets. Have you found that to be something that you're worried about? I find that it can also I I don't know if like, because I read a lot about, you know, engineering leadership perspectives on this even outside of the report. And a lot of people are like, you know, the foundations I learned in, you know, engineering school are still super relevant because I sometimes will be debugging the code that is generated. And so if I don't understand the underlying frameworks that are being applied or the the the logic that I've output using something like cursor or clod or another tool, I. I will just, you know, like, it's it's almost like I'm just vibe coding and pushing. to production rather really good. point. That. comes up a lot. And, you know, you see that here. Even 36% of folks are talking about loss of developer skills as, as a big concern. Think what's interesting, even within our own organization, we're we're seeing that, some of our most senior engineers are the ones who have been, like, driving, been the driving force for AI adoption. And I think it's because they're able to really, channel the power of their coding assistance towards the right things. Like, if you understand the root cause, like, people we I think most people have internalized this today. Right? The way you prompt things, the way you direct your AI is how you get value out of it. And so the more accurately you're able to send it down the right direction, the better value you're gonna get and the more results you're gonna get. So I think that's what we're seeing. I think the risk, though, is that if a lot of developers, especially early career developers, are writing a lot of their code with AI from the starting days, then it's, you know, are are those developers gonna learn the same skills that will, you know, help them get to that place where the senior developers are able to use AI? You know, you could argue that maybe the skill set is completely different in the future. Like, maybe maybe you don't need some of those same skills, but the ability to direct your AI, the ability to understand, like, underlying architecture and and stuff, I think, is gonna be more important than ever before. So I think, really, at the end the day, we're just adding a different tool to the to the toolkit. I think the other thing to to think about and one thing that I've heard here and know we're kind of digressing a little bit, but I think it's interesting on on this particular topic here about tech debt and developer skills and mentorship is this idea of, like, durable code. You know, in the past, because code was, like, one of the main outputs for most junior developers and most developers, like, a lot of code reviews was were focused on, like, the quality of the code, the structure, the readability, and so on. Now in the in the future where AI is writing more of our code, you could argue, like, does the readability matter, and does it always matter? And so one framework that we've heard before is, like, this idea of how durable is this code. Like, is this code that is gonna change really often? Like, is this some, you know, new feature that we build on the front end? We don't really know if it's gonna stick. You know? And maybe we're updating that UI so often that, like, actually, maybe it doesn't matter. Like, we're just using AI to write that code versus if you have a critical path piece of, infrastructure, like you have a background queue system, for example, where we run our scorecards, that is code that powers so much of the product. You really wanna understand that. You wanna make sure your developers understand it. You understand the architecture. The code is reviewed really well. And so thinking about kind of, like like like, tech debt the idea of tech debt is maybe evolving a little bit, and so I think that's something that's worth that's worth calling out. Yeah. And coding really has never build a build the bottleneck. There's a a comment in in the in the chat about that, and I'll actually talk about that a little bit more later in the webinar, how you should use that framing to think about your broader strategy around AI. So great call out. Awesome. Well, we got our second poll. Which of these foundations do you think is the most critical to amplify AI strengths? And say it's not going anywhere. You know, what can we do to improve? Alright. What do you think we should do to improve? What's the most important for you, Ganesh? Oh, I don't wanna, I don't wanna give away what I'm gonna talk about at the end of the webinar, but I do think clear ownership is where it starts. I am a strong believer in accountability, and, human accountability is where the puck stops. Well, I got news for you. If we were to show the results, They agree. 75% of people on the webinar agree with you. With secure coding practices and vulnerability management, you know, in line with the the engineering leaders in our report for sure. Alright. Let's go back to the slides. And a 100%, you know, it sounds like literally everyone can agree that security, testing discipline, and ownership clarity are requirements for safe AI scaling. Right? So that ownership piece, though, I really do wanna dive into. You know, there are but before we kinda get into that, I think it's important to kinda talk about four shifts that are happening in conjunction with the adoption of AI for coding practices. Yep. Ganesh, did you wanna talk a little bit about this? Yeah. Let me dive in here. So this is this is still a very early research that we're seeing in the market, but I think we were able to kind of bucket it into these four themes. The first one is around measuring the impact. And we're talking about measuring impact. It's not just on velocity. It's not just, like, ROI. I know there's a lot of talk about that in the industry, but I actually think it's by the impact on the outcomes. You know, one of the things, again, that we we we saw on the DORA report and by the way, if you're interested in in learning more about the DORA report and how to apply that, I highly check out suggest checking out my recent podcast episode with Nathan Harvey, who leads DORA at Google. Measuring AI impact doesn't actually really change much. Like, is you wanna look at your your standard DORA metrics. You know? Are are we how often are we deploying? But you wanna counterbalance that with things like MTTR. When things go wrong, are we able to recover from those issues quickly? It's it's interesting because MTTR actually really captures the essence of of the concerns that we have with AI, which is do we understand our code? Do we understand the failure modes? Like, are we are we ready to to mitigate issues when they arise? And so things like that can actually help you understand the impact of AI. So looking at your teams, looking at your application, and saying, are we seeing the impact not just on velocity but on the downstream effects of that? So I think that's one of the themes that we're saying. And another way to put this is, like, you can only improve what you measure. And so if you're not measuring things, how can you actually get the most out of AI? So that's kinda the first bucket that we're seeing. The second kinda category is moving away from just individual tools and integrated platforms. I think the the concern about having a hodgepodge of tools across the ecosystem maybe is even more amplified in an AI first world because as things are moving faster and the AI is an amplifier, the concern about having a variety of of individual tools increases risk across the board. And so moving towards more kind of consolidated platform, moving towards single tools or in the AI space, governance around LLMs and things like that are are becoming very important. I'll talk about that in a second. Specialized AI tools, I think this is really interesting. You know, at the beginning, we're a lot of talk a couple years ago was, hey. Are the foundation models gonna do everything? And the answer is is no. The foundation models are not everything. Actually, the application layer is very important because the more context you have, the better those application layer products can do. The more of a bounded problem space it is, the better those AI tools can do. And the best example of this is coding assistance. A coding assistant is a specialized AI tool. Right? It is a it is an it is a a capability where the bounded problem it is set out to solve is writing code. And you're providing a context through your code base and all the information that you have across your your repositories. It's trained on those particular types of things. The agents are focused on writing code. And so specialized AI tools are gonna be a big part of the future in 2026. And I think it's because although reasoning models are getting better and, you know, even models like Opus are getting better, the more bounded the problem is and the more specific context you can provide an LLM, the better it is at solving those tools. And so I think we're gonna see an increase in specialized tools and specialized context layers and semantic data for those, those AI tools. But, finally, the thing that we've been talking about a lot, and we came up in the poll as well, is governance automation. The thing that, you know, we see a lot in the enterprise, especially in in the current state, is a lot of governance is actually calcified human in the loop processes. Right? I I like to think about process as actually or governance as not you know, governance for the sake of things. Usually, there there was a thing that happened in the past that you were trying to prevent or there's a regulation that's that's important and you're trying to put in guardrails in place where you you don't wanna make sure that humans in the loop are not making mistakes. That's generally what governance is. Right? When you think about even something like production readiness. Right? It's, hey. We know we've seen a failure mode in the past where somebody deployed a service, and they didn't have a latency monitor. And it turns out that latency is spiked, and that caused an outage. It caused an incident. And going forward, we wanna enforce that every single every single service has that. And so how do you do that at scale? You wanna do automation. And so we're kinda seeing some of these themes around automation. I'm gonna dive into the details about this, coming up here in in a few minutes, but these are kind of the broad themes that we're seeing across, across the board. Awesome. Thanks, Ganesh. I guess, yeah, let's think about how do we think how should we be thinking about governance governance? Where do we start? And, you know, I think the report mentioned that only 32% of engineering leaders report having some formal AI usage policy. Was that surprising to you, Ganesh? No. Not at all. Okay. I mean, in our in our own customer advisory board, this is exactly what we what we heard, and our customer advisory board is made of some of the most recognizable logos in in the world, and, you know, organizations that you would consider are the cutting edge of software engineering. That's exactly what heard heard in our own customer advisory board is. There's some organizations that have formal policies and performance with enforcement, and some most of them are are very, very early. It's we talk about Vibe coding. I think it's kinda like Vibe governance. You know, it's what we feel. It's very, very early. That that's kind of what we're seeing in the market right now. So it's still very early there. Vibe governance. I feel like we should we should trademark that. But I think. I mean Vibe governance, please. okay. If I Okay. if you if you take one thing away from this webinar, don't do bipvernance, and do bad about. why. I think almost a third though of these organizations already having formal policies with enforcement. That's pretty good. Maybe we should, like I think it's pretty correlated with with, with highly regulated industries. Folks who have governance in their DNA for a variety of reasons because they're working with highly regulated data with with, sensitive data or sensitive industries, like those that are in public markets and things like that, those companies have governance in their DNA. And in fact, one of the things we heard is that some of these companies that have formal policies and enforcement actually jumped the gun. Their lawyers were thinking about AI before their developers were thinking about AI, and so they put in governance in place before they even knew what the impacts were. And so I don't know if if that's the right way of doing things either, and we'll talk about why. But, yeah, there there are some organizations that are that are ahead of the curve, if you will, when it comes to governance. I agree with you about highly regulated industries. I also completely agree with you. Large companies that have, like, huge staffs of lawyers are definitely at the forefront. I I before joining Cortex, I was at a very large, like, 90,000 person company. And before we were allowed to use any AI tooling, they had already created an internal, like, basically foundational model that you could only use. But once you used it, and it was pretty good, we basically licensed foundational models and you got to select which one you wanted to use, you could input any document from like, any company, like, work related document you could use with this tool. And so and that was a year and a half ago. So I find that you're absolutely right. The legal profession becomes really important. Compliance teams become really, really important. And large companies have those kind of on lock. And so they're gonna get maybe a little bit of a jump on some of these important, like but and necessary, but almost blocking elements. I I think for a smaller company to build that muscle of compliance, build that muscle of enforcement is almost like antithetical to how nimble and agile smaller companies are because they're not blocked by those typically. Right? But I think that the paradigm is shifting quite a bit because the risk might be too high. So with that, we have our third poll, our third and final poll. Does your company have formal AI governance policies in place? I guess it depends on who's here. So as we wait. for that to go. in, let's see. I'll give it a couple seconds. I'm seeing them coming in. Looks like it's a little bit all over the map. So two or, you know, or 33% oh, going down. We're going down. So, you know, 28 per oh, here we go. We're we're it's changing by the by the minute. We it's seemingly like most or like a little more than half have well defined and enforced standards. So I guess, like, if we have or 30%. Here we go. And then some are in progress. That makes sense. And then some are informal or none yet. So it's almost like a third, a third, a third. Yes. Well defined, a third in progress, and a third not really there yet, which I think is pretty in line with the report. So alright. Ganesh, I would love you to bring us home a little bit and trying to explain, like, how can we prepare for these governance practices that are absolutely necessary to get back to the high quality, the productivity and and really, you know, benefit from the productivity gains. Like, how can we get back there with. these new it's a it's a great question, and I I think it's probably why a lot of folks, are attending this webinar is to figure out, okay. What should we do about this? And I like I like to think about it from first principles. Right? Like, what are what are what are the things that we're concerned about? Why are we concerned about those things? And then how do we keep it in check? Right? So we talked about what we're concerned about, and we know that's things like, security issues. It's it's testing. It's regressions and quality. Those are the things that most engineering leaders are concerned about, including the folks here on the webinar like we saw in the polls. If you take the take a step back and say, okay. Why are we concerned about these things? Like, what is the point? Like, why are we so concerned about quality regressions? It's because at the end of the day, what we care about is customer impact. Right? Like, that is that is the reason we're building software. It's to deliver some sort of value to our customers. And so the more we introduce, security regressions and quality regressions, that affects the customer. Say, okay. Well, let's take the assumption that now AI is accelerating how much code we write. And the reality of it is, yes, we are going to understand less of it. It it's it's fool's errand to try to assume that, and we are going to understand all of our code. Like, the reality of it is it's not gonna be true in the future. Right? We're we're we know that it's happening faster than we can realize. So if that's the assumption that we're going in with, I think about, okay. Well, then what are the systems that we have in place to help us capture the impact on customers? And how do we how do we create the right guardrails for AI to work? And so when we think about that, the idea is about confidence. Right? When you think about the DORA metrics, really, DORA metrics help you capture confidence. Is my team confident in shipping? Is my team confident when something goes wrong, we're able to negate that? Let's talk from from from the very top here. Code quality and testing practices. Right? If your developers or your product teams are thinking about new capabilities, we've been talking about test driven development for a very long time. But, actually, that's one of the first things you should be thinking about now in AI first world. Because if you can codify the things that your coach should be doing, right, if you if you if you think about the expected paths, the unhappy paths, the the best practices, if you codify all those things, it gives your agents more room to go and iterate. Right? Like, if you've seen Cloud Code, like the Ralph Wiggums loop or superpowers or whatnot, it's able to kinda go and continuously work in a loop and run tests and look at failures and go back and fix your code and so on. Like, that's the future of agentic software development. And in order to enable that, the more tests you have, the more humans are writing tests or or or coaching their AI to write tests, the more your agents can go off and and kind of iterate in that loop. So it'll actually help you get faster, but it'll help you prevent those regressions as well. There's less room for AI to make mistakes. The second thing is about monitors. If we're saying monitors and SLOs. Right? It's about, okay. Well, maybe we don't understand we don't understand all the code we're deploying. But as humans, we should think about the failure modes. What are the things that can happen to our customers? So let's think about, like, a payment system, for example. It's a very sensitive thing. You wanna make sure that payments are are are are happening successfully if you're, like, a a retailer, for example. Like, what is the failure rate of of of payments? And so okay. Maybe maybe your AI coding assistants are writing more code in your payment system, you understand less of that. But you can keep that in check on the other side. Right? You can define SLOs like, hey. 99.99% of payments should succeed within three seconds, or, hey. Our monitors are gonna be around payment latency. So you're you're thinking about the customer impact. What does the customer care about? If And you can put those guardrails guardrails in place, it'll actually give you a breakpoint to say, hey. You know what? Yes. We're focused on moving fast, but the contract that we've defined with our customer is actually falling apart. And so now we should stop. We should slow down and go back and get the right things in order. We should go back and write our tests. We should go back and fix the underlying issues. And so the the things that we've been doing for a very long time around SLOs and monitors are actually more important now than ever before because they are the final gate. Right? If we don't understand what AI is doing, it's the final it's the final gate at the very end. I I see a question here. I'll talk about that in a second. Like, AI generating code that developers don't understand, and why are we accepting that as an on statement? It's a it's an interesting point, and I think what's gonna happen over time is organizations, for better or worse, I think some organizations will still have a human in the loop. But I think what's gonna happen over time is in the market, in a macro lens, there's gonna be there's gonna be more pressure to move fast from from leadership, from the market, from shareholders. Like, I think that's, like, the reality we see in the market, and I think we're gonna start seeing processes where, you wanna automate some of those checks. Right? Right now, the way we're we're guardrails that is we're doing things like code reviews. Right? Humans are in the loop. They're doing code reviews. Your senior developers are kind of being that choke point. And, eventually, you'll say, hey. Actually, maybe for low risk PRs, we're gonna have AI doing some code reviews, and that's gonna be kind of, you know, the first gate. So I think over time, we're gonna see a little bit of a degradation. And the reason I feel so strongly about this is we already know that in in organizations with microservices and things like that, eventually, tech debt grows and, like, context dissipates. Right? Like, we talk about tribal knowledge and tribal knowledge being, like, humans having knowledge in their own minds, and then they leave the organization or, you know, they they switch teams and that that knowledge is lost. I think that's gonna accelerate. Like, even if you have a human in a loop that, like, generally understands our code, that context is gonna dissipate faster because of AI taking a little bit more of that cognitive doing a little bit more of that cognitive work. And so I think that's why we're gonna see, like, a faster degradation of context and a faster increase in tribal knowledge and that dissipation. So that's kinda how I think about it. And so that's where, like, I think about the first principles that can help you keep that in check. And so security practices, like, are you making sure that every repo is tracked and monitored? Like, you you know, these things are not things where, like, security teams can be your final final guardrails. Right? We've seen a lot of organizations. You have security teams that are, like, you know, filing tickets against Teams and saying like, hey. You have vulnerabilities here, or you have issues in your in your repository, or we're gonna do a security review before you ship some software software out. And I think those kind of manual guardrails are gonna get harder and harder to advocate for in the future, to be honest. And so the more you can automate, the more you can shift left, the the more you're gonna able to move fast with AI agents. And then finally, clear and up to date ownership, human accountability. And to the question in the chat, I think this is important. I think at the end of the day, the way to keep this in check, the way to make sure that we do understand more of our code, the way to make sure that our customers are not being impacted is by driving human accountability. You have to be able to define a a a choke point, a single accountable party, whether it's a team, individual at at the software layer to say that, hey. We actually don't care who writes your code, but you as a team are accountable for the customers, the outcomes, the vulnerabilities, the code quality at the end of the day. So I think that's that's where it comes at the end of the day is, like, no matter who's writing code, you have a human accountable choke point. And it's up to that team how they how they define some of these things. And so I like to think about these things as guardrails. Right? Like, over time, the amount of software writing is exploding. And so the more accountability you have, the more you think about these first principles, the more you're you're gonna be able to move fast, but keep quality in order as well. And for what it's worth, I think the DORA 2025 report actually emphasizes this. Right? We talk about focus on the fundamentals because AI is an amplifier. AI is gonna amplify the things that you do really well and the things that you do don't do so well. So for example, if you have a really great code review process today, hey. You're writing more code? That's gonna shine. Right? If that's your strength, you're gonna be able to get more code through that bottleneck than than other organizations where maybe if you're an organization where reviews are the bottleneck, you're writing 20% more PRs like we saw in the data. You have 20% more of a bottleneck now in your code review process, and so it's actually amplifying those things. Or if you have a quality problem and you're shipping regressions all the time, you're shipping more regressions. You're shipping more you're shipping more regressions. And so, like, AI is an amplifier. So if you focus on the fundamentals, you're gonna be able to keep those things in check. So that's why I think about it like, okay. What are the fundamentals? What are the guardrails that you can keep on both sides of the equation? Writing code, the inner loop, the outer loop, and I think those are the things that'll help us deal with AI and the amplifiers in a in a much more kinda structured way. So, again, highly recommend thinking about the DORA, the report. I think they do a great job about talking about this and thinking about capabilities as well. So I think I would talk about that. Ganesh, one thing I'll mention also around the human accountability is that, you know, there's also a junior developer risk. Right? Like, you know, an increasing reliance on code generated by AI tools. It's kinda like even for the liberal arts where kids are not used to having to write the five paragraph, you know, standard essay anymore. Like, they can just prompt something in Claude or Gemini or Chateappiti, get an entire history of the French revolution written for them, and then they can just submit it. And that's why there's so much, like, panic in academia right now about how these tools are impacting cognition and comprehension and thinking for oneself rather than relying on, you know, somebody else to write something for you. It's like we're losing the ability to write. And I think of code as a language as well. Like, of course, right? Like Like the the it's the entry level folks that are coming in that potentially, if we're not continuing to teach the fundamentals and really stress how important it is to think critically about a problem and how would I address that myself. And then augmenting that with code, I think is like a beautiful evolution to become more productive. But I think the fundamentals even in the way we teach, the way we learn needs to be preserved. Right? Yeah. It's a great point, and it kinda goes back to the earlier thing we're talking about, which is mentorship and kind of helping developers learn those skills, being a potential, you know, way this degrades. And so I think that, yeah, absolutely, is super, super important. And to to to another point in the chat, actually, very, very important. It is very important than than ever before that you document and automate your controls. Documentation is not enough. Because even as we know in the past, as a velocity of an organization, increases, it is very hard to keep those guardrails in place. And so automation is one of the only ways that you can actually enforce things at scale. Right? When we think about production readiness, we, you know, we think about we work with a lot of organizations that are in the ecommerce space, and one of the biggest moments of their year is Black Friday and Cyber Monday. So you're talking about hundreds of teams and thousands of services and and software components. If you're thinking about just documenting on a Confluence page, hey. Here's all the things that we should do get ready for Black Friday. It's gonna it's gonna be bad. And so a way a lot of those organizations get around it is they automate it. They say, hey. We're gonna automate checking every single software component against a set of requirements that we know are gonna help us have a better Black Friday or Cyber Monday. And so if you can do the same thing when it comes to AI, that's gonna help you move faster. And so, you know, making those AI readable and making those documented, I think, is very, very important. And I think, you know, one of the things to call out here, code quality and testing practices, that is an example of documenting and automating your controls. Right? If you can define your happy path, your unhappy path, the edge cases, that is automating best practices. Right? And this is this is maybe a little bit tongue in cheek. But you think about, like, the the code quality and and the guardrails for the code level, that is what code that that is what testing is. And so I think that is really, really important. And so, you know, there's a couple of comments in here about policy and code and, you know, how to automate governance. And, you know, I wouldn't be the founder of Cortex if I didn't tell you how Cortex can help you some with some of these things. So with that said, we can we can jump forward and talk a little bit about how do we help? Like, this is something that we talk we we think about a lot. This is where we're actually working with a lot of our customers, to enforce these kinds of things at scale. What's really and really interesting is actually we we noticed some of our customers were already using Cortex for AI governance before we even started talking about this, which is which is really cool, and I think it's what that's that's what excites me a lot. And so let's talk about that a little bit more. Just two more slides here talking about how Cortex can help and how we can automate this because that's what we care about at the end of the day. So I wanna start at the very top. I just wanna summarize the challenges very quickly that that we talked about here in the webinar. Number one, we know that the volume of AI generated code is increasing exponentially. We're moving faster. We're shipping more. The volume of code is increasing. If any of you guys have used, something like Claude, you you guys have seen the type of code that Claude's write, or these AI assistants write. It is, it is much more verbose, if you will, than what humans might write in a lot of cases. But the volume of code is rising, but at the same time, we have unclear human accountability. This is one of the things that we see in the market to this day is a lot of organizations still struggle with ownership and ownership of services and code, and it's only getting worse as the volume of code is increasing. So that is getting compounded. The corollary to that is if the volume of code is increasing and you have unclear human accountability, then governance becomes impossible. You don't know who to hold accountable. You have more and more code to keep track of. You have more services to keep track of. And so the reliability governance, AI governance is getting just harder and harder, and eventually, it becomes a flywheel effect. And then finally, if we know that, well, governance is getting harder, reliable reliability governance is getting harder, we also know that the difficulty in measuring that impact is leading to shooting from the hip. So rather than saying, hey. We know that this is the bottleneck in this part of our SDLC. You're like, oh, well, you know, we should govern this thing, and we should govern this thing, and maybe this is the problem. And so a lot of organizations are kinda shooting from the hip to try and get ahead of this rather than making targeted improvements. And so this is the set of challenges that we're seeing across the board in the market. So how can Cortex help you drive reliability in the age of AI? Well, number one, the volume of code is increasing exponentially. So Cortex released a new capability at the end of last year called Magellan, which uses AI and machine learning to map your entire software ecosystem. So can we automatically define accountable owners for every repo? So for those of you that are using Cortex today, you've probably seen this in the application today, but you can actually go and see our model's predictions for every single repository. We will tell you based off of data that we have about that repository exactly which teams that we think are accountable for that repo. And so this is a very easy way of keeping accountability at scale and catching that drift over time. And so if we know AI is the problem, why not use AI to try and solve the problem? Because that's where we're applying AI in the first place. The second way we help is if we know that governance becomes impossible at scale, the the comments in the chat about, you know, how do you document and automate your controls, how do you do policy as code, that is exactly what Cortex does. So Cortex scorecards allow you to define best practices and standards and codify them and apply them across your entire software ecosystem at scale. So whether that's AI governance policies, whether that's production readiness standards, that's reliability standards, operational excellence standards, you can enforce those things across thousands of repos, and we provide out of the box reporting and action items. So let's kinda tie in how those things work together. If Cortex can help you define accountable owners for every single repo, and then if we can help you define and enforce policies across every single repository, we can actually automatically assign action items to the right team. So we can say, hey, Kara. You are the owner of four teams that don't have automated vulnerability scanning enabled for your repos, and now you are not in compliance with our, security standards for AI adoption. So, therefore, your team doesn't have access to AI tools. And so you're actually able to define those kinds of things automatically and enforce those across organizations and see which which which teams and products are falling behind. And what's really cool here, actually, that I'll call out based on one of the comments here is you can actually export the stuff through our MCP. So if you take these scorecards and you apply them through MCP in your coding assistance, you can actually have your code review processes look up your policies and best practices from Cortex using our MCP and review your code based off those best practices. And so we actually work with a large a company in the semi semiconductor space that you probably know that is using Cortex in that critical path to rightsize their compute and apply AI govern security governance at scale using our MCP directly inside of GitHub Copilot. So that's a really powerful way of driving adoption of those best practices at scale directly within the IDE. And, finally, we talked about difficulty in measuring impact leads to shooting from the hip. So Cortex is actually, the only platform that gives you access to engineering intelligence out of the box. And so it is built into the product where you can measure velocity velocity, reliability, quality across teams, across products, across verticals, and correlate that with AI adoptions. You can actually see, it's our teams that are adopting AI actually are having are they moving faster? Are they having more incidents, fewer incidents? What is the impact at scale? And then being able to make very targeted improvements around that. So if you see, for example, that your teams are actually, you know, the the quality is going down across teams, you go back in the scorecard and say, hey. Actually, we wanna enforce in our production readiness requirements that every single service has a has an 80% code quality code coverage standard before you go to production. So you can make very targeted improvements and automatically enforce that across your entire software ecosystem, so it creates a flywheel effect. So just summarizing that very quickly, using AI and ML to map your software ecosystem and predict accountability and human accountability across every single repo, then using scorecards to codify best practices, apply those at scale, find the gaps, drive action items accountability, and then finally measure the actual impact of those things across the ecosystem and see, are the improvements we're making having an impact? Is AI having an impact? And where do we wanna go and improve? And that's how Cortex, helps you drive those at scale. And that is kind of how Cortex helps. Happy to answer questions. I know we have some questions in the q and a, and there's one question about Magellan as well. Today, you can actually see if you go to tools and you go to the ownership report, you should see our ownership predictions within that bucket there. And so you can actually see for repos without owners, you'll see our predictions for for ownership and some more to come there. If you have questions about that, happy to take that offline and and help you get some of that data in your workspace. Yeah. There was another great question just about the the report itself around how many companies participated in the for the benchmark data also by size. So the answer to that is more than 80 companies with at least a 100 engineers in them participated in the study. And so you can imagine, you know, it's it's a normal distribution out of those 80 plus companies. But at least a 100 engineers had to be in the organization to be pulled for this report. Yeah. It used anonymous anonymized data from, from the Cortex ecosystem as well. So we're able to kinda. correlate the survey results with actual raw data as well. And most of our customers have at least a 100 engineers as well. Yep. Another another awesome question. If I have only fifteen minutes a day to dedicate to AI excellence, what is the one highest leverage thing I should do? I feel like we might have two, different answers to this. Ganesh Datta, you wanna go first? yeah. I would say focus on ownership. And if you're if you're a Cortex customer, Cortex can automate that for you with our ML. But if not, if you don't know who owns a piece owns a repository, a piece of code, none of this stuff matters. You can govern all the things you want, but governance then just kinda become shouting into the void. You're like, this repo has too many vulnerabilities. Like, okay. Well, do we know who owns it? Nope. Alright. Well, nobody's gonna fix it. You know, it's kinda like the bystander effect. You know, we talked about that. Like, oh, somebody should call 911. It's like, well, if you don't point at somebody and say, Kara, you should call 911, nothing ever happens. And so that's what I think about, like, ownership is the number one thing you have to solve to get any sort of value out of governance. I think, you know, coming from a non engineering role, my answer would be try to train, like, a foundational model on your own your own previously written output to basically fast track rote tasks. We had, like, a really interesting, demo that one of, like, our go to market per people did where he created basically, like, a an individual GPT where, you know, for outreach, he was able to expedite his productivity significantly because he had taken a bunch of things he had written previously. And so the model was then able to read it, write it for him in his voice, and then become, you know, x percentage more productive. And so he could focus on things that were maybe a more high high impact on the go to market side. So for for smaller things like that, using AI to really it's deterministic and it's it's using if you're able to train the data with as much context as possible, then you're able to kind of, like, automate a lot of things that might have taken you a really long time that shouldn't take you a long time so that you have leverage to really spend that on higher value tasks throughout the day. And I think more time for strategy, more time for refinement, I think, is always good. So for. for non engineering roles, I think that's really important as well. I think the next question here, the key tool or use case you see bringing more value and more trouble to those companies. Obviously, I'm biased. I think our customers would say Cortex is a big part of their, yeah, governance and reliability practices. But if I had to pick something else, one of the things that, you know, came up in our own customer advisory board as, like, one of the capabilities a lot of folks are adopting would be, like, LLM gateways or MCP gateways, at the enterprise layer. I think that's been a really interesting, tool chain to being able to apply token restrictions, like how much capacity you can use applying MCP, governance, things like that, I think, has been, really powerful. So, if, you know, if you have, any sort of blockers that are getting in the way of adopting MCP servers and things like that, I would focus on on solving those things. Other than that, I would say maybe investments in in CI, honestly, because the the volume of coder writing, one of the biggest bottlenecks that we see in organizations is bad CI, like slow bills, flaky tasks, things like that. And so investments in those areas, I think we've seen a lot of a lot of value as well. But, obviously, if I had to pick one, I would pick pick Cortex. Let's see. We have a couple more questions. Who in the organization's own governance if you don't have an official compliance or legal team? That is a great question. I actually think that for most organizations, you don't want your AI governance to start from compliance or legal. You wanna start from the customer mindset. Actually, there's a I I just did a podcast episode with, Fred Meyer, who's a principal software engineer at Xero, who runs a production readiness and confidence score program. And we talked a lot about, like, how do you think about production readiness and governance for these kinds of things. And the really interesting quote, I I highly recommend you check out that episode, is to think about to think about the customer first. Right? Like, the whole point of all of this, like we were talking about earlier from first principles, is thinking about the customer. And so it's like, okay. Well, who within the organization is accountable for for the customer outcomes? And so, generally, I would think the the folks that think about that are teams like SRE. Right? Because SREs own reliability, when it comes and reliability managed with the customer. Right? And so SRE teams are great are are great source of of thoughts and and thought leadership around reliability governance. I would also think about security teams. Security should probably be a part of this. And then, generally, platform engineering can be another owner because if they're kind of the bottleneck or the choke point for getting access to AI tools and things like that, they probably have a set of concerns around driving adoption for that. And so I think that's probably another group. And so I think those are probably, like, the core teams that I would think about. So SRE, security, and then platform are probably the three groups that should be driving your compliance and governance policies because they're the ones that kinda thinking about the customers the most. Do we wanna take another last question, or do we wanna I think we do. Yeah. yeah. I also in the chat, you know, the self organizing teams comment, I think, is brilliant. I think that tiger teams around important initiatives including, you know, compliance and governance is absolutely especially if it's cross functional. Right? Like, there's an element of, like, presales sometimes where you need to, you know, respond to an RFP where they're asking you in a highly regulated industry what your policies look like. Right? So what are the what are the things you need to account for for RFPs? What are the things you need to account for in your own usage of AI coding tools? How do you be compliant with different government regulations if you operate in internationally? There are all sorts of perspectives on a multi disciplinary tiger team. I think that, you know, if you're self organizing when you have a particular need, super, super impactful. It's something that we do internally at Cortex as well. And then. there was one directed at me. Let me share it real quick. I was gonna, quickly add. something that, yeah. I think, actually, like, one of the really, really important things about, governance is it cannot come just from the top down. So actually having self organizing teams of of folks that care about this kind of thing can actually drive adoption of AI governance because it's more of a bottoms up thing. One of the best ways to drive adoption of best practices is to come up with a set of standards that everyone can kinda agree on. Like, hey. These are these are things that we can all agree are good. Like, these are good things for our end users, whatever. And so it's a shared language of what good looks like. And so that can be through governance panel. It can be through kinda self organizing team. That's a great take from the chat. I I would highly take a recommend taking a look at the talk from Skyscanner at, IDP Con last year, which is on YouTube. They actually did a great talk about how to drive adoption of scorecards and best practices at scale across an organization. Really, really interesting talk about how they have evolved their governance around governance over time because you wanna give teams the flexibility to move and drive new best practices, but at the same time, you don't wanna overload teams with, oh, there's 15, types of compliance and governance. And so, actually, those are really, really great, learnings from that talk. So I highly recommend taking a look at that. And, yes, we will be sharing the recording afterwards. We'll follow-up there. I know we're we're out of time here. We have a couple minutes left, and I wanted to quickly call out. I know this is something that I'm really, really passionate about. I know a lot of folks here have questions as well. I would love to offer up my own calendar here for a one on one session. So for those of you who are on and still on this webinar, I would take highly suggest booking a session with me. There's other stuff you would like to tech chat about, happy to tech talk about anything. I get to to see this across industries, across across the globe, across different company sizes. So whether you are a engineering leader at a company with 50 engineers or thousands of engineers, I've gotten to see see it all in in this role, which is really, really cool. So happy to talk all things production readiness, seasonal readiness, live event readiness, AI adoption, AI governance, best practices around that kind of thing. So take a look at the link here. Feel free to book a one on one session with me. I have a ton of availabilities that I've put in there, but if not, feel free to shoot me an email as well at Ganesh@Cortex.io. Happy to set up some time to chat and definitely take a look at the podcast as well. Lots of cool learnings from some top engineering leaders. The podcast is called Brain Trust by Cortex. You can find it where all major podcasts are distributed. Also under the docs tab, you'll be able to download the ungated version of the engineering report that we talked about today. And thank you. We had a great time discussing the report with you. Thanks for all the great engagement and the questions. If you have any follow ups, please book a session with Ganesh or feel free to connect with me on LinkedIn as well. Thank you, everyone. Hope you had a great time. Thank you.