AI Boosts DevOps Productivity Amid AppSec Fears

Hey everyone. Welcome to techstrong gang. I've been off the show for the last couple of weeks as I did some family vacation and some business travel in Europe.

It is great to be back on and to see these smiling faces, or mugshots, as the case may be, looking at me in my stream yard. But welcome to techstrong gang, and we're happy to have you. Let me quickly introduce you to a full house here today.

We've got the esteemed Ira Winkler. Always good to see my friend Ira on. Stephen Foskett of Tech Field Day, and he brought Tom Hollingsworth with him.

Tom, good to see you. Yep. That was a Hollywood Squares move there, Stephen.

I don't know where he is. Charlie Weaver. No one knows who Charlie Weaver is on here, except maybe Mike Broussard.

Of course, we have our two, Robert Reeves and the aforementioned Mike Broussard. Mike, good to see you. Thanks for holding down the fort.

Let's jump right into it, gentlemen. com about, hey, maybe this AI stuff does help developers after all. Yeah.

Well, I think we're reaching that point now where we're trying to quantify some of this stuff, and the challenge, of course, is AI keeps moving as well, so some of this stuff is still a trailing indicator of where we may be. But it's interesting that Jellyfish did a little survey, and they talked to 636 software development engineers, and you can assume that they're reasonably experienced folks, and two-thirds of them are saying that they've seen an increase in developer velocity and productivity of about 25%. Now, everybody's in a different place, so what that 25% growth is, is hard to quantify, but at least a quarter were saying that it's between 50% to 100%, and even 6% said it was 100% or more.

Primary areas that people are using it for is code writing, 53%, code reviews, 49%, code explanation, 43%, and favorite tools, of course, are Claude. Gemini Code Assist came in second, and GitHub Copilot was ranked third. But it was interesting to me also that the survey also said that just about half said AI is improving the quality of the code being developed, and that seems to be one of the challenges that people are still trying to sort through, and they're also getting into issues around cost.

And there's some challenges about, well, which tool to use because all the AI models seem to be playing leapfrog. But Robert, does all this resonate with you, and are we seeing an actual ROI? Because is there a difference between, well, a developer might be more productive, but that doesn't mean more applications are going out the door faster.

Well, that's true. Remember, if we're evaluating ROI and productivity when it comes to DevOps, we've got four metrics. That's what Dr.

Forsgren tells us, that what you need to pay attention to. So any kind of ROI analysis on AI adoption, there should be looking at things like lead time and meantime to recovery and the rest of them. It's important that if we're going to evaluate productivity gains, that we're using the same measuring stick.

I encourage either before and after adoption of AI is good. I'm not a big fan of controls, where we starve one team of AI benefit, so we can see the other folks doing it. That just leads to contempt and resentment.

Mm-hmm. But there's one thing in here, Mike, that you talked about in this article and in the survey, and that is two things. One is that there's a concern about adoption from senior engineers.

And then there's also a concern about the quality of the code that AI solution is delivering. I would really like to see those senior engineers see if it is the model or the AI provider that is causing the bad code, or it's how the other engineers are interacting with it. I have just seen senior engineers be able to get amazing productivity and teach and mentor junior engineers, and I'm wondering if applying those skills to that agent and helping to educate the other junior engineers, mid-level and junior, in the company to use the AI solution, if they would start to see higher quality.

I think getting those senior engineers on board and creating a win-win-win for them, for the company, and the customer, their users, that's the way to approach this. Right. Alan, to your intro, it does seem like everybody, at the very least, is now using these tools to some degree, but it does feel like everybody's all over the map in terms of where they are in terms of expertise and skills, and maybe that's the next big thing we need to focus on.

Well, I'm glad Robert brought up the DORA metrics. Right? With, is of course, Dr.

Nicole Forsgren. But I remember when they first came out with the DORA metrics, right? It was Nicole, it was Jez Humble, and of course, Gene Kim, right?

It was before Google bought them. And John. Don't forget John.

Who did it? No, but it was really the three of them who did those DORA metrics. Fair to my friend John Willis, who I love.

But it was an interesting thing. It was Gene Kim who made the correlation that those metrics signified high-performing IT teams. But if you look at the companies who had high-performing IT teams, their stock prices reflected itSo it made an impact on the bottom line.

