Doing AI Is Easy. Doing It Well Is Hard.

AI has made writing code dramatically easier.

Building great software is another story.

Recorded live at Cisco Live, Raj Chopra, Cisco's Chief Product Officer for Security, joins WWT's Brian Ortbals and Joe Berger to explore what it really takes to become an AI-native organization. As AI changes the way software gets built, engineering becomes less about producing code and more about solving meaningful problems, applying domain expertise, and creating the right guardrails for systems that can reason and act on their own.

This isn't just a conversation about AI-assisted development. It's about how organizations, teams, and leaders need to rethink the way they build, secure, and scale software in the years ahead.

When code becomes cheap, judgment becomes the competitive advantage.

Support for this episode provided by: Cognition

More about this week's guests:

Raj Chopra is Senior Vice President and Chief Product Officer for Cisco Security, where he leads product strategy across Cisco's security portfolio. A cybersecurity industry veteran, Raj previously held leadership roles at Proofpoint and was part of the founding team at Netskope, helping pioneer the Cloud Access Security Broker (CASB) category. Throughout his career, he has launched market-leading security products used by enterprises around the world.

Brian Ortbals is Senior Vice President of Global Solutions and Architecture at WWT, where he leads teams spanning AI, cybersecurity, cloud, infrastructure, and digital transformation. Since joining WWT in 1999, Brian has helped shape many of the company's technology initiatives, including the growth of its Advanced Technology Center. He works closely with customers to solve complex technology challenges and accelerate enterprise AI adoption.

Joe Berger leads WWT's Digital Experiences practice, helping organizations transform how people work, build, and interact with technology through AI. His team focuses on AI-native engineering, employee and customer experience, application development, and data platforms. A recognized technology leader and speaker, Joe works closely with leading partners including Microsoft, Cisco, NVIDIA, and Glean to help enterprises turn AI into measurable business outcomes.

The AI Proving Ground Podcast leverages the deep AI technical and business expertise from within World Wide Technology's one-of-a-kind AI Proving Ground, which provides unrivaled access to the world's leading AI technologies. This unique lab environment accelerates your ability to learn about, test, train and implement AI solutions. 

Learn more about WWT's AI Proving Ground.

The AI Proving Ground is a composable lab environment that features the latest high-performance infrastructure and reference architectures from the world's leading AI companies, such as NVIDIA, Cisco, Dell, F5, AMD, Intel and others.

Developed within our Advanced Technology Center (ATC), this one-of-a-kind lab environment empowers IT teams to evaluate and test AI infrastructure, software and solutions for efficacy, scalability and flexibility — all under one roof. The AI Proving Ground provides visibility into data flows across the entire development pipeline, enabling more informed decision-making while safeguarding production environments. 

Transcript

Doing AI Is Easy. Doing It Well Is Hard.

SPEAKER_03 0:00

One of my uh engineering leaders, uh, she says, and it's very, very true, doing AI is easy. Doing AI well is a lot of hard work.

SPEAKER_00 0:13

Doing AI is easy. Doing AI well is hard work. That may be the clearest description yet for where enterprise AI stands today. Because the tools can already write code, build prototypes, and compress weeks of work into just hours. But becoming AI native requires much more than handing employees a coding assistant. It changes who can build, how teams organize, how quickly ideas reach production, and how much risk an organization can create before anyone realizes what happened. So on today's episode of the AI Proving Ground Podcast, we'll be talking with Raj Chopra, Cisco's Chief Product Officer for Security, and two AI leaders here at WWT, Brian Orbald and Joe Berger, about why when code becomes cheap, the scarce resource is no longer the ability to produce it. It's the judgment to decide what should be built, the domain expertise to make it useful, and the governance to keep it all secure. We recorded this episode live on the show floor at Cisco Live. And throughout the conversation, Raj, Brian, and Joe explore what separates organizations merely using AI from those genuinely changing how they operate, and what happens when autonomous agents can reason, access enterprise systems, and take action on their own. So let's get to it.

AI Doesn't Just Change Developers

SPEAKER_01 1:48

