Name: Surviving the AI Code Explosion: Why GitHub Backup and Recovery is a Prerequisite for AI Adoption
Uploaded: 2026-05-14T12:15:12.328Z
Duration: 1 h 15 min 4 s
Description: Surviving the AI Code Explosion: Why GitHub Backup and Recovery is a Prerequisite for AI Adoption

Transcript for "Surviving the AI Code Explosion: Why GitHub Backup and Recovery is a Prerequisite for AI Adoption": Hello, everyone. Welcome to today's webinar. I'm Pradeep Saran. I'm the product manager leading the efforts for DevOps protection here at Rubrik. I spend most of my days talking to CISOs, CIOs, and IT leaders about how to keep the businesses running when a disaster strikes. But to really understand about the disaster we are talking about today, I needed help from engineering perspective. So I'm thrilled to be joined by Courtney, a principal engineer who lives and breathes this space every single day. Hey, Courtney. Thanks for having me, Pradeep. Good to be here, and not sure you need so much help, Pradeep, but let's, let's see where we go from here. So, Courtney, you and I were chatting the other day about how dramatically the concept of engineering has shifted in the last few years. Right? When I talk to some old school IT folks, they still think of GitHub as a simple storage locker of sorts, a place where developers just check-in their code at the end of the day, and that's about it. But that's not the reality anymore, is it? Things move so fast, and we'll be talking even in weeks and days these days in the development world. So for my team and really any modern development team, GitHub is the absolute nerve center. So it's not just the source code. Right? It's, how we get that to production through the CICD pipelines. It's GitHub actions. It's infrastructure as code. If GitHub goes down or if that data gets corrupted, entire ability to build, test, and deploy the software that we're building completely stops. So it is the innovation engine, I guess, you could say, of of the enterprise. Absolutely. Yeah. So right now, that engine that you're talking about is being pushed to its absolute limits by unprecedented shift that we are seeing, which is rapid adoption of AI that we are seeing. We are hearing a lot more about large language models and not to forget autonomous coding agents likes of Cloud Code. We we hear this every single day. We know every single enterprise that's listening today is somewhere on that AI adoption spectrum. Right? Some of them may be just getting started with a POC of sorts or some of them would be already in fully. But the macro numbers that I'm seeing are, like, mind blowing. Some data that I have in front of me where 97% of developers have used AI coding tools at work already. That is that is a really big number. We are seeing this explosive volume and rapid evolution, code because of these coding assistance and fully autonomous agents, which is basically causing all the risk. That's exactly what we want to protect and how we build a safety net to protect ourselves. Let's start with where the enterprises are right now. To understand the risk, we have to look at how this technology is actually being deployed on ground. We see many organizations are already heavily relying on basic autocomplete or AI assistance like Copilot to generate the code already, while many tech forward enterprises are moving entirely to AI native IDEs, likes of Cursor, Windsurf, and so on. Across the board, companies are reporting up to three x increase in code output with these tools. But this massive velocity increases something called as volume quality paradox, which puts us in shoes of our engineering manager. So, Courtney, what does this three x increase in code output actually look like from engineering or a development strategy day to day? Yeah. I mean, Pradeep, you've you've mentioned some huge numbers. Right? And we're seeing huge volume increases across minutes, as you said, across code production. And, honestly, all of that completely shatters the the human dependent sort of safety nets that we have in place within within these code bases. Right? So you have to remember, right, so for most organizations, the standard sort of software development life cycle, So, you know, the code views, the QA processes, it was all built around, you know, that human pace sort of code production. Right? So on a day to day level, an engineer would sit down, say, write a feature after taking input from something like Jira, reading the acceptance criteria, and then submitting a pull request that's maybe, you know, 50 to a 100 lines of code. And that's digestible for, I wanna say, another human, if I if I can say that. We we, compartmentalize, these two, actors here. And, you say the other you know, the human can read that, understand the context, and and spot the flaws, and, either, you know, approve it or or provide feedback. Right? But now flipping that with with AI assistance, we're now seeing developers, generate, you know, 500 to, say, 5,000 lines of code in a single afternoon session. Right? And so that can be across multiple pull requests or even in one. Right? And, I tell you what, I'll be honest. As a code writer, a lot of the humans don't even know what what they've produced in those lines of code. Right? So they haven't even read every single line. Let me stop you there, Courtney. Did you say 5,000 lines of code in a single afternoon? Yep. That is wild. Right? From security and compliance perspective, how do you realistically even review that? Like, looks like there's going to be more code or or developers are spending more time reviewing the code than writing the code itself? Yeah. I mean, that that's right. And so I think the honest truth there might be that you don't review it as well as you could or you even don't get through all of it. Right? And it you know, so it completely overwhelms the human sort of review capacity. And there's hard industry data showing that once a pull request crosses that sort of a thousand line threshold, human defect detection drops to around twenty eight percent. I think I'm nowhere near that a thousand line threshold personally. So, you know, even even my poor request reviews haven't been as good with AI around. Right? And the reviews, you know, that are doing it across the board are experiencing incredible fatigue. So they look at this massive wall of AI generated code, and they see that the basic sort of tests have passed, and they just go, okay. We just rubber stamp that, approve it. You know, Claude must know what it's doing. Right? So we are basically shipping more code, but we are effectively reviewing it less. That's what it sounds like. It seems to be like a recipe for disaster. Also, I'd like to understand about the quality of bugs themselves because AI is supposed to be the perfect code writer by itself. It just doesn't make typos, and it sounds all good. You're right. Pradeep, that's the paradox. Right? So it's, it's fantastic at reviewing or eliminating these cello bugs. And so, you know, quick ones to work on and fix, you don't really see, like, the syntax errors or the missing semicolons anymore. But then it trades those shallow bugs for the incredibly more deep logic typically in these larger code bases. Right? So it needs to understand the full context. In fact, recent studies show a a 153% spike in architectural design flaws in AI assisted code itself. Wow. That's huge. And, why is that? Why does it fail at the architectural level? Firstly, you have to give AI deep context. Right? And it lacks that without being set up correctly. So if you're a brand new start up riding a greenfield app, AI is great. Right? It doesn't need to have much context. But most enterprises are sitting on ten year old legacy code bases filled with tech debt and weird workarounds and bug fixes that it wouldn't have the entire context for. So the AI companies know this, which is why, you know, tools like Claude Code, as we keep referring to, introduce this concept of context hierarchy or markdown files to try and teach the AI about your architecture. Look. Here's the most disappointing part. I'll be honest with you. Even if you feed it the textbook and skills and and this context and you give it all that context together, it can still hallucinate. It takes a long time to generate all these markdown files and give it context. And so, you know, we we're finding that Claude can actually get overwhelmed by having many different skills that it needs to check out and get slower, and there's sort of a nested complexity that forgets the sort of core ideas and hallucinates logical accidentally and introduces, like, a privilege escalation path right in the code. And so, potentially, the code would compile beautifully. Unit tests might pass, but then the underlying architecture can be deeply flawed. And quietly, those bugs or even worse still, those flaws and hacking vulnerabilities can actually make it into the main branch. So looks like we have a massive volume problem and a hidden quality problem by by the looks of it. Right? So many organizations are still grappling with Copilot. I I hear a lot of companies are still using Copilot, and the bleeding edge of development is already moving towards the the next frontier, which is the fully autonomous agents, tools like Cloud Code, Win, and Copilot agent mode. So this inflection point where the risk profile doesn't just increase, it completely changes the game. So the new reality is that the agents are acting as developers themselves. Adi, can you explain the difference between an agent and an assistant and why this changes the game for security completely? Yeah. It's a good question to sort of understand the context. Right? So the difference comes down to, I guess, the autonomy and permissions. So with an AI agent or assistant, sorry, the AI suggests the code, but, you know, I, as the developer, still in the driver's seat. So I review it, I stage it, and put out for PR, and I explicitly committed to to GitHub. An agent, on the other hand, assumes an actual identity. Right? So you could almost think about it like a human, but with its its own identity within the whole software, development life cycle. So it executes multiple multi step tasks across, an entire code base autonomously. And the most terrifying part of these agents is that they have full Git write access to your repositories. Right? So they're like a developer. They have they have everything they need. So they can read files. They can spin up test runners. They can stage code, commit it, and and push it directly to your GitHub branches. So, really, that, you know, introduces two massive problems. The first is that agents can simply take or make destructive mistakes, Something that, you know, you were relying on a human not to make. It it could make those and does. And we literally just saw this happen with a major cloud provider recently. Their internal AI agent, I think it was called, Hero encountered an error in an environment and autonomously decided the fastest, most efficient way to fix the error was to run a delete and recreate command, on the entire environment. So it wiped everything and caused the thirteen hour production outage. Delete and recreate. That's a perfect example of a harness mission speed mistake I like. That's right. But you mentioned second problem. So what really happens when the malicious actor gets involved to this mix? How does an agent fundamentally change the attack surface compared to a traditional attacker or a human driven attack happens? Yeah. That's a great question too. Right? So it's it's really the attack at scale. Right? So it explodes that attack surface. So think about it the old way, the human driven attack. Before AI agents, if an attacker wanted to compromise your code, they had to go through, like, a rigorous five step process. They had to fish a developer, steal their credentials, manually read and understand the code base, write the malicious code themselves, and then somehow evade, you know, human code review. So it is quite an effort. Right? And a bit of a a massive human effort and time. And, how about with AI agents? Yeah. So then, obviously, with the agents, the attacker can bypass almost all of that effort. Right? So we are now tracking sort of six or more attack vectors, where the attacker leverages the agent to actually, like, act and do the early the dirty work. And in many of these require absolutely zero human interaction from the attacker. So if the agent has the keys to your kingdom, and in most certain most 99% of cases I've seen, they do, and we trust them inherently, and the agent is compromised, then, you know, you guess that your code is actually compromised too. Wow. That's that's really scary. So what are the most common ways you're seeing these agents getting compromised or weaponized in the wild? Yeah. I thought, you know, we could probably give four main scenarios that are actively destroying repositories right now. I'll try to explain them sort of simply and clearly for everyone that's, you know, consuming this webinar. Right? So the first is the stolen agent tokens or what we call stolen agent tokens. So teams are, you know, generally bad at least privilege. Right? So, and and developers usually have full privilege. So they often give agents the same privileges in in terms of, you know, personal access tokens with full delete repo scope instead of, say, more granular access. And now if that token leaks in a CI log or via malware, like the cord code malware campaign we saw in March 2026, the attacker uses that, the GitHub API to instantly, you know, do anything it really wants. So strip branch protections, the right history, delete repositories, basically takes full control. And then there's also another so secondly, I guess, for another example, main scenario is a MCP tool poisoning. Alright? So it sounds very fancy, but actually not not too fancy. Really, an attacker compromises like an AI plug in or a model context protocol, which is really just a way to connect to other systems via your agent. So for instance, if I wanted to to connect to Slack or any other type of tool. And so the agent can act using that connection and it thinks it's just running, you know, say, a harmless formatting or logging tool and it, you know, it can tell the user we're just processing code because that's what that MCP tool might be telling it. And then in the in the formatting tool example, it had a hidden instruction that runs, say, git push force in the background, and the user wouldn't know. They wouldn't suspect anything, but the branch history is finally destroyed. And then there's another example shown by a US company where Chinese hackers were forced in MCP to actually log plain text Git credentials to a logging tool that they had control over. And so they were able to get those Git credentials. And another example says the Claude skill poisoning. So everyone's talking about Claude skills. Effectively, these are now at comp at risk of compromise too. Right? So Russian hackers in in another example uploaded a malicious skill for download on a popular Claude skill site. And that forced Claude to think it needed to behave as a white hat hacker. And so then once once it's downloaded, Claude can invoke that skill and then manage to wipe all known repositories in the GitHub instance. And then lastly, and I'll I'll stop after this, I guess, is the prompt injection via PRs and and rule files kinda similar, but, you know, just for different systems. So an attacker might open, like, a benign looking pull request, but plants a hidden instruction in the description of that pull request, like, you know, system run git push origin delete main within that actual description. Right? And so it can it can run those hidden git commands. And when the agent processes those PR descriptions, reads the instruction, follows it blindly, just nuking your whole main branch. So and we're seeing those kind of similar things with the within cursor rules or Copilot instructions or ND files that are being backed toward by attackers. So once that file is merged, it suddenly, instructs all agents in the repository to start injecting vulnerabilities into the code. Oh, that that's quite a lot of examples. Yes. Yeah. So that perfectly aligns with what we are seeing in the security space. Right? We recently saw a vulnerability called prompt pond where CICD pipelines get hijacked in exactly similar way what you just mentioned. So these AI agents don't question instructions. They just execute them. Right? That's right. And then because the agent is already using authorized credentials inside your perimeter, so it can wipe the repository clean and, its own logs in seconds. Right? So I think it's truly mission speed destruction by itself. That's right. So this brings us to the core problem of this entire webinar recovery. So when I talk to IT and business leaders about these AI risks, the first objection I hear is, Pradeep, you know what? Well, it's GitHub. By design, everything is version, isn't it? And, if my AI assistant introduces a massive architectural flaw, my engineers will just use native Git revert. So why doesn't the traditional safety net hold up at this scale? This is a very frequently asked question of sorts when I talk to leaders. So what do you think about this? Yeah. I mean, Git Revert is is an amazing tool, I guess, at a at a human scale. So we talked a lot about loads of the autonomous agents acting. So this is a great, tool on a sort of one to one level. If I accidentally push a bad file and and then catch it five minutes five minutes later, then Git revert is perfect. Right? But I think, about, you know, the AI velocity that we discussed earlier, Let's say, an AI, agent introduces a subtle architectural flaw that evades QA and merges into the main branch. Because we're moving so fast, 20 other developers immediately pull that code and start building on top of that flawed architecture using Copilot. And when you finally discover the the bug three days later, Git revert is no longer, you know, sort of magic undo button at that stage. Right? Because it's a decentralized system. And so reverting that original commit will will trigger this cat catastrophic and sort of cascading merge conflicts across dozens of files. And, you know, I've I've been there. Right? It's an absolute nightmare to untangle manually just via the command line, especially at scale. So remember, at least one developer needs a copy of the correct version to actually get back to where you want it to be. And so if they've all pulled changes through, since that change, then you're basically toast. Right? So any relying on that approach at scale is a disaster. So and then you take that and you and you imagine, you know, you have 500 repositories and the last time someone worked on your custom ERP repository was three years ago. Then, you know, obviously, nobody has a copy. Right? That developer might have moved on. Yeah. That, makes total sense with a bad code scenario. But, what what happens when the whole thing gets escalated to the agent threats you just covered? Say, likes of prompt injections or the wipe and recreate kind of scenarios. Yeah. And that's where the native version versioning sort of, protocols go from difficult to, I guess, impossible. If a hijacked agent runs git push force or maliciously deletes the repository, then your version history is gone. And the fundamental flaw with relying on that git history is that the history lives in the exact same domain, the exact same system that the agent just wiped. Right? You can't use version history to recover if the version history itself was the target, especially if not one developer has a copy locally. Got it. So that that leads us to a very uncomfortable question. We we ask IT leaders this all the time. If a compromised AI agent wipes away all your branches, force delete all your repositories, first your git history tonight, and nobody has a local copy in place. How will you recover tomorrow? Right? So that's the most important question or I would say uncomfortable question. Yes. And I mean, we're talking about the absolute worst case scenario here. It doesn't make make one feel good. It makes me feel, almost sick inside thinking about it. But, you know, that that question is usually met with dead silence from from the customers, right, and potential customers. So most teams will instinctively say, well, you know, we'd restore from and then my immediate follow-up is always, like, well, restore from what? It's gone. Exactly. So because the reality is most organizations have absolutely no real DevOps backup. Yeah. Yeah. I I feel we should spend some time here to break things down, because it's a very important, piece of information about there are a lot of dangerous myths out there about how my data or everybody's data is getting protected by GitHub. Right? Myth number one is always GitHub is in cloud, so, obviously, Microsoft should be taking care of it by by by themselves. Right? Yeah. And that's a common, I guess, misconception or understanding even as well. Right? So GitHub is a fantastic SaaS application, so software as a service. Remember, you're renting it as a customer, but it's not a backup service. Right? Just because there's version history there, it doesn't mean that it's backed up individually. So the share what they call the shared responsibility model, you can you can go and Google that applies here. Right? So they guarantee that the entire platform's infrastructure is available as GitHub. But if your authorized AI agent or the stolen token issues that we mentioned before, like, delete a repository, then the platform, does exactly what it's told. Right? The data is gone. True. Yeah. And, the second myth I keep hearing this, Pradeep, you know what? My developers already have a local copy or a local clone on their laptop. So if, as you're saying, if the main branch gets wiped out, we'll just reclone from the copy I have. This is another common myth I hear from leaders. This is probably the most common thing I hear on on customer calls. Right? And so, you know, relying on a local clone and I must just add one that is is up to date, you know, assuming my previous example about you having 500 repositories and so therefore, you know, you've got every single update on a local machine somewhere. Right? It's fundamentally impossible to do at scale and, you know, stay a stale repository is is hopeless in this case. So it's really just the source code. So it doesn't contain, you know, your CICD pipelines, your GitHub actions, your secrets, your web hooks, or even your branch protections. Right? So it's just the code. So even if you did have a local copy, you gotta make sure that, a, it's up to date, but, b, there's no ways you would have all the rest of it. Right? So if you lose all those pipelines and actions and things that I mentioned, your engineering team is completely paralyzed. Right? So you also have that recovery sort of time objective issue as well. And then furthermore, if the attacker has your credentials, they can access and wipe every fork you have anyway. Yeah. Correct. Yeah. And, the other thing that I hear is, what about the teams that try to build their own backups? Right? There are some smart people out there where they say, you know what, Pradeep? We we write our own scripts. Right? So we make sure we you have a Python script which backs up the code repository, and then we push it to, say, s three bucket or blob. What what do you have to say about that? Yeah. Probably the second most, heard objection or, I guess, thought in a customer, meeting. And so I've seen a lot of or heard about a lot of these homegrown scripts. And and I'll be honest, that it's a great idea at first as a first sort of stage of defense, but it is a bit of a false sense of security if I'm honest. They rely on, say, personal access tokens that expire. They can fail silently in the background. No one actually notices until it's too late. Right? Until you need that backup and you realize, I don't have it. And the the biggest issue, I guess, with them is that they aren't immutable. So if an attacker or rogue agent compromises your environment, they have exactly the same blast radius as your production data. So they can just easily log in and delete your s three bucket exports. So, Cody, let's recap here. Right? We we spoke about a lot of things. Recap the reality we are facing at this moment in time. So we have unprecedented AI code volume out there, agents making autonomous destructive decisions. And so this makes native GitHub tools or your Python scripts that are simply aren't built for enterprise scale recovery. So this is what I understand from, our conversation. Yeah. So that's exactly why we built Rubrik DevOps protection today. Right? So organizations are going to adopt AI coding tools and autonomous agents, like, SoftCloud, which have to to stay competitive, they need an absolute unbreakable safety net out there. Right? Let let me break this down, how we solve this problem. And, Courtney, I'd love your thoughts on how this changes the whole game for your teams completely. First and foremost thing is cyber resilience and immutability. So you I remember in your conversation, you mentioned about immutability. So what we do is we take your GitHub data out of the blast radius first. Right? And we backup your repositories, your branches, your GitHub actions to your own s three or blob storage. Right? And we apply object lock, which is warm, write ons, read many technology of sorts. And we also have a fully hosted option, which is completely air gapped. Right? So which sits in a Rubrics tenant with all the guardrails, likes of encryption, immutability, everything is taken care of. So what do you think about this? Look. I mean, I can't I can't stress how critical that air gap is. Right? So if the version history lives in the exact same system that the rogue agent or the attacker just compromised, then the history is useless. Right? So having having that data separated where it literally cannot be modified or deleted is really only the you know, it's it's it's the only true fail safe you can have. Absolutely. Absolutely. Yes. So, yeah, it is completely immutable. So even if a agent's agent runs completely rogue or an attacker compromises your GitHub admin credentials, which is the most common scenario or threat that we see, they cannot delete or encrypt your backups which are sitting in Rubrik's tenant, right, Or Rubrik's backup itself. Right? That brings us to the second most important pillar, which is SLA driven automated protection. You spoke about those Python scripts. There are brittle, and there are a lot of issues out there. Right? So that's where we we came up with SLA driven and automated kind of protection. We we get organizations out of business of managing brittle Python scripts, and, you authenticate Rubrik via secure OAuth app, which is using oauth2.o, and it automatically discovers all your GitHub organizations and repos. So one single click, we install the app, we discover everything, and then you apply a policy to that. Say, for example, backup my code and other metadata every eight hours, and that's about it. So think of it like this. If a if a developer spins up a new repo, or two or your agent spins up a new repo, Rubrik automatically sees that, and it it protects it immediately. So no one has to remember or go back to your Python scripts, add that new repo to start protecting and things like that. It's fully SLA driven with automated protection. Yeah. I mean and that that alone saves the platform engineering teams hours of maintenance. If if agents are running at full scale, then we're seems like Rubik Rubik's automated protection is also running at full scale. Right? As fast as the a AI agents can run, we can we can run too with, you know, auditing, and the maintenance, as I mentioned, every single week. And the the third pillar is flexibility. One click recovery. Right? So recovery plays a very important role with the whole backup ecosystem that we have. So think of it when a AI disaster happens. You don't have time for engineers to write custom restore scripts or to untangle complex git commands. Right? You log in to Rubrik in a typical scenario. In this case, you log in to Rubrik. You know when the disaster happened. Select that point in time, and you choose the snapshot right before the corruption and hit restore with a single click. Courtney, how does having this level of flexibility change the recovery conversations Yeah. It changes everything. Right? Because it matches the scope of the actual disaster. What I'm trying to say is if an AI agent or assistant corrupts a single repository, we can then do a targeted sort of repo level restore and bring back its entire history without impacting the rest of the the business or the other repositories. But if an agent or attacker wipes out the entire GitHub environment, we can scale that up and recover at the organization level just as easily. Exactly. Yeah. But we know disaster aren't always limited to just your data. Right? Sometimes it can be at the platform level itself. So just reading through GitHub releases these documents. They talk about, I think, monthly reports that talk about the outages that they had. In the last year, GitHub alone had over seventy hours of documented outage. Right? That's pretty huge. Again Wow. There are service disruptions on top of that. That's why we also recently launched cross platform recovery. From engineering standpoint, why is that capability so crucial for you? Yeah. I mean, I didn't actually know it was it was up to seventy hours. So, I mean, that that's huge. Right? But we can't really afford to have that sort of downtime across, you know, large organizations. So I guess the cross platform piece that you're talking about is the ultimate insurance policy. So just thinking out loud here if there is a catastrophic platform wide outage on on GitHub or, you know, we lose access to the environment entirely, being able to recover the repositories and pipelines to, say, an alternate DevOps provider like Azure DevOps or something like that means we can completely bypass the downtime. So we don't lose days of engineering velocity. We can just keep the business running. That brings us to the final pillar, which is enterprise readiness and compliance. So you can't protect the enterprise innovation engine with fragmented solutions that we discussed earlier. Rubrik is built to handle that massive, massive scale. There are customers who have more than 50,000 repos. So protecting up to 50,000 repos is a huge scale. Plus, we bring robust compliance reporting, alerts, and platform security features like granular RBAC and retention logs and, Quorum authorization to prevent rogue deletions rogue deletions of the backup themselves. Yeah. And I think that's the key point that we're talking about today in the webinar. Right? Is that these backups are the best at scale. Right? So when you have thousands of developers, thousands of AI agents, thousands of repositories, that scale and auditability that you mentioned is absolutely non negotiable for security teams. Which brings us to the core realization of this entire session. Enterprise grade GitHub backup and recovery is kind of foundational requirement for successful enterprise wide AI coding adoption itself. So you basically cannot scale one safely without the other. Yeah. Great. Agreed. Yeah. To summarize everything that we talked about today, one is AI is fundamentally transforming the software engineering itself. Right? Whether your teams are heavily leaning on Copilot assistance today or you guys are looking at experimenting with fully autonomous agents tomorrow, your GitHub innovation engine is moving faster and carrying more risk than ever before. Right? So Yeah. You cannot simply rely on native versioning history or your homegrown manual scripts to protect against mission speed mistakes that we spoke about. Right? You need a foundational safety net to support that truly AI adoption that we are seeing. Right? So with Rubrik DevOps protection, you close the cyber resiliency gap with complete air gap immutable backups. Yeah. That close the data protection gap with automated SLAs built for scale, say, 50,000 or beyond repo backup scale, and you ensure your engineering teams never suffer extended downtime with flexible cross platform recovery. Yeah. I mean, you could you couldn't have said it better. Right? Ultimately, my goal as an engineering leader is to to be an enabler. Right? I want my engineers experimenting with cord code, cursor, copilot, whatever the agent might be. And you want them moving fast. Right? And you want them to break boundaries and be able to push code, you know, safely and having that rock rock solid enterprise grade backup as you alluded to, means that we can fully embrace that AI evolution without, you know, constant fear of anything in that space or any catastrophic mistake that that agents or any other AI might make. Right? So it lets us, I guess, at a high level innovate safely. Yeah. Well said, Courtney. So it is the ultimate enabler for AI adoption. Right? Yeah. So I think that brings us to the end of the session. You found this session valuable and you want to ensure your GitHub environment is resilient enough for the AI era. Please reach out to your Rubrik account executive, or you can visit us on our website to explore an interactive demo of DevOps protection using the QR codes on the screen. Finally, thanks so much, Courtney, for bringing your incredible on the ground insights today. And, thank you all for joining us. We will follow-up for any remaining questions in the q and a chat or via email, and have a great day. Thanks for having me, Pradeep.