Those companies were high performers stock-wise, not just IT development-wise. And I think that's what's missing from this kind of survey and where we are today with developers using AI. I think a lot of us kind of swallow the Kool-Aid and like the cotton candy and say, "Look how cool this is, man.

I just made an app. Boom. " All right, so it's just a shell, the empty.

I got to go underneath and fill in all the hard stuff. But look, so I'm much more productive. Much, much more.

How much productive? Ah, 25% at least. But until we see these productivities, these DORA kind of metrics translate to bottom line ROI, as Mike or Robert said, I don't know if I'd bet the house.

I think you've got to still follow this through to where rubber meets dollars or crypto coin or whatever the equivalent is today. Go ahead, Tom. Well, Alan, I appreciate that you're digging up all these old surveys, but I don't know if you know this or not, but according to NVIDIA, we don't measure in dollars or imaginary money anymore, it's tokens.

Yes. However many tokens we're burning through, that is how productive we are. Meta even put a tote board up that said, "Here's our most productive people," and it was really just the token burn rate.

Now, I'm sure that has absolutely nothing to do with the fact that NVIDIA manufactures the machines that make tokens, and so the more of them that you're burning, the better. And that could never lead to people creating convoluted code that consumes more tokens to build. Although, I think that now the revolution's going to be burning even more tokens to take that convoluted code and boil it down to its bare minimum, a la those old one-line Perl competitions and things like that.

Right. I feel like how are you measuring productivity? Any time you put a number to it, you are creating a scenario where someone's going to attempt to game that number, burning through tokens at a rapid rate, or how much money can I expend on this particular offering now?

Because one of the things that we're seeing is that Claude or Anthropic and Microsoft are saying, "Oh, no, wait. " Because as it turns out, letting people on the $20 tier do that makes them way too productive for- Oh, yeah. You had me till right then, Tom.

You had me till right then because you were making my point. Tokens aren't necessarily profits. But as I tell people on my team, two, three, 400, $500 a month spent on tokens is still coffee money.

What do you spend a month on coffee and lunch? Right? If you're really getting the productivity gains they're talking about.

Yeah, but there's also people who are running out of their tokens halfway through the month, and then their project sits, and they do nothing for the next two weeks. Well, they live below the AI poverty line. I guess that's- Well, look, our friend Wendy, I ring you know this, our friend Wendy Nather, who's famous for the cyber poverty line.

Most organizations can't afford to do security well. She called it living below the cyber poverty line. We're going to have the same thing with living below the AI poverty line.

Alan. Go ahead. Oh, sorry.

I want to bring up something else because I think one of the findings that struck me was that the senior engineers are less likely to use some of the AI tools and things like that. And I think that I wonder if they're going to make themselves theoretically obsolete, because fundamentally, there's always the old people who, I'm kind of not young myself, I'll say it that way, but there's a lot of people who are just hesitant to change their ways because honestly, vibe coding, doing a lot of other things is a different way of doing things. And you're talking about somebody who's senior, and I care frankly more about these coding tools that are going to start to hire some of the more experienced people and take the algorithms in the back of their head and implement them into the machine learning models and the LLMs that they're using in order to make their tools better.

And that's going to make the more senior people obsolete because, in general, when we're talking about AI, and I hate the word AI, but I'll use it with Dr. Evil quotes every time I say it, it's like the people who are going to last are going to be those people who don't spurn AI, whose jobs aren't going to be taken by AI, but whose people are able to use AI to make themselves more productive. And frankly, one of the problems is, I think when we're talking about people writing code, that's one thing.

But again, from my cybersecurity world, what we really need is some of the other tools that double-check what these people are doing. And it's interesting to see whether or not they're going to be using AI by incorporating whether or not they know they're doing that by having those AI tools that are making the code process more efficient, making the cybersecurity reviews more efficient, and everything like that. And so it's a little bit, I think, naivety of where people are using AI.

Maybe we're talking right now just in the actual coding itself. Right. But in the overall process, it's got to be incorporated as well.

To your point, we need to also include how much of the code that was created was rejected for whatever reason, like security issues that got kicked back, and then I wound up doing it over again, right? Because that's always been an issue. And so now, as one wag once said to me, he said, "AI is great.

" Lead time metric would capture that, Mike. Yep. If we are using the DORA metrics, things where we have to send back, that extends lead time.

Honestly, I think applying the same metrics that we do to humans would be good. That's true. Also, we all saw last week, the startup that had their production database and backups deleted.

