Swapnil Bhartiya: AI is now accelerating software development, which means patches and updates are coming faster too. But the teams and systems responsible for absorbing them have not changed. Your infrastructure was never built for this space. Anthropic’s Mythos expose something most executive already felt, but they have not faced it yet. Legacy systems, lean IT teams and a patching backlog that grows faster than anyone wants to admit. That Gap is exactly what Rack and has been focused on. Today we have with us Rob Hirschfeld, CEO and co founder of Rack and to talk about what executives need to rethink before that gap becomes a crisis. Rob, it’s great to have you on the show.

Rob Hirschfeld: Swap. It’s a pleasure and I really appreciate the executive framing here because I think that this is one of those cases where executives really need to be prepared. They need to be thinking about this, they need to be asking really hard questions about what’s coming because this isn’t the same environment that they’re used to working in. And you’re right, Mythos did fade from the news cycle. I am certain it will come back because there is a wave, a variable tsunami of patches coming as a consequence of this.

Swapnil Bhartiya: Of course, by now my thoughts has faded from the news cycle, but what it exposed is much bigger than the news itself. Forget that specific event. Can you talk about what has it actually revealed about where we are and what executives need to be thinking about right now?

Rob Hirschfeld: Well, I think this is the challenge, right? We definitely have a security chat crisis coming in. The fact that AI is going to be finding is finding issues in the current systems and it’s not a one time thing. It’s not like we’re going to find security issues and then fix all those security issues and we’re going to be done with the patches. This is an ongoing state of play for all security vulnerabilities. So executives need to understand that we are going to be discovering, hopefully on the good side, discovering and then remediating patches faster than ever. It’s not just like, oh, I’m going to wake up one day in June and I’m done with patching because Mythos has found all the issues. This is an ongoing continual state and that means these patches, we’re going to have a big round of patches that are going to be urgent coming in from the first pass, but we are going to be continually finding patches and vulnerabilities based on urgent ongoing scans and analysis of our own software. And so from an executive’s perspective, your question can’t be, can I deal with these patches? It’s actually, how do I change my whole stance on what’s going on? How do I make sure that I am ready for wave after wave after wave of patches and changes and security vulnerabilities that are coming in. And that unfortunately is just table stakes with the way we need to think about AI and change readiness for AI because it’s also intrusion detection in response to intrusion. Dynamic analysis. Right. It’s people that are zero days that are being discovered where we’re finding about vulnerabilities after the fact, not before. And what we’re seeing is we do more and more AI work our own normal development. So the whole rate of change of all software is going to accelerate. So we start this conversation from a Mythos perspective. But the simple fact of the matter is release cycles are shorter. You’re going to have a lot more releases that might just have simple bugs or other issues. Those have to go through your processes faster. So executives really need to be asking a question, not just mythos, but how prepared are we to accelerate our ability to absorb new software, new product, new capabilities? That’s the heart of the challenge here.

Swapnil Bhartiya: There are so many cases where AI is finding and it is going to find bugs that your teams did not even know existed. And backed actors will use the same tools too. So they will know before you know. So how should executive rethink their entire stack from the very foundation so security is no longer an afterthought? Where bad actors don’t win, it does by using the same tools that you could have used.