Oh my gosh, yeah. I would say over the past, yeah, over the past six to 12 months, we've just seen a huge uptick. I think if you start looking at a lot of the different use cases of AI that people have developing over the past few years, they really honed in on coding assistance because you were able to see immediate impact within your organization. And I think we're at that point now where a lot of companies have adopted these tools. Now it's around how does this actually change my organization? It's not just I have people using the tools, but how does it change my software development lifecycle? How do I start shipping code quicker? How do I test for bugs faster? I know we're going to get into security talk here in a little bit, but it's really creating this big momentum for the software development team. And as well, you're even seeing it make its way into sort of your everyday knowledge worker in terms of low-code tools and now everyone can start developing really quickly. So just tremendous opportunity out there that I think a lot of organizations are, they've already been using it or they're kicking the tires on, at least for sure.

SPEAKER_00 2:47

Yeah, and Brian, I mean, he's talking about how it's changing not just the developer teams, it's it's changing the whole course of an organization. What are you seeing in terms of implications of AI native engineering and what it means for an organization, not just from a development standpoint, but infrastructure and policy and things like that?

SPEAKER_02 3:03

Uh, you know, first thought that I have before infrastructure and policy is just the impact to Joe's point on the on the workforce. So you start seeing the tipping point from AI native engineering into workforce AI, and you've got the the entire workforce has the ability to do things that were never possible for them before. And I think that's what ultimately has a consequence on behalf of B infrastructure policy, the way you architect things to Raj's point, like everything's changing. The problems of yesterday are not the problems of tomorrow. And so we have to solve things in a very different manner now. And that is just like we've gone through over the last 25 years, it's another iteration of this requires new ways of thinking about infrastructure design. You're you're accounting for ways in which you have to connect systems in a different manner, which ultimately requires how you secure them and in just a new frame of mind, new mindset. So I'm I'm excited about the fact that we've got this ability to go create new experiences for our user base, but it's also incumbent upon us to make sure that we are empowering them in a way that's responsible, it has an ability to scale and provides a delightful experience for them.

SPEAKER_03 4:08

Certainly a great segue into Raj. Yeah, go ahead. I mean, hopefully this is not a hot take anymore, but AI is exceptionally good at doing hard things. Right. For a long period of time, people have this notion, which is like, okay, we'll use AI for as an assistant or so on and so forth. Hopefully, again, one more time, this is not like I'm not blowing anybody's mind off. AI is very, very good at doing hard things. So the real question comes: do you have people that have agency to really challenge what are the big things to do? Right? If writing code is essentially free, what are the big problems to solve? And what we are finding from our developer experience is that people have so many high-quality problems to solve that you should expect not just the professional skill set, but the cultural mindset to shift to people who have a lot of agency. I think the distance between the end customer and the developer is gonna shrink. The surface areas on which people interact are going to change. The way uh vendors like us enable partners like you all is going to change. It is not gonna be the usual lecture, and here's the document, and so on and so forth. But every aspect when you lay it down, think of the hardest problems. Those are the first ones that AI is solving, and that is culturally changing the composition of the team, not just skill-wise.

The New Skill Is Agency

SPEAKER_00 5:38

Okay, so the tools exist, the capability is there, but the shift from using AI to write code to being the kind of organization that's actually AI native, that's a cultural change as much as a technical one. And it doesn't happen by accident.

SPEAKER_01 5:51

Yeah, hey Raj to that point, are you noticing because obviously, as as developers move from sort of writing code to now being the orchestrator of stories and a building, are you seeing that shift within Cisco? And is it also is it kind of challenging the mindset of the engineer of like my job yesterday was this, I now have to go think like this, and it's different. I mean, there's a shift happening.

SPEAKER_03 6:18

It definitely is, and I think these shifts are those of mindsets, not of titles. So most people now in the team should think of themselves as member, member of technical stuff. Yeah, right. Yeah, it is not like you are a developer, you are an you are not a developer, you are a QA, you are a PM, you're a designer, what have you. But it really is you're a member of the technical stuff. And that technical stuff gets applied to all sorts of different kinds of problems. It truly is where you're thinking about how exactly should we solve the most urgent, the biggest problems, and then have the empowerment to go solve it because the cost of failure of trying something and failing at it is small. Oh, yeah. So if the cost of failure is small, what else would you try? I think that's the mindset. So it's I think the org structure is evolving more organically than you would think. It is mission-oriented, it is those who take agency, it's where their job becomes more about collapsing whatever the inefficiencies are rather than being told, go do this, go do that.