" And as the token DevOps engineer in any group I'm with, I looked at it and I was like, why aren't you treating that AI agent like a junior developer, and why the hell would you give the junior developer access to production? It's like I drank this bottle of whiskey, and I didn't put on my seatbelt, and I got into this car accident. I can't believe the car manufacturer.

My God. Yeah. But here's an interesting thing.

My experience is a lot of senior people are more quickly to embrace something that's going to bump up their productivity, right? Yes. Let me play both sides- Laziness is a virtue.

Let me play both sides of it, because I like doing that. On one hand, you have senior people who, they're the ones who can get that 10X bump because they understand it best, and they can make it happen. On the other hand, I don't think there's ever been a better teaching tool, and not just for coding, for teaching history, for teaching sociology- Yes ...

than AI can be. And that is one of the promises when we talk about how AI can really help us. It could be a great teacher.

Well, I think that sounds really poetic, Alan, but at one level it's all b******t because, no offense to you, but it's sort of like, yeah, there is all this potential, but at the end of the day, more internet traffic is being done with porn than it is with productivity and things like that. How much of that porn is AI porn, Ira? I haven't reviewed it.

I haven't done my study there. Maybe I will. But the reality is, is that when we're talking this, there is the potential, but what is it actually being used for in the trenches by people who are being shoved these tools, as opposed to being taught more appropriately how to use them?

Having been in a large company where AI tools may have been started to be used, and I can't confirm or deny anything, it started to be there, but again, the cybersecurity team then had to go back and be the buffer and start to look at, hey, the problems we're going to talk about in the next segment, for example. We need to make sure that the fundamental good coding practices are built into it. And saying it can be this, it can be that, the problem is there's a lot of people who rush to get these tools out there, but there's not as much effort into training people how to do it properly.

There's not as much effort into forcing it. I don't want to say forcing it through- Well, now it's my turn to call b******t, Ira. Yeah.

Okay. Why should AI be different than any other thing we've rolled out in the last 30 years? Oh, I 100% agree with you there.

I'm just saying that the poetic nature of what it can be is like unicorns and rainbows. But instead of unicorns and rainbows, we're getting mules and walking over big roads. We have not heard from Steven yet on this topic, and I know he's sitting there grinning like a Cheshire Cat, so I know he has something to say.

Yeah, I got a little bit to say. First, get off my lawn, you whippersnappers. Go say it in front of your own house.

It's funny, I love this. I listen to Ira, and I'm shaking my head, and I'm nodding and shaking and nodding, and I think you're right, Alan. We don't need to be cynical about this.

I think if we're going to be defeatist and say we'll never be able to use these tools appropriately, then that's no good. We've got to have belief in our own abilities. And I agree with you that senior developers have not actually been slow to adopt this stuff.

In fact, most of the senior devs that I know are actually pretty realistic and pretty impressed with what they can do with some of these tools. " But the problem is that, to Tom's point and so on, a lot of these companies, I think, are expecting miracles instead of inspecting just next generation capabilities, and that's just not realistic. Yep.

I love the idea of using these DORA metrics. I 100% agree with them. By the way, everybody, look it up on Wikipedia and you can see what it's all about, because they're realistic.

They're like adults in the room kind of metrics about developer productivity instead of this nonsense about using tools. Unfortunately, a lot of the senior developers that I've talked to have been smacked down because they're actually taking a respectable, responsible, confident, understanding approach to using these products, and their administration, who's bought into this idea that somehow this stuff is fricking magic-... are saying, "How come you're not using this better?

How come you're not using this more? " Instead of being like, "Wow, you were able to use this and turn this stuff around twice as fast and generate twice as much code. " No, twice as much isn't good.

They want 10X. They want 100X. They want no developers.

That's just not realistic. We need to let people who know what they're doing use this code or use these tools to generate better code. And, to Ira's point as well, the next section, we're going to be talking about security, and it's the same thing.

These tools are incredibly good. In the right hands, they can do some really cool stuff, but if you're expecting it to be a magic wand, you're going to be disappointed. I also think it comes back to the human condition.

There's usually two types of people at work, right? There's those that want to do the thing well and do it right, and then there's those that just want to be done. If you just want to be done, you just generate a bunch of code, and you check the box, and you go home.

Yep. And it's garbage. Well, speaking of wanting to be done, though, we are done with this segment.