Rob Hirschfeld: There’s two forks on this question that I think are both important. So the fork first one is actually really good news for executives. They should be making sure that AI is scanning their products and their shipments for vulnerabilities like they’ve never seen before. So one of the benefits that we see directly, and this is rack and is a software company, but we see across the industry, is the ability for AI to scan and fix vulnerabilities to be part of your process that devsecops where you’re actually reviewing and analyzing your code that is much higher. Now. It does mean that you have to be prepared, that you’re going to find issues and bugs, security vulnerabilities and code you’re already shipping. And you have to be better at responding and getting those changes out. But executives should be asking their teams, how much scanning are we doing? What type of additional reviews and certifications and tests and checks have we added into the process for AI? In a lot of cases, one of the first wins that any executive should expect from AI is not to have AI writing more code, but AI reviewing more code, doing more analysis, doing those checks and scans. And so the likelihood that you’re going to find vulnerabilities in your code that you’re shipping or you’re using internally or you’re promoting that is actually much higher. And the vendors that you’re using, you should be holding them to higher standards to do more vulnerability checks and scans. So, you know, this is an interconnected component where we’re, we’re overall, you know, improving our ability to find, detect and respond to threats. Again, it’s always going to come back to, yay, I found something. How fast can I put that patch into effect? How many things does it break when I, when I update the software and move? So for, you know, executives need to be making sure their teams are leveraging these tools to the deepest extent possible and paying the money to make sure that those things are being assessed and then asking, how fast, when we find something, does it get into production? How fast do we put those pieces in? And I said, there’s multiple layers in here. The other thing about this is it’s important to not only think of code as the only vector here, especially with Mythos, there’s a whole bunch of hardening that AI can assist with, but not always assist with that come down to security. TSL certificates, your SSH keys, your password rotation, all these. There’s so much hygiene that your company needs to invest time in that is also part of this. Part of your protection here is making sure that you rotate your keys regularly, that you don’t have access and permissions that shouldn’t be in the system. Right. All of those pieces mean that your infrastructure has to be, be much more dynamic, that your, your level of maintenance and your, your operational discipline need to be upped to respond. And this might be a place where executives have always have never worried about assuming, you know, if your password rotation is right or your hygiene is right. That is, you know, a part of this security factor that people aren’t really thinking about. But we need to be concerned. If somebody penetrates your systems and you haven’t rotated keys in a while or certificates in a while, you, you could be compromised in a way that you’re not expecting. And that goes all the way down through RAID bios, firmware, out of band management. Right. We’re just going to have to be much. We can’t checkbox the security passes anymore. We really have to make sure that we’re pursuing them and on that note,

Swapnil Bhartiya: does security by OP security even hold up anymore? What does it really mean? Because no matter how you try to obscure the code, AI will find those bugs. So what should be the real strategy here when it comes to security by OP security?

Rob Hirschfeld: So this is one of the first questions I think that executives are going to ask and it’s a logical question, which is if we can’t trust the software that’s out there because it’s being scanned and has vulnerabilities, then should we just use AI to write our own, which is fundamentally security by obscurity. If you’re writing all of your own software, then nobody knows the vulnerabilities except your team. So you’re sort of keeping, you know, it’s like, well, I have a lot of vulnerabilities, but since I’m keeping them secret, no problem, right? I’m not, I’m not running the risk that somebody’s taking a library or product scanning that product and I’m getting infiltrated by that vulnerability. And so executives and I’ve had this conversation, so I know this, this is happening in boardrooms are asking, well, why don’t we just let AI write all of our software and therefore not be subject to these public vulnerabilities? And I understand the temptation. It unfortunately is a real risk for your company to take that on and make this assumption that oh, AI is going to write all my software ones we already know. And people have this experience viscerally. AI often makes assumptions, jumps to conclusions, shortcuts. It doesn’t think about things in the full context. And so what will happen is if you let AI write all of your software or really any component in the software that stack you have, it will add in vulnerabilities and problems and checks security issues, even some of them it’ll catch, but some of them it’s to going to miss. It’ll have bugs, it’ll have other issues that will make it into the process. Because the assumption in an AI development model is that you’re going to have a quick oops, I missed that, let me fix it for you pattern and you need to be ready for that. But the differentiator for any software vendor, and I think this is important for executives to ask these questions of their vendors is those software vendors have more exposure, but they also do more testing. They learn things faster, they’re checking. So when you’re working with a software provider like Rack n, because we are working with so many different customers, we are finding the bugs, fixing the bugs, reviewing security, we’re actually going through that cycle much more aggressively, very fast. It’s our differentiator is our test and our ability to validate and check. And so the extent to which our customers need to be able to take updates and patches as they come, that always is a, is a benefit to customers. But we’re going to be hardening our product a lot more than anybody would be doing if they were just trying to write it themselves. Unless they’re going to invest significant amount of time in testing and validating and doing security scans and reviews on every single piece of software they’re doing, and AI has limitations here, then they’re going to actually be building software that has vulnerabilities and scans baked in. And for what we do, right. Bare metal operations is such a foundational layer for your platform. And so if you have an oops, I missed that moment where you leave a port open or a key rotated or you’re exposing some information you shouldn’t expose on the machine machine. Very easy for AI to not even realize it’s having a vulnerability exposed and then that gets picked up as part of some other intrusion. Your whole, literally your whole castle could come down. And you have to be prepared that the attackers are going to have incredibly advanced tools that are going to scan and find vulnerabilities faster. So doing it yourself as a way of just saying, oh, we’re, you know, we’ll keep our bugs secret is really an incredibly risky approach for doing that and it won’t hold up to scrutiny and frankly, it’s not going to keep you safe.