SPEAKER_01 7:30

And let me ask you, because I know Cisco's got a very large development organization, what did you all do to enable this? Was it training programs? Or is it, hey, get the tools in everyone's hand, let them try it out? Like how how did you get over this adoption curve?

SPEAKER_03 7:45

I think the most effective way that we did, and a bunch of those things were tried and still are tried. I think, first of all, making these tools available for people to experiment and sometimes fail. I mean, that's totally okay. But really, availability of the tools is very, very important. The the two big things I would say is expressing the mission of the company in uncomplicated words. Very, very important. And then second is driving the lived experience of urgency. There is no time to waste. Again, one more time. This is not about like foster, harder, faster. It is more about the fact that if we are not solving the big problems, then we are not being responsible. Yeah.

SPEAKER_00 8:30

Brian, what do you think about that? I mean, you're you're interfacing with clients every day across a wide variety of industries. Is that what many organizations are doing, or is there a learning curve there?

SPEAKER_02 8:39

I think there's a little bit of all, right? There's you think your experience is gonna vary. Cisco's obviously a leading technology solutions manufacturer provider, developer innovator. I think organizations that don't necessarily have that kind of a culture built into the fabric of how they operate, that that may represent, that may manifest itself in a development workforce that may be a little bit more hesitant to lean in and understand that it's mission-oriented as opposed to project-oriented or code-oriented. And what we've seen with clients that have really, I think, made it past that that made it around that curve is kind of forcing the issue to have the conversation with your workforce that it is gonna behave differently. We're asking you to do things differently, and what you were doing yesterday might be a little bit different tomorrow. Your skills are still super valuable. We still value all of what you've done for the organization or in your career around software, but we're gonna apply it differently now. And so I think being forward with that in areas where maybe the culture isn't as innovation-leaning is important, but I think it's a great question from Joe just around being thoughtful around the cultural shift and the adoption curve matters deeply in this stuff because it's not just about acquiring a tool and giving it to your workforce and hoping great things happen. There has to be a purpose and a plan behind it. And I think the mission way you say the standard diraj is a great way to frame it.

SPEAKER_03 10:00

If I may, one of the other things, Brian, is what we internally have found is I think the showcasing the failures, yeah, and not in a way like you're calling somebody out, but celebrating that this was tried and this was a learning from it is is very helpful. And then the other part that we again live through talk rather showing rather than talking. Right. So instead of a very elaborate sort of spec or this or that or the other PRD specification, why don't you just give it a lived experience through a prototype? Prototype it, yeah. Right. And I'm telling you, like 10 out of 10 times, once people have used the tool, they feel so much of empowerment. Yeah. Right. One other additional thing, and this goes back to your your skills, are really important, is AI is generic, right? And it will give generic answers if you give it generic prompts and generic everything. What makes a product really hum and really sing is that domain expertise that needs to come. So it is not that a generic AI is gonna solve bisco problems, domain expertise amplified through AI is what solves real world problems. So that skill set stuff is very, very important. Code is just a means to express it.

SPEAKER_02 11:34

Yeah. I I've I've been using kind of a framework of you've got to create a mindset around adoption to build confidence that leads to having, and ultimately you're gonna see change. Yep. And you know, it's it's being deliberate about those things. Again, not just hoping for the best because you've provided a tool. We've given tools to people many, many times with mixed results. And I think in this case, we're being at least internal to worldwide, but very, very deliberate. It sounds like Cisco is as well, but you're you're focusing on the how and the why, not just the what. Yep, absolutely.

SPEAKER_01 12:06

I I would also add, and I think Brian can attest to this, and Raj, I think Cisco's probably in the same boat. This starts from the top. Top down, 100%. And you know, if you know anything about our CEO, Jim Kavanaugh, I mean, he's very passionate around AI. And so every Monday on our AI calls throughout the week, he's attending, he's asking the questions. But but when we've seen customers who have really dived into AI over the past couple of years, it really is because they've got someone at the top driving it and making sure the success and pushing it down. To your point around the mission, it's not just a product set, it's really how do I change the organization with these tools? But that's driven from the top down. And that's really how you can moment.