It's time to move on. As Ira kind of telegraphed a little bit, we're going to talk a little bit more about security on this one. Mike, what do we got?

Yeah, so everybody seems to suddenly be talking about the security issues inherent with vibe coding applications, and there was a report on Wired about this, and we covered it on Security Boulevard as well, and it's suddenly top of mind, and I think everybody kind of knew this issue was coming, but Ira, is it your sense here that we're going to wind up exposing more data and more personal information, and we're now accepting that, or is there a day of reckoning going to come with all of it? There is definitely going to be a day of reckoning, and not for the right reasons. The day of reckoning, in my opinion, just for example, is going to come because somebody is going to violate some privacy regulation, whether it's GDPR, LGPD, if the US ever gets their act together, maybe CCPA or whatever replaced it recently.

" And vibe coding is perfect for that. The problem is that the people who are doing it, it's much like security from the beginning. One of the examples is Mozilla.

The first version of Mozilla, which I unfortunately remember, or maybe I fortunately do, had no password capability. 2 that somebody said, "Hey, you know what? Security might be important.

" That was not built in. That was an afterthought. Encryption, SSL, was an afterthought, and the problem is security in everything that's doing, especially not when you're taking, for example, corporate organizations and having a nice corporate function that says, "Here's the requirements of my software," but allowing vibe coding to have individuals, and it's not necessarily a bad thing, don't get me wrong, but allowing individuals to come up with their own code and do all these functions with it.

It's kind of like we were talking initially about shadow IT. " And anyway, I'm thinking, yeah, this type of stuff happens, shadow IT, and I'm using shadow IT because now what we have is, maybe I'll trademark the term, we now have shadow coding, which never was able to happen before. And the same thing with, then you have shadow AI, where people were, for example, taking, let's say they wanted to write a performance appraisal, and they wanted to do a good job, so they went to ChatGPT and said, "I want to write about this person.

Here's what they did," and so on. And that became shadow AI, where they were violating corporate policies to do these things. Now we have shadow coding, in my opinion, where people are just randomly doing things, and we're going to have to catch up and stop it from a security perspective, or we're going to have to start to put in internal policies that much like you have anti-malware, you're going to have to have anti-vibe coding for a lot of people.

And that's just random people, but even the people who are within the programming function are vibe coding these things. They're using tools that were never trained to implement cybersecurity concerns, and that's another aspect of the whole vibe coding thing. Because I read in the article that was highlighted by Mike, I think it was your article, that everybody is pushing back.

" I'll call b******t on that. " And, "Oh, gee, yeah, that is a concern. " They didn't.

No, Ira, some of them come flat out and say, "That's the way it's supposed to work. " Well, and yeah, but they maybe should have a paid function that says, "We're going to implement cybersecurity," which would be a good add-on that I would encourage people to purchase. But it gets better because as far as I can see, what's about to happen is we're also seeing AI being used to discover vulnerabilities faster than ever, and theoretically, maybe we're going to patch them faster than ever.

Well, yeah. And then we're going to have this cycle of events where we're going to have people who don't know much about coding generating more coding than ever, which has more vulnerabilities that are easier to discover and exploit than ever. So, I mean, at some point, does this just kind of collapse in on itself?

Well, I have to say, I'd like to full disclosure for bias, I'm with Isle, and we do what Mythos does, but better and, but more importantly, fix it, which is part of the problem that Mythos and all these other tools aren't addressing. Because it's more like, I describe these things as pulling a Nelson. " It just basically goes, "Ha ha," shows up randomly, goes, "Ha ha," finding these vulnerabilities.

And one thing is these vulnerabilities are always there, and the article you shared, for example, on the finding of vulnerabilities in Mozilla, they said roughly 420 vulnerabilities were discovered. 200-something were attributed to Mythos. I'm like, that's still another 150 vulnerabilities that other people are finding as well.

So anyway, I'm just starting to think, okay, let's go ahead and do that. Who's this typing? I'm just typing.

Oh, sorry. Guys, whoever's typing, you got to stop because that's coming through on the screen. But anyway, sorry, I'll just leave it there because these vulnerabilities are going to be found.

And again, we should have Mythos, I think Steven, I'll try, typed in the chat. Yeah, maybe they should start including this in Claude coding and everything. That's the thing that I don't understand.

So here's the thing. So number one, if we assume that these tools were trained on public code bases, like the contents of GitHub and whatever, then they were trained on reasonably secure code or at least decent security. It's not like they were intentionally trained to be insecure.