Swapnil Bhartiya: Rack and is leaning heavily into AI Based on all the discussions that we are having here, what does that actually look like inside the company?

Rob Hirschfeld: I think what you’re asking is a really interesting point because we just like our customers are doing the, this work, we are in the vibe coding. We’re building a lot of capabilities into how the product works. And I will tell you very clearly, and I think this is a helpful thing, sort of executive to executive. While it’s easier to write code than it’s ever been, and that’s a fantastic thing, it is also easier to write code than it’s ever been, which means that you have to be better at testing, you have to be better at validation and checking. What I’m telling my team is use the bonus that you get from coding faster to actually deliver more quality. More tests, more validation, more integration tests. We need to make sure that it’s not just building more product, it’s delivering a fully integrated, tested, hardened capability. And this, to me, full circle is where we look at what mythos is doing. And we have to be better at building an integrated product than anybody else on market. That’s our differentiation is that security, that capability around it. And this, I think, is when you start looking at a software vendor or any vendor that you’re integrating with, you need to have full faith and confidence. Not that they’re adding every feature you ask, it’s adding every feature, testing it, validating it, running the security, security scenarios, making sure that it’s tested against as much of your own footprint and your own use cases and scenarios as ever before. And that’s how we use AI. The AI is not just about can you add more code, can you add a new feature? Frankly, our customers don’t really want us to go crazy adding new features, that’s more things for them to learn, more things for them to break as changes in process. Right. That’s actually not, not a benefit as much as reducing the effort and risk they have on. Can I take an upgrade? Because as we discussed, you’re going to be taking upgrades from all of your vendors and your own internal teams at an increasingly fast rate. And so our job, just like your internal team’s job, is to make sure that those upgrades are smooth, seamless, and low risk. Because you don’t have time. If you can’t take an upgrade, you’re vulnerable. So we have to be putting a lot of our time, and I would suggest executives need to be asking this question and thinking about this for all of their vendors and their internal teams. How much time are you putting into making those upgrade processes smooth and easy and not breaking my APIs and not letting your AI coding agents break something? Oh, I thought it would be great, great to change this API or the CLI command or add this new UX feature that nobody knows how to use. That in a lot of ways is going to cause a lot of disruption. Not in a lot of ways, it will cause a lot of disruption. And we use AI very aggressively to ensure that. We minimize customer disruption, we minimize security threat postures and risks, and that is how we think of these, these capabilities. And I think, you know, executive to executive, that is a big concern that you need to be asking. It’s not just how does AI code for me, it’s how do I use the coding bonus? Because we see a huge improvement in coding time, but our developers use that back for security scans, for testing, for integration. Right. We’re, we’re designing more carefully as a consequence, we’re not just dumping all that into writing more and more code or adding more and more features. That’s not beneficial.