SPEAKER_02 12:46

I think sending us. Yeah. Because we want to see proliferation of our user base uh really taking full advantage of these capabilities.

SPEAKER_03 13:24

One of my engineering leaders, she says, and it's very, very true, doing AI is easy. Doing AI well is a lot of hard work.

SPEAKER_02 13:36

Oh, yeah. But I I I think it matters to get people off the starting block because when they realize what's possible, then the curiosity kicks in. And that's when I think real change can happen, and that unlocks all sorts of new possibilities that we weren't really able to tap into before it weren't even in our vision before.

SPEAKER_00 13:52

So the adoption curve is real, but it cuts both ways. As tools proliferate and everyone from developers to business leaders starts building with AI, a new risk surfaces that most organizations aren't ready for. This episode is supported by cognition. Cognition's AI powered developer tools, windsurf and dev and deliver deep code-based understanding, intelligent code completion, and the autonomous engineer capabilities to help teams embrace the future of software engineering. Supercharge your development team with a cognition platform.

Shadow Engineering Is Already Here

SPEAKER_00 14:23

Well, Joe, I mean, you know, Brian's talking about how you know the unlimited possibilities once it kind of clicks for people, but are we also kind of entering an era where you know we've all heard of shadow AI? Are we gonna have shadow engineering where you know Brian's making that that's already out there, Brian?

SPEAKER_01 14:38

If he's writing code now and well, if he's prompting for code, well, that's where kind of Brian talked a little bit about the governance. And you know, you hear more and more people talking about the notion of the harness where you've got to make sure your data sets are in place, your governance is there, you've got security behind it because it does start spreading fast. If you don't have these other things already in place, that's where you're gonna get yourself into trouble. Yeah, and so just having that team. I know we talked a little bit about you know the COEs getting formed in a lot of the organizations, just having that attention on these things now before your departments go out and just start buying stuff off the shelf. You don't know where your data is going, having that COE and governance now is really gonna be a tremendous asset as this gets bigger.

SPEAKER_00 15:23

Yeah, Raj, I mean, we're talking about code being created faster than ever and tools in everybody's hands. What other risks do we have to be concerned about as we enter this era where things are gonna be popping up all the time?

Agents Don't Just Think. They Act.

SPEAKER_03 15:36

Yeah, so I think the biggest risk, there are two parts to it. One is agents have reasoning capability. What does that mean in normal English? We used to write, I've written software, right? You're writing software. Sort of. Is we used to write code, right? It would be if this happens, do this. If then else, so on and so forth, right? So there was a codified logic. You give the same input ten times, you're gonna get the exact same output, right? These agents do not have that kind of methodical thing. It is what is called reasoning. Depending on the input, I might take a different action. So that is number one, the risk part. The other thing is agents take action. APIs don't take actions by themselves, devices don't take actions by themselves, right? There is, those are all in some way waiting for instruction. But agents take action. And in that world, there are those are the, I would say, from a technical perspective, those are the two biggest risks. Because between reasoning and the ability to take action, what really becomes important is yeah, accessing that Salesforce.com or your Jira instance or whatever, that may be perfectly okay, right? For an agent. But the intent behind that access becomes very important, a very simplistic example. It's one thing to say, I'm asking my agent to have access to email so it can summarize this email that Brian has sent, because Brian sent me very long emails. He's excited about the software. So it it's one thing to say, I'm gonna summarize an email. But that same access, if you're scraping my entire mailbox, very different intent. So codifying that reasoning along with the ability to take action action and putting it behind an intent, that is the key. Now, there is no protocol for intent, there is no spec that is out there in the internet, but that is what we as an industry and we as Cisco are trying very hard to distill intent into both visibility as well or observability as well as policy so that you can match up the intent of the agent because these are reasoning and they take action. So, how do you allow looking at one email to summarize? Perfect. Looking at my entire mailbox, same function, but calling my entire mailbox to scrape every single email, probably not okay. How do you see,