So that's fact number one. Fact number two is that Anthropic has this amazing Mythos that's amazing, and it can discover all these security vulnerabilities. Whether that's true or not, we can talk about here in a second, but why don't they use that technology and this technology to do the thing, right?

" That's a good idea, but it's very expensive. Mythos is- Oh ... it's brute forcing something.

The reason why Mythos is- But brute forcing is expensive, though. Well, Mythos is essentially brute forcing. The reason why, like I said, our product and other theoretical products work better is we're doing the pre-processing, putting intelligence in front of it to make better use of tokens so they're not burnt up.

Now, so we have to stop and consider, yes, putting it there is there, but it's going to increase and probably triple the cost of vibe coding and Claude code to do something like that. So what's so bad about that? We're supposed to be generating good stuff, not just cheap stuff.

That's still coffee money compared to what those vulnerabilities can cost us. That's the issue. But guys, I think we're short-selling what we're dealing with here.

Mythos doesn't only find vulnerabilities. In the wrong hands, it also creates exploits for those vulnerabilities, right? Because Ira, as you know, and Tom, as you know, just because something may have, quote-unquote, "a bug in it" doesn't necessarily mean it's reachable, exploitable, or anything else, right?

Mm-hmm. And Mythos, whatever, it's capable of all of those things. But I think, Ira, what you said is dead on.

At what price? At what cost? In terms of managing the risk, which is really what security is about, how much are we willing to invest?

And this predates AI, right? I remember when Mitchell and I were running Still Secure. Our test coverage for every six months, we had a new version.

Our test coverage was a dollars and cents decision about how many tests we wanted to run, how many different endpoints, what kind of scalability. It was a dollars and cents decision as to how well we tested. It's the same thing here.

Can we put Mythos into Claude Code, or... And I think AI is supposedly doing it with their version with Codex, but at what price? Yeah.

And it doesn't have to be Mythos either, because we're talking out of both sides of our mouth here. On the one hand, we have products that their whole pitch is AI can make your stuff more secure. On the other hand, and if we take that at face value and we say that's a product, then why can't we use that product?

And it doesn't have to be Mythos. You're right, Ira. Mythos is the big daddy, but what I've seen here is that a lot of people who are worried about using AI to find vulnerabilities are finding that older models find vulnerabilities, too.

In fact, there's a recent article here, the guy who maintains Curl, Mythos found one vulnerability. Why did it only find one vulnerability? Because that is the most secure software in the universe, because they are constantly looking for vulnerabilities.

And they didn't use Mythos to find the other ones, they used just other stuff, people or older models. Well- It doesn't have to be in Mythos. It can be any model, and- Well, Mythos- ...

we can have any model put security in here. Yeah. Well, there's a couple things.

First off, again, I'm trying not to be like a pitch man, but our company ran Mythos against... We ran our product against the same stuff Mythos did. Mythos found one vulnerability, we found four others on top.

So the Mythos model is good, Alan, you're absolutely right. It does what we don't do in many ways, and goes crawl through things that other products can't. But to the question, though, that you're asking, it doesn't triage.

It doesn't do what Alan, for example, mentioned, saying, "Okay, is it reachable? " And then it doesn't come up with a fix, and that's a more expensive problem. And so Mythos, like I said, would be pulling a Nelson, leaving developers who are untrained to find, understand the problem, and find a solution to go ahead and fix it.

That's why you need other people to do that type of work. But you're right. But right now, I think part of it is, it's still a new thing, and it's going to take a couple years to institutionalize it in ways it should be, in my opinion.

As I listen to you guys, I can't help but think of Ralph Nader and unsafe at any speed. Is that what we're really looking at? Well, yeah.

But let me... No. The security industry has existed in a state of fooling ourselves for a long time when it comes to, we know there's a lot of vulnerabilities, and we know not every vulnerability gets fixed timely, and that's the problem here.

Carm, I know you recently did something on the Security Boulevard podcast with the apocalypse, the vulnerability apocalypse. And I'm not here to spread doom and gloom, but put yourselves in the poor schnook who's the system admin who just got dumped, what was it? 472, 400 and something vulnerabilities from Google.