Swapnil Bhartiya: Frankly, if AI is accelerating development across the board, that means patches and updates are also coming faster. How do you look at that? Is that a problem or a solution and an opportunity?

Rob Hirschfeld: I mean, fundamentally what Rack N does is we’re going to help customers maintain their bare metal infrastructure to higher levels of discipline and standards. We are seeing patching and the need to patch at every level of the infrastructure, come at a faster rate. And actually that’s a good thing. The challenge that we see, and this affects every software vendor, it affects open source, it inspires some very insidious ways, is that you have to remember that a lot of patches aren’t just fixes. They are behavior changes, API changes, new system behaviors or new capabilities that come in. And so it is very difficult, I would say impossible, to untangle a simple fix that changes behavior or fixes a bug. Especially if you’re bringing in new libraries or you’re adding in, you’re protecting yourself and some way from patches and fixes that change the behavior of your systems. A lot of times that behavior is a fantastic, you know, it’s performance improvements or a new capability or feature you’ve been wanting or some type of integration. But those patches and changes come with consequences of disrupting things that have been wired in to use those systems. And so it’s a Yertle the turtle, if you remember the Dr. Seuss book, where they have a big stack of turtles and the turtle at the bottom burps and the whole stack comes down. What you have to realize, and I think this is a surprise to some executives because we’ve done a lot building organizations in very isolated layers to try and protect from this. And those barriers are going to come crashing down because in order to take patches throughout your system, which you have to be ready for, those patches are going to change behaviors. Those behavior changes are going to impact other teams, as other teams are going to have to spend their time chasing the fixes up. And then that’s going to cascade into the teams around them or above them. And so what that means is that when we’re looking at this system, it’s not just as simple as I need to be better at taking a patch. You have to understand, understand that the systems that you’re relying on, their behavior is going to be changing at an increasing rate. This is one of the reasons why AI changing or adding features is not always to your benefit. A lot of times you want a Change that has the smallest fixes a problem and has a very small blast radius. And so your ability to bring in that change and then make sure it doesn’t, you know, it will disrupt other systems. To find what other systems are validated, have them do the patch and come in and the extent to which other teams are involved, you might put a patch in that the other team didn’t even realize was going to break them. And then they have to respond in a critical time to fix the systems that relied on that. This is one of the challenges that open source, right? If open source starts getting more patches, it’s very hard for them to distinguish between a feature change or a behavior change coming into that community that for one user might not be disruptive, but for other users might be a complete breaking, fall down approach. And so it is really critical for people to understand in this change, it’s not just can your team accept changes and patches better, it’s are they communicating with the other people who are surrounded by them? Is the software vendors you’re working with working to isolate their changes so that they don’t disrupt your business? And that takes a lot of work, right? We spend a significant, we have a lot of pride in this. We work really hard that when we make API changes, we work very hard not to introduce backwards behavior changes so that everything rolls to the forward. It’s an impossible task. We work very hard to have it be as small of disruption as, as possible. And you need to have a mindset here that understands that there is no isolated department that’s going to, you’re going to, you’re going to say go faster, do more patches. They actually have to build buffer and happily with AI, they should have more time available to absorb the changes and interact and communicate and have a systems approach to what they’re doing. You, you have to think very clearly and swap. You’ve been asking me these questions in a really thoughtful way and I appreciate this of using that AI bonus of time to put it back into human communication, human analysis, human design, more test, more validation. You can’t look at it as just, I’m running three times faster than I ran, I’m going to get to my destination three times faster. What you really want to be thinking about is when I get to that destination, am I going to have strength, readiness, preparedness, am I going to be in better shape than I was along the way? It’s not running it faster, it’s actually running it more. I would think of it as with more fidelity, but you should be in a stronger position every day because of AI, not just a faster position.

Swapnil Bhartiya: A lot of organizations are still deep in legacy environments and they cannot move at this pace. How should executives reframe that? What is the mental model shift that they need to make here?