Every Agent Needs An Identity

SPEAKER_03 18:19

Raj?

SPEAKER_00 18:19

Stick with you. How do you see identity and access evolving as as AI becomes more autonomous? I mean, you're the way you would talk about it previously would be for a person or for team, yeah, or for an application that didn't have agentic reasoning. So how is it shifting over time and where is it going?

SPEAKER_03 18:37

Yeah, so two-step process. One is authentication. Authentication, which is just giving an agent an identity, just like back in the old days, right? No, you wouldn't let somebody come in, plug a device into the wall socket, right, whatever, and say, now you are on the internet or you have a DHCP address. Yeah. Right? We wouldn't do that. Yeah. We do a posture check and all that kind of stuff. So when somebody brings an agent, before you give it an identity, you've got to make sure that this agent is worthy to be on your environment. Because this agent is going to take action all around. So how do you do that? You basically posture check that agent, the skills that it has, does it uh have access to MCP servers that might be corrupted, etc., etc. So you're basically checking the posture of that device. Once you've given it an identity, you want to classify these, right? I mean, they're what, I don't know, 100 billion URLs on the internet. We don't manage these one URL at a time. We're not going to manage 10 million agents one agent at a time. So you classify and say, this is an HR, this is a this is a benefit, so this is whatever, travel expense, something like that. So that you can put appropriate policy. So that's step one, which is literally the act of giving it identity. The second part is authorization. Authorization is this is the scope on which you can access whatever you're trying to access. The key part that we this is the lesson that we've learned building agents ourselves, and then how we are helping customers together working with WWT is that authorization needs to be scoped appropriately based on the intent. Right? Ideal case, and these are the solutions we're building, the agent never holds an authorization token. There is an entity, whether it's a sandbox, whether it's a gateway, whatever, something else is holding that authorization. So IT and security can determine this is too much, this is too little, this is appropriate, not appropriate. But you ideal state, you never want to give the authorization token directly to the agent because it will go hay.

SPEAKER_01 20:49

So Raj, to that point, what happens when the agent isn't within your organization?

Trust, But Trim Permissions

SPEAKER_01 20:54

Let's let's say a consumer tool where I'm using my agent on my behalf, it's calling my bank or it's ordering something.

SPEAKER_03 21:02

Yeah, so third-party agents in that authorization becomes even more pronounced and even more important. And the way to work this is what is called self-attenuation. I don't want to go technical on you guys, but just very briefly. Well, you got Brian here. Yeah. So maybe for Brian. I slept at Holiday in Express last night. Very briefly, you it let's say you have a. So now it's using an authorized. Topen on my behalf to go to Amex. Yeah. Yeah? So every two weeks, expenses get filed. Four, six, eight, ten, whatever. Six months into it, there is a new credit card that is issued in my name to send to a different address. Is it right? Is it wrong? I don't know. Right? I might have changed addresses. Maybe I lost my wallet. Maybe the card expired, whatever the story may be. But but this is what goes haywire. I don't know whether that card is okay or not. But when you take this read-write permission for my scope that I've given in Conquer and take that read-write permission to your Amex, that becomes a problem. So you want to trim that down to just read permission when it goes to MX. Okay? And when MX were to call USPS to look up if this address is really true, you'd trim it down even further to say you only have view capability. Right? So trimming down the scope is how you keep these things in check. Otherwise, they have absolute sort of agency to go in any direction.

Your AI Bill Is Coming

SPEAKER_02 23:11

Just another thought on the on the topic of policy and risk. Maybe a a different angle on it than the traditional secure, you know, security and compliance side is there was a story this week around an organization that unleashed their enterprise AI tooling to their workforce without caps, without with no metering. And they've got a $500 million bill.

unknown 23:35

Yeah.

SPEAKER_02 23:35