Last month's Microsoft Patch Tuesday had an outrageous amount of vulnerabilities. Guys, it's one thing for us to be pundits here and throw around a couple hundred vulnerabilities there, a couple hundred, but some poor schnook's job is fixing these, patching these, finding out should they be patched, should we leave them alone, should we not? That's work.

You want to talk about burning tokens? That's burning man-hours. Well, part of the thing, though, Alan, is that we've institutionalized.

This is why I watch the videos that Nicole Perlroth did when she interviewed the person from Anthropic, and the thing is, we've actually institutionalized a lot of fixes. Yes, in the larger companies, you do have to do the validation of it. But for the majority of organizations out there, just implementing the patch as it goes.

I don't know the last time I actually researched an iOS patch for my iPhone. I just let it run. Usually, I wait a day or two to make sure it's not going to crash, and I don't see news articles about people's phones being wiped because of the update.

But generally, it doesn't matter if there's one security fix or there's 472 security fixes. It's still one patch being implemented by most people because we've taken the process and institutionalized it. I don't believe there's the apocalypse.

There can be, that's a different topic, but we have a good institutionalization of fixing the problem, in my opinion. And we've had it since, God, again, I'm dating myself, with Bugtraq mailing list that was out in the 1990s. And we've been- And yet, most software is not up to date, and most of those patches are not applied in a timely fashion still.

And this is why it doesn't matter whether Mythos comes out with 472 patches on Mozilla because 87% of Mozilla users haven't updated their thing for the last vulnerability fix six months ago, or whatever it was. Because people aren't being hacked with zero-day vulnerabilities. People are being hacked with six-month-old vulnerabilities that should've been hacked.

And the problem is not how many vulnerabilities are out there. The problem is getting the solutions implemented. And it doesn't matter whether it's a solution for one vulnerability or 472.

Anyway, sorry, that's my soapbox. Iver, why aren't we shifting left on security with AI? Why haven't we, as part of, okay, fine, let the PM, the product manager vibe code, add this feature that keeps getting kicked back by the engineering team, and then we've got gates in our CI/CD that is going to apply security.

We've got a policy on what good code looks like. Let's pass it through that. Maybe we pass it through a model to look at security.

Why aren't we doing that? Why aren't we enabling more code? We are.

Again, I'll try and be a pitch. That's what my company's whole, like AIL stands for AI Shift Left. But it's like the concept- Oh, I get it.

I didn't know what it was. com after or what, but it turns out there was a reason. Yeah.

But the reality is, we're not the only people. The issue, though, is that- I didn't know that. I didn't mean to interrupt.

Oh, no. My CEO would appreciate that. But the reality is thatIt's a difference between people buying the tools and wanting to invest in the tools that do this.

And again, the functionality is fairly new, but it's also the concept that a lot of people, and this is something we haven't mentioned today, the bigger problem that software has is not your custom design code, it's the fact the supply chain code, because 90% of software- Yeah ... is not written by a developer. It's written because they pull in libraries from throughout the internet.

And a lot of these problems are software that most people are analyzing the software they create, not the libraries that they pull in, which comprise 90% of the software in most cases. Right. And so if you want to shift left, we just don't have to shift left, we have to shift left into another galaxy.

Right. You got to shift everywhere. But guys, we've got to shift.

Because we're stepping on our next segment. It's an important one. Sorry.

It's okay. No, I appreciate the passion as always. And this- It's my fault, Ira.

It's my fault ... no, Robert, you're never- No, you triggered me in a good way. That's fine.

But, John. Hey, our Tech Field Day brethren have been up to some work. Steven, I know before we go into what's past, let's talk about the future, as we do like a Christmas carol here.

Tell us, what does Tech Field Day of the future look like, Steven? Or the near future anyway. Yeah, the near future.

Absolutely. When you're watching this, so this week, Wednesday through Friday, we've got AI Field Day. We're going to be having a panel of folks interested in AI, including some folks from Techstrong gang like Garima, who is on here with me a lot, and Guy Currier and people like that.

Kate Scarcella's going to be there. And so we're going to be learning about AI. That's going to be streaming on the Techstrong TV app.

But it's been a busy few weeks. We had Security Field Day, then we had Mobility Field Day, and Tom is here. Tom was leading Mobility Field Day.

I got to say, this is my favorite because, yeah, there's AI, but there's also a lot of really cool, nerdy tech in there. So Tom, tell us a little bit about Mobility. Well, as luck would have it, Steven, we did get a little bit of chocolate in the peanut butter when it comes to Mobility this time, because a lot of the discussion was around agentic AI, and especially HPE now that they've acquired Mist and they were trying to roll those together with Aruba and create this HPE networking system.