Rob Hirschfeld: This is one of the things that we’ve been pointing out. And having a lot of legacy infrastructure is very hard and I don’t think it’s an acceptable answer to tell people to burn down what they’ve got. We used to see this a lot in the cloud native times. We’d have conversations like, well, I don’t care about what you’re already doing doing, do it the right way. And there is no right or wrong way. These legacy systems are working. They add a lot of value. And I think companies need to look at how they get these legacy systems updated and patched as soon as possible. The idea that you are going to stay two revs back on a system is not sustainable. And that means that you’re going to have to have systems that allow you to, to bring up these legacy vendors. You know, if you have a legacy vendor that’s no longer getting support and patches, that’s a problem. That has always been a problem. But most of these legacy vendors are still from active, they’re still active, they’re still putting out new things. But companies have chosen to take updates and patches more slowly. That will no longer fly. But, and this is a huge but, you will never get ahead of what’s coming with AI one patch at a time. It is not possible. So you can’t take a patch and wait and a patch and wait mindset to fixing these problems. So for every executive who has a mixed environment, which is every executive, you have to look at these systems and automate first. And this is something that we’re talking with racking customers about every day, all the time. They’re very afraid of automating first and then patching. What we have seen over and over again, and we work very hard at this, is that you can bring the automation platforms in beside your current systems and pull them into automation. And that is actually a much more effective way to address how these systems work. Because since you need need to get into a continuous automation, a continuous patch process, build that process first and then start applying the patches. If you wait. And we see this happen all the time, right, we’re too busy to automate because we’ve got to get all our systems patched, we’ve got to get these new things online, we’ve got to build These clusters, we’ve got to figure out how to do kubernetes. And they don’t start from the foundational levels and then build up. They’re trying to build from the software, the platform layer down, and that actually never, they never catch up. And what we’ve seen over and over, if you build the automation first, if you get the bare metal layers right, you’re building on top of your OS deployments and everything’s automated. The layers above that just flow naturally, faster, dramatically faster in most cases for these customers. And so that is really my advice here, is that you’ve got to break, and only an executive team can do this. You’ve got to give your team the push and the space and the incentive to automate these problems first so that they’re not just getting, oh, wait, once I fix it, then we’ll automate. Once I fix. That does not work. You have to automate and then fix it. You have to give your team time to say, get the automation done. You’re going to be patching, patching, patching, patching. And if we don’t fix that core problem, we will never catch up. That’s what mythos has really exposed here, is it’s a new state of play for everybody. You have to assume you’re going to be getting a constant stream of updates, and that has to be built into your processes in a way that it never was before. And not just for your own software, but for every product, every IT product that you have in market. The bios, the raid, the firmware, the configuration, the architecture, the system, certificate rotation, right? All of these operational disciplines are no longer optional, and you can’t treat them as optional.

Swapnil Bhartiya: Now, let’s talk about the easiest or the hardest question. People process technology. Where does the real problem sit when we talk about AI and how does rack and actually help organizers move differently without just adding more pressure, more code, throwing more technology at them?