Is it true? That wasn't that was in the news this week, right? Now it might be marketing fluff, but it I think what it represents is FinOps starts becoming a very meaningful part of this. And a lot of the tools that we're deploying today, they're SaaS. In many cases, if you're building your own, you might be deploying that in a NeoCloud and a hyperscaler. It's off-prem, it's somewhere else. But when it becomes a bill, it becomes very real. And to your point, whether it's assigning an identity or a policy to that identity for an agent or to the actual workforce at large, the user base, the real people, and how they're building and deploying new capabilities using these tools, there has to be a mind's eye towards the not only the cost, the you know, the token at the tokenomics associated with it, but also there is a right size for right fit type of an approach here as well. And that's again back to infrastructure. You you're likely going to see a significant shift towards a hybrid IT, hybrid AI model that is a balance between I'm consuming some from the public, private, as a service, et cetera. But I'm gonna I'm gonna have applications and workloads and data access and security and governance controls of the right order for the right purpose. And I think that's, you know, maybe a few steps downstream from where we are today. But that that first article of a half a billion dollars in expense wakes everybody up. And so now there's a, you know, it's at least an acknowledgement as of today, you have to think about this. Yeah. And even though you're gonna go this path now, because it's the path either of least resistance or speed, you have to be mindful of not only the expense, the risk, and the security, but how you architect systems for the future to again enable the right fit for the right, the right purpose.

SPEAKER_03 25:24

Yeah, and locally deployed models are definitely gonna be there. Domain-specific models, I mean, it's a little bit of an oxymoron, but small language models, all of these are very much part of the techniques for development at scale. It is happening now, it's not future tasks, right? It is because you're not gonna go to the frontier model for every single question. That should be your, I don't want to say last resort, but that should be for the most sophisticated of the things that the local models cannot adequately answer. This is why e-vals become really important to you. This is why we we're really happy to have something like a Galileo as part of our mix because how do you make sure that when an agent fails at a certain task, for you to know what why did it fail? Right? So tying exactly to the spend and everything else that is happening, there is going to be specialization of these the way models are. And I, to anybody who disagrees with me, I tell them just look at how many, how much of specialization there is in databases, right? That's right, right? Just look at how many bespoke variations of databases because at scale, you cannot not have that kind of specialization.

SPEAKER_01 26:41

So absolutely spot on. And so really honing in on what outcomes you're focused on and what is the true cost to get to that outcome, I think is becoming a lot more important these days.

SPEAKER_03 26:53

Accomplishing the task, yeah, which is what EBAs measure.

SPEAKER_00 26:56

Yeah, I think 100%. Yeah. It's a perfect way of so not just not just token spend, but but execution. And to build on your news article, I'll offer you another one. There was a Wall Street Journal article that that found only 18% of spending on AI coding tokens translated into shipped products. So, Joe, I mean, what's what do we think the gap is there? Is it just not knowing how to use the tools? Is it training? Is I I think a lot of people are playing with it.

SPEAKER_01 27:22

Yeah, and they're creating stuff. And to them, maybe it is providing value in their own day-to-day. But as you start looking, this goes back to sort of that outcome-based or kind of business value. What are you really trying to achieve? And maybe that's more of a team or department structure. Is it producing the outcome that group needs, not just the individual?

SPEAKER_02 27:42

I think I think we're still really early. Yeah. The shift is underway, but it's you know, it's top of the first right now for a baseball analogy. I think there's still a long way to go for an organization to see meaningful gains from a growth, an operational efficiency and or innovation standpoint. But there are absolutely whether it's 18% or 5% or 30%, I'd say instead of worldwide, we're seeing very meaningful progress through all of our departments, whether it's finance, it's HR, it's ops, it's global supply chain, it's our technology teams, all of us, our API, we're all gaining ground, becoming more operationally efficient. I think we're actually seeing a path to revenue gains as a result of a lot of work that we're doing and the way that we show up with our clients. Now, the question is, does that efficiency translate into meaningful progress? Or did I just give somebody back 20 minutes and an hour and they're gonna go screw around? Yeah. Right. Is that actually translating into that 20 minutes gets applied to a more meaningful task now that they couldn't otherwise get to? I think for us and for most of the clients that we encounter, there's more work to be done than they have people and resources. So there's a backlog that's a million miles long. Ideally, because we're able to get through more tasks faster, we're able to conquer that backlog more quickly. And again, turn your mind's eye, your best people, towards what are the biggest problems you have to solve and how do we start making progress against those?

SPEAKER_03 29:05