They're talking about using agentic AI, not just to report on what's going on on your network, but to actually go out and proactively fix it. And they're starting to adopt the standard pieces that we've seen, MCP and things like that. They want to be able to effectively operationalize the network to say, "Okay, we're seeing problems over here.

" They used Waymo quite a bit as an example. We want to make sure that this is going to work that way, but also, we don't want to have a network that has a 95% reliability. We want to get to a point where it's going to be reliable all the time.

" The LLM doesn't know. What does weird look like? A weird PCAP, or does it even know how a certificate handshake is supposed to work, or what validation lists look like?

So that's one of the things that they're working on is they're working on training the systems to be able to do that, because Wi-Fi is getting, honestly, a lot more complicated. Little things like the new Wi-Fi standards require GPS receivers. Why?

Because they have to know where they're at and what's around them, so that when they contact coordinated databases to be able to turn up the power a little bit, they're not trampling all over things like satellite downlinks or ship-to-shore communications. And so being able to understand how all of those things interact is honestly kind of beyond what a person is capable of doing today. But one of the things that came up that I thought was really interesting was around private 5G, private LTE.

This is an interesting area. A lot of people have said for years you have to pick one or the other. You're either going to do Wi-Fi or you're going to do private 5G.

It looks more now like the private 5G companies are starting to use this as almost like an additional layer, a security type layer, because we heard from one layer, which is focused on the security aspects, but we also heard from one of our friends, Solona. And the Solona guys actually had a brilliant way to look at this. When you think about the way that these AI data centers are being built out, there's a huge focus on things like power and cooling.

And the less you can add to that area, the more that's available for all the GPUs. So Solona's actually starting to see people saying, "Well, why don't we do private 5G? " And they're seriously getting inquiry on that.

" That's what private 5G is designed to do. Absolutely. There was an AI security field day before Mobility, though, I think you mentioned, Steven.

Tom, as long as we got you here, it's not going to cost anything extra with the union. Give us an update on that one. Quantum is a thing.

We don't know when. It will happen eventually. A lot of companies are starting to focus on that.

I thought the Fortinet presentation, kind of speaking to the shadow coding, shadow AI aspect of things, was also super important. So here's a good example of how they're securing that. They're looking for MCP calls through the firewall, because MCP, obviously, if you're using it, you're probably doing something with AI.

So if it's an unauthorized call, then we shut that down at the firewall layer to prevent people from doing that. I also talked to a friend of mine. " But Quantum is out there.

Solving shadow AI problems is still out there. These are the kinds of things that, as security professionals, and honestly, Alan, you and I talk about this on "Security Boulevard" a lot on the podcast. We spend a lot of our time fighting the little fires, like, "Oh, I need to prevent my data from being accessed," and all this other stuff.

But just like Y2K, just like the 2038 time problem, these are out there, and if we don't think about them now, we're going to have to have a huge fire drill when the time comes to actually implement those fixes. Agreed. Hey, I just want to quickly mention, we have about a minute.

All three of those, the two in the past and the one coming this week, will be available on the Tech Field Day YouTube channel, on Techstrong. The one this week will be streamed live on Techstrong TV, as well as YouTube and LinkedIn. Also on the OTT app, which is a mobile app.

It's for iPhone and Android, as well as whatever you stream on Apple TV, Roku. We watch it on Roku TV in the office. Yeah, on the big TV.

So yeah, you get to see Steven in all his glory. I should mention that both the Techstrong TV and the OTT site have recently been updated, too, and they're pretty hopefully a little easier to navigate. So good stuff there.

But guys, that's going to wrap it. On behalf of our panel today, thank you for joining with us. Gang, thanks for joining.

Robert, Ira, Tom, Steven, of course, Mike, as always, thank you. Hey, we do this every day at noon Eastern Time, live. But if you can't catch us live, it is available on demand on the aforementioned OTT apps, Techstrong TV, YouTube channels, and all of the rest of that.

And I just wanted to close this out with one other thing. Yesterday was Mother's Day. Happy belated Mother's Day to all the mothers out there who nurture us and make us who we are.

So Happy Mother's Day. Until tomorrow, this is Alan Shimel. It's good to be back, but I'm out.