Rob Hirschfeld: At the end of the day, we always know it’s a people problem, because if your people aren’t on board, aren’t thinking correctly, then they can’t fix other pieces. What we know over and over again, and this is an important part about one of the innovations that Rackn has made here is we are a bare metal platform and we distribute the automation as part of our product. So unlike any other product in the market, from an ops perspective, where you write custom, you buy a product, and then you write custom automation, our most effective customers have incredibly low customization rates. They’re only adding 1 or 2% changes into the product in very specific places so that they can stay on our process. They get part, they’re part of that automation. And that has really been a game changer for our customers. So when, when we’re running the world’s largest AI infrastructures, the world’s largest virtualization infrastructures, which are two of our top customers, we are using the same processes. And anybody calling up and becoming a new customer gets the benefit of those standardized processes right out of the box. The challenge is that process change is an incredibly emotional response inside your organization. And this is another look, if you’re an executive, you know how hard it is to change and fix process. And we watch people say in one sentence, I can’t stand my process, it’s so broken. I can’t believe we do it this way. And then turn around in the next sentence and say, but I’ll never change it because we do it this way and we love our process and it’s ours. The challenge for any executive here is to get to a point of saying, is that process working for us? Are we defending? We built this process brick by brick over a decade and it’s reinforcing these patterns of patching, patching, patching, and it’s getting in your way. And so it really takes a push for an executive to make it okay to embrace a standardized process. What we’ve seen is that when we sit down and, and show up with a standardized process and a team that’s ready to say, we want to learn your process because we know that it’s faster, more effective and battle tested compared to the ones we’re using. We know that that customer is going to see dramatic improvements in results. Right? We’re seeing 10x20x improvements in provisioning time and reprovisioning times and reliability of that process. But you can only do that if you’re able to, you know, look at your own process, give up what’s not working. We work with customers all the time to incorporate things that they have high effective good processes or required integration points. That’s normal. And you have to look at that overall process and say, can I offload some of that? Can I get things? Can I use industry best practice and rock it forward? We do it for bare metal. There’s other companies that have standardized processes. If you want to compete at AI speeds, then a lot of what you’re going to be looking at is not saying, oh, AI is going to figure out all these pieces. It’s do I have a standard working process that can be tested and validated like crazy by AI, but just works deterministically. And I’m confident in those. Become the foundational bedrock for your business because you’re not adding any business value. You don’t want AI to be figuring that out. You, you don’t want an oops, I didn’t realize that that’s a place where you’re going to see a lot of acceleration. That is a place where we have really been able to help customers just go much faster with kubernetes deployments where machines just come online and join clusters even though they’re coming from bare metal. That’s game changing. And companies inventing that process themselves have to learn, build, have to have a lot of capacity capabilities around it. That’s just one example. Over and over again, these standardized processes

Swapnil Bhartiya: are the game changer for the executives watching this right now, sitting on a sprawling mixed stage infrastructure environment. What is the one conversation they need to have internally this quarter?

Rob Hirschfeld: First, one of the things I think is that executives should play with these technologies. It is very useful to get some hands on experience and understand just how powerful they are. And you should be looking at the cost of what you’re actually spending behind these scenes. Even if that means you have to get a personal account and watch the token burn. Go up and see how often you have to put dollars in the machine to buy tokens. Having that as a visceral experience is absolutely essential for you to understand what’s coming. Because for executives, they need to understand viscerally that these new AI platforms and systems, the way we’re treating them with agents, these are new workers, these are virtual people, they’re machines, but they’re virtual workers in your organization. And what you will find very quickly is that when those workers aren’t working, your systems are going to stop. Your integration, your checks, your validations, your engagement is going to stop. And so having a reliable source of tokens and AI infrastructure is absolutely essential. And you’ll go a step further and start realizing that if you’re dealing with a third party and they can change their model and the performance of your systems changes overnight because somebody has changed their model, or the costs change overnight because they’ve deprecated one model and moved you to a second model and your costs all of a sudden are 3x or 4x, these are very real concerns that executives need to be understanding. It’s important to have a visceral understanding of it so that you’re seeing just how problematic it is when you don’t have AI or The models change. But take my word for it, you need to have a strategy for a hybrid LLM hybrid AI capability where you can control cost, where you can control models, where you can have some choice and variability using frontier models where you need high reasoning, but falling back to open models or models under your control that can do routine predictive tasks within your system. If your organization is isn’t already looking like that, I can promise you it will be coming and you need to be thinking about how you have access to the underlying infrastructure. Your organization has access in a predictable way. We’ve had high stakes IT systems before. Access to an LLM, access to these AI platforms to make your virtual workers work is going to be more essential or as essential as it is to having Internet access in your office, office buildings and AC and cooling. Because if they’re not working, your workers are fundamentally out of, you know, on the street, waiting for the fire alarm to be over.