Talking about big problems and how tokens get utilized in the eight odd weeks, eight some weeks that we've had access to mythos, we have gone through nearly two billion lines of code around 50 plus products. All of that consumes tokens. Yeah. So it's not the producing more code, but all of the analysis that goes into it so that you're fixing it. Just give you one example because Mythos is on everybody's mind. But there are many, many such examples where there is, of course, there is some leakage where people are filipping with their use of tokens. But I would say by and large, it is used for whether it's for research, competitive Intel, digital twinning. There are thousands of other things that software requires other than just a writing code uh for it to go into production.

SPEAKER_00 29:56

So the measurement question matters. How do you know AI is actually delivering value and not just consuming tokens? That's a real challenge, but there's a harder challenge sitting underneath it because the same capabilities that make AI coding assistance powerful also make them dangerous in

AI Can Find The Bugs. Can It Fix Them?

SPEAKER_00 30:11

the wrong hands.

SPEAKER_01 30:11

I think Mythos came out and it either I think a third of the group got completely scared and goes, oh crap, what are we gonna do with this? A third thinks, eh, I don't know how it's gonna affect me yet, and a third just don't know how it's gonna affect them. So there's definitely still a lot of confusion about it. I know our security team acted very quickly on it. We've we've created workshops and briefings on in the past six weeks just because of the amount of customers asking us about it. But we see we see it being real. I mean, this thing, it the cat's out of the bag once again, and this thing's got some real power behind it. I think kind of how you guys are using it for good of hey, I can look at all my code bases and quickly figure out what gaps I might have and remediate them faster than maybe you ever had before. I think everyone's just scared of what happens when mythos starts getting in the hands of the bad actors at some point, and what's that gonna do to everyone's infrastructure and their in their in their code? But there's there's just a lot of conversations being had about it and people need to take it seriously right now, for sure.

SPEAKER_02 31:14

And I think the just to tie it back to native engineering, there's there is a path here where you're using it to scan your code base or your infrastructure and look for vulnerabilities. To be able to patch those at the speed that you need to using legacy approaches might just not be fast enough. Yeah. And so to have coding assistants at your disposal that are proficient and actually tailor-mage for that type of a use case to quickly remediate your code and get yourself into a position where you're no longer at risk. That's actually where these two worlds collide. So now I've got tooling, whether it's mythos or other. There are plenty of other tools out there that will help evaluate the infrastructure and code for vulnerabilities. And now I've got assistance to help me patch or remediate really quickly. I think that's again, it's changing the game. These are not the same problems that we were dealing with before, and the solutions aren't going to be the same either. And we're we're coming up with new ways and new innovations to ensure that we're staying a step ahead. Yeah.

SPEAKER_03 32:09

I mean, you guys will see. We've blogged about this, we've taken some of these things to open source. It's called Foundry Spec. What is the harness that we built around? Because I mean, 1.8, whatever that number is, 1.8 billion lines of code. You don't go to a chatbot and say, here is a GitHub repo, tell me the button. That's not how it works, right? So there is a lot that goes into the harness to make sure that it is accurate. Cisco's taken that, what we used internally, and open sourced it, right? So everybody can use it. And I know I've talked to to Brian and a couple of other folks within your organization of how best to use it. The thing that I wanted to say again there is yes, finding bugs, yes, fixing code, but the biggest benefit that we get out of the AI model is the richness of the test cases that are built. Because it's those test cases that help us make sure that this fix is a durable, nothing more, nothing less. The performance is accurate, and that we have genuinely plugged it. It's not like we've just taken care of one aspect of it, but this is going to be effective in many different ways that we are going to see the attack form. So, from my perspective, not even just a practitioner's perspective, my perspective, it is the ability to write a very, very rich library of use cases where AI is a huge asset, more than even fixing

Don't Wait For Perfect

SPEAKER_03 33:41

the code.

SPEAKER_00 33:41

So we'll close out with this question. Um, I'm gonna ask each of you, you know, just in general, what do you think a priority or a you know a tip or piece of advice is? Joe, I'm gonna ask you from the perspective of a user. Brian, you'll be from the perspective of an organization or an executive. And then Raj will ask you from the security standpoint, what do we need to be doing to make sure that the back half of 2026 we're set up for success with coding agents and AI native engineering?

SPEAKER_01 34:05

Yeah, I'd say from the user perspective, it's be curious, start testing out these tools, play with them, become familiar with go get training. If your organization isn't providing these yet, you know, start fighting for those licenses because this is the new way. And if you're not doing it, your competition's coming up on you because they're using the tools too. So yeah, get used to it, don't be scared and just dive into it.

SPEAKER_00 34:29

Okay, so go go rack up the tokens. So go rack up the tokens. Okay, Brian might have something to combat that with here. Yeah, maybe.

SPEAKER_02 34:36

No, I think you know, if I'm an organizational leader or an enterprise and a business leader, I think one of the things that I'm as I just reflect on our conversation and all the conversations that we have, events like this and others, it's a lot. There's an awful lot to deal with. Whether you're in purchasing, you're a finance leader, you're a CIO, CTO, CISO, chief data officer, CEO, board. The the amount of demands and things to unpack all at once, it's never been at this kind of pace. And the margin for error is just too narrow, right? It's just it's a combination of factors that make it very difficult for an enterprise leader to be able to move at the pace that they'd like to keep up with or even advance themselves. I I think the most important thing is, you know, being in an event like this with Raj with Cisco, choosing the right partners matters. And it makes an just an immediate impact when you look at having the right organization at your side to help you navigate the complexity of all these things, learn from each other, benefit from the experiences that have been getting elsewhere, tackle new problems in new ways. But I think, you know, organizations like Cisco, like worldwide, I think we we we pack the goods to really help navigate the complexity of all the challenges that exist out there and do so in a way that we're gonna fail quick, but keep moving forward and and ultimately find a really positive outcome in the end.

SPEAKER_00 36:00

Yeah, so Raj, I mean, if if we want everybody to get our hands on this, but also the margin for error is thin and there's some risk here, what do we need to know from a security perspective?

SPEAKER_03 36:07

I would say three or four things. Number one, you guys run capture the flag exercise. Yes, take advantage of it. Yeah, right. There's never been a better time using the sort of open source sort of tooling that is out there. Capture the flag, really important. Run a hackathon. Run a hackathon like you actually mean it. Give people truly two days, whatever the time frame is, and and give them the ambition to be bold. What is the biggest problem you would solve if cost was not an issue? Right? The third thing I would say is you've got to celebrate that moment where something happens. In if you use general terms, things become like, yeah, okay, we'll get to it one day. Here was how I inspired our team. We were at a customer advisory board, we ran a session, I told everybody explicitly from 3 30 to 5 30, we were gonna say, What is the most important new feature you require? Right? And the goal was that by the time CAB was over, which was a day and a half later, we will have that production ready feature. That was an explicit goal. You're gonna get something that you don't know about between 330, between 3:30 and 5.30. And by the time they leave the day after next at 11 or 12, it is has to be in production. And we did it. By making it concrete, people know what is the what is it that that makes it real. Otherwise, like code, we could go faster, blah blah blah. Like those things are good, but they don't have the impact. Yeah, give a goal that is concrete and then celebrate it. Really important. And then if something fails, yeah. Whatever. Fix fast. Uh failure will happen. Move on. Um but this is the moment time to be precise and auto.

SPEAKER_00 38:01

All right, thanks to Raz, Joe, and Brian for joining us during a very busy week at Cisco Live. The key lesson here: AI native engineering begins with experimentation, but it can't end there. The organizations that gain the most from these tools will not simply generate more code or consume more tokens, they'll be the ones turning domain expertise into working solutions, measuring whether those solutions produce meaningful outcomes, and building the security controls required for systems that can reason and act independently. That means giving people room to experiment. It also means giving agents identities, limiting their authority, understanding their intent, and knowing when their behavior begins to drift. And perhaps more importantly, it means choosing problems worthy of this moment. This episode of the AI Proving Ground Podcast was co-produced by Nas Baker, Kara Kuhn, and Sarah Chiadini. Our audio and video producers were John Knock and Brian Gagliano. My name is Brian Phelps. Thanks for listening. See you next time.