96% of Companies Run AI Agents. Only 21% Can Control Them

This has been generated by AI and optimized by a human.

Gari Singh (00:00:00): I'm telling you now, you unleash the AI, the AI is not going to wait for you to install Chaos Monkey. It's just going to start doing whatever it can. I mean, I really, really urge people to run an agent and ask it to do something and then see what else it does.

Nicky Pike (00:00:15): This is [Dev]olution, bringing development back to speed, back to focus, back to freedom. I'm Nicky Pike. Okay, so everyone's talking about making AI developers faster. Copilot, Cursor, Claude Code, Vibe Coding the next billion dollar startup before lunch. The inner loop has never gotten more attention, but here's what nobody's saying out loud. The inner loop was never the bottleneck. The fight is happening in the outer loop. MCP servers, agent identity, container governance, the unsexy infrastructure layer where your AI either gets controlled or it doesn't. And we are absolutely speed running the same mistakes that we made with microservices and blockchain just at agent speed this time. The people who own that layer have a brief window to bake governance in. Everyone else, they're building death that's just going to come due at the worst possible moment. With me today is Gari Singh. He's a product manager at Google Cloud focused on containers, Kubernetes, and the runtimes carrying most of the world's AI workloads.

Gari spent 15 years at IBM. He ended up as a distinguished engineer and a blockchain CTO and has now lived through three of the biggest infrastructure waves of the past 30 years. So when he tells me where AI infrastructure is about to break, I listen. Also, fair warning to anyone who hasn't met him at a conference yet, you have not lived until you've gotten to Gari Singh Bro Hug. Generally, it's a contact sport. Gari, welcome to the [Dev]olution.

Gari Singh (00:01:39): Hey, thanks, Nicky. It's like to be here finally.

Nicky Pike (00:01:42): Yeah, I'm looking forward to this. This is going to be a fun conversation. Let's go ahead and set the stage for this. So three of the biggest infrastructure ways of the last 30 years, XML middleware at DataPower, at Enterprise Blockchain at IBM, and now you're doing Kubernetes and AI runtime at Google. That's not a resume, brother. That is a pattern. So take me back to DataPower for a second. What did you learn there about how infrastructure actually gets adopted that you're still using today?

Gari Singh (00:02:08): Yeah, and actually even before that, I was doing app servers. I went from doing J2EEE at the time, that's how old I am. It was still called J2EE at the time. But yeah, then we went to ... I wanted to work on more purpose-built stuff, right? So building appliances, XML was hot, SOA was just coming up, right web services. So how do we govern that, secure that, route that? So my resume is basically always about distributed computing pretty much and security. So that's kind of what I've always worked on. But yeah, I mean, I think I learned a ton there. Being the gatekeeper, super important. What happens when you get in the line of traffic, how you distribute things. The dangerous part of course is it's great. Once you're in the middle of traffic, you start to do a lot of stuff. But the bad thing is when you're the gateway to traffic, you can never go down either.

And you're sort of the place that's got to detect that. So yeah, that was a great experience going from building and deploying the J2EEE applications to them being that front end that kind of protected, distributed in it. But also back in those days, we had XML attacks, parser attacks. I mean, we didn't have all the RAM that we have today. Browsers didn't have stuff. Microsoft still had a JVM and their own XML parsers. I mean, this was all a whole free for all back then, kind of like now in the AI world a little bit. And so we had to figure out how to broker all that stuff, security. So yeah, all that stuff is ingrained, I think, in me since then and sort of carried forward.

Nicky Pike (00:03:28): So you say like the AI world. So are you seeing some of the same patterns? I mean, we all know it's at a different speed. This is a rocket ship that's taken off with AI, but are you seeing some of the same patterns that you saw with these things now that you saw back then?

Gari Singh (00:03:42): Yeah, sure. I mean, even simple things like the day that somebody made it simple to point and click and expose something on the web. Then they're like, "Oh, here's my web services, here's my apps. Oh, it's going to be great. We're going to have APIs. Everybody can access them." Yeah. Did you ever think about, but you were used to building closed systems, systems that stood behind the firewall or internal. Whole different threat vectors that start coming up. And now again, the cloud made this easier, but AI just makes it faster. Now I'm building agents. I can expose them to the web in a second. I can deploy them onto our infrastructure, Cloudflare's infrastructure, connect it. It can wire it to systems because it's even easier than it was before. So yeah, I mean, we're seeing that same type of thing from the speed. I'd just say it's probably like whatever, 10X is 100X probably faster.

There's a new framework or a new thing every week. At least back in those days, it was like maybe every six months or maybe every year.

Nicky Pike (00:04:40): Right. Yep. I'm with you. And you talked about this being the free for all era. I mean, that's one of the things. So before we dig in, you went from a Yale math and econ degree to an IBM distinguished engineer and now you're working at Google as a product manager and you described yourself as a free for all guy who hates process. So how does that version of you survive a company where you were talking about they won't even let you install what you want on your own laptop anymore?

Gari Singh (00:05:05): I always like to say where there's a will, there's a way. I think I like the challenge, but yeah, it's always good. I guess I've always stood by the mantra, right? Nobody ever really intentionally tries to stop a good idea. So it's all how hard you want to really believe in that idea to push through. And that's like everything I learned from college, playing sports, just keep trying, keep trying hard, write all that type of stuff. So yeah, it's never stopped me. I guess I always believe I'm either right or just really believe in what I'm doing. So I just keep going through. Whether it's true or not, it's a different story, but I believe it.

Nicky Pike (00:05:37): So when Gari says there's always a way, right? If you're Gari's manager right now, Earmuffs, don't listen to what he's saying because we don't want you getting in trouble for installing things that you shouldn't.

Gari Singh (00:05:47): They're all well aware. Oh yeah, it's true. They don't know about that, but they're all well aware that it really happens.

Nicky Pike (00:05:52): I got you. I got you. So here's the challenge on the table. 96% of companies are running AI agents in production. Only 21% can actually control them. Now when we look at this, 88% have already had a security incident or they suspect that they've had one. And the wild part is that only 22% of the teams treat their agents as independent entities. The rest are running them off of shared API keys like it's 2008. So we've got an enterprise stampede to deploy agents on infrastructure that wasn't ever built to govern them and it's sitting on top of platform teams who were never invited to the AI strategy meeting in the first place. How does this end any differently than what we've seen with blockchain and microservices? And that's what we're going to be digging into. So the enterprise blockchain went from world changing revolution to this expensive collective hallucination.

You were incited at IBM and you were watching proof of concept after proof of concept never make it into production. What's the AI version of that pattern playing out right now and the thing that looks like it's adoption, but it's actually just theater.

Gari Singh (00:06:52): The main part I think with blockchain at the time was I think people thought it was the hot thing to do and it was like the answer is blockchain, I don't know what the question is or what the problem is. I will say that AI has a much better trajectory. And I think we see that now because everybody said, "Hey, we're going to build all these autonomous agents that do all this stuff. They can answer all of your questions. It can solve world hunger." We actually saw the same thing with API management, right? Expose all your data as APIs, monetize stuff. We've seen the same sort of trends. That's why in a lot of those cases they didn't quite understand it. A lot of people didn't understand what LLMs are because there's AI, but I guess we should really talk not to be pedantic or whatever about more generative AI is really the hot topic.

And I've often found that people don't even fully understand what generative AI ... The keyword in generative AI is generative, right? It's the next token prediction. It's not the same thing as a question and answer that you're kind of used to. And so I think a lot of people didn't fully understand that, kind of built these things, thought it was going to do some magical thing and then it just didn't work out. But the difference between AI and blockchain in this case is the sweet spot that blockchain found or the adoption that it found was cryptocurrency. Love it or hate it, that's where it was. It just never found a great use case for the cost, the price, the expenses, and people didn't want to change stuff. I think the difference with AI is that after a little bit while, especially starting, I don't know, maybe time flies, but definitely last year with Gemini 3, Claude, Sonopas like 4X or whatever, we really started to see that there are serious use cases for it, everything from the code generation stuff to a writing doc.

At a minimum, it has real use and real utility. And I think that's kind of the difference of where things left off. So people were failing on some stuff because they didn't understand it, but all of a sudden there was a rapid, the technology changed so fast and improved so fast that people then saw the value of some of these use cases and now that's sort of putting people on a different focus or different trajectory. Whereas blockchain was never a technology problem, it was a problem that the technology didn't solve enough common problems.

Nicky Pike (00:09:07): Well, and what you said was interesting because we did the same thing and I see this as the same pattern that we saw with Kubernetes and it was the same. I came from the Cloud Foundry world and that was one of the jokes we always made. Hey, the answer is Kubernetes. Wait,

Gari Singh (00:09:20): What

Nicky Pike (00:09:21): Was the question again? Right?

Gari Singh (00:09:22): Yeah, yeah, exactly.

Nicky Pike (00:09:23): But it took, we saw QueCon blew up, we saw all these industries come around Kubernetes, companies were jumping into it because, hey, Google's doing it, Netflix is doing it. We should jump in and do this as well, but people didn't clearly think it through. Now there are good use cases, but it took a decade for Kubernetes to really jump in and become a thing in the industry. We're seeing that same pattern with AI, but what took decade for Kubernetes we're seeing in like 18 months here and I think that you nailed it is because the use cases are there. People are finding new use cases, new ways to use AI every single day and the capabilities that we're seeing from the LLMs and the agents are also exponential. I think that's part of why we're seeing the huge growth here. What do

Gari Singh (00:10:06): You think? 100% agree, right? I was obviously playing around with it, obviously we're Google, so we have access to all of it. ChatGPT came out and you play around with that and you're like, "Oh, that's pretty good." I think when it first came out, I'm like, I queued a different way of doing search and answers questions and it writes in a nice thing. And then there was some issues in there. But then maybe it was like the beginning of last year, a couple of years before you start looking at the code generation I think was like the game changer for me. I mean, just the quality of what it did was just amazing. And then the doc writing ability, all the frontier models, there's still room for improvement and everybody's driving and competing. I mean, the market's still up, but we're always seeing improvement in those things that are making it seem real and not Vaporware.

It really can do what it set out to do. And I think that's the difference in a lot of technologies. And then of course, you can use it to, of course, rewrite itself. I mean, it's ironic to use AI to build AI.

So I think that's that exponential factor.

Nicky Pike (00:11:02): Yep. And we see that arms race because no disrespect to Google. Gemini came out, nobody really wanted to adopt it. And then all of a sudden Gemini went to the top and then Claude and then OpenAI and we keep seeing this arms race going on. And personally, I love that because every one of them's got different strengths. Every one of them's got different weaknesses. So the ability to switch around as we see fit, use them for different work cases or use cases, that's phenomenal. And that's something that is, I'm not going to say it's unprecedented, but it's not something that we've seen a lot. We had technology. You used. NET for the longest time if you wanted to do gaming

Gari Singh (00:11:38): And

Nicky Pike (00:11:38): Things of that nature. But with AI, we're starting to see all these explosion of use cases. We're starting to see this explosion of people who are non-technical able to use AI to do technical things. And there's a lot of conservation about there about whether non-technical people should be using it. But let's be honest, this is going to lead to an explosion of ideas. People have great things in their head. AI is going to be an unlock key for a lot of this.

Gari Singh (00:12:02): Yeah, most definitely that's in there. I read an article about, I was talking about SaaS companies are the ones that probably have, to your point, are the ones that probably are going to have to watch out. People building packaged software to solve specific problems because now some of those mundane problems, if you're a guy or gal sitting back and you're like, "Hey, I need an application for blah, blah, blah that manages my inventory, does X, Y, or whatever, you can literally bring up whatever, the Gemini Canvas, Claude, whatever your tool of choice is and literally design the UI and the mockup." And literally it's not even like click-throughs. You can build you a live site that looks like whatever you want, maybe it's using fake data and now all of a sudden you're like, "Here's what I want. " And then the build versus buy kind of goes, "Okay, well, there's what they want.

Now let's just, okay, we'll just build it. Let's have some agents or whatever kind of build it. " And so I think that's where this, whatever, you can call it citizen coder, but I call it almost like business person requirements driver. There's no longer like, "Here's what I want. " And then somebody has to come back and discuss with them and build all the user stories and blah, blah, blah, that whole cycle. No, here's what I want, here's what it looks like and have it,

Which really makes that cycle much more fast, much, much faster. I don't speak English apparently. Makes that cycle go much faster.

Nicky Pike (00:13:20): Yep. No, I think it's interesting because we're seeing this, it's become like one of the top three use cases with a lot of customers we're talking to is that citizen developer, the citizen builder, because they do. They've got people inside their company that have these great ideas. They end up giving them the IT, but they sit on the backlogs for six months, nine months, right? They never really make it because the IT department wants to do things that are creating business value AI is now open in that and a lot of people are like, "Well, yeah, but what if it's insecure?" Well, there's a different risk profile there when we're talking about this, when we're talking about internal apps, when we're talking about things that citizen developers that they're building, but you're absolutely right. Let's say that somebody does build something that they want to take to production.

Well, now it's the new wireframe. We're giving it to the IT team and saying, "This is exactly what we want. Just polish it up, make it secure, make it perform it. " That still cuts a ton of time out of the IT team's time to write that or publish that code. And I think that's an enormous use case. So we're going to see this explosion of software coming up, but on that same lines with great power comes great responsibility, Gari. And there's a stat that I read that I think every platform team should be listening to and that's that the prompt injection attempts that we've seen against enterprise AI have surged something like 340% year over year since 2025 and 73% of the audited production AI deployments have known prop injection weaknesses. So the problem is that this isn't a malware signature that anybody can scan for.

This is very difficult for security tools to look for because it's natural language. The same exploit in prop injection can probably be written 18 million ways and it just looks like a normal customer support ticket or email. So from your perspective, break that down for me. How did platform teams even start defending against an attack service that is just natural language?

Gari Singh (00:15:06): I would say that the same principles still need to hold that whether it be, I think SQL injection and crosswide scripting are probably the closest examples of it or people who are building deploy code and compile it for you type sort of applications. Yeah. I mean, I think you have to kind of know the blast radius of, to your point, like people just deploying this agent not knowing what's really happening and then all of a sudden you're just allowing direct access to it through prompt. So obviously there's some stuff that can get through. You should of course always go with the defense in depth and there's many different companies are building firewalls specifically to these things. Obviously they can't know all the signatures. I think in a lot of cases you have to, what is your actual agent capable of doing? Because people could send anything in there and you have to start thinking about like, what is this environment and the execution environment that I have my agent in?

So everything from the sort of sandbox layer. If somebody sends in a command and tells it to run like Bash, well, that's fine, but maybe you shouldn't have Bash on the system if that's not what the intended thing was. If your intended use of your agent was for it to be natural language that gets translated to look up some information in a specific system, make sure that that's what your agent does and all kind of has access to. So I think you can start from sort of the back, like limit to blast radius of what the thing that's actually, once the prompt kind of gets there, what it's actually doing. I think a lot of people sort of miss that. They're like, "Oh, I built an agent. Even if I deployed it on a container, I've deployed it on Debian and Slim, it's in a container, deployed it on Kubernetes or whatever.

I deployed it on a VM." Well, you're like, "Yeah, but okay, that thing all models will be like, Hey, I can run Bash. Oh, I have access to Bash. And if you didn't have those sort of security things, you see that in IDEs and the cloud codes and the agents, whatever, they have all those allow these commands, but there's some default in toolkits, but if you just build with a simple API, you're not going to know that. So to me, that's almost like the biggest thing, right? And then obviously test, test, test and also monitor what things are doing, right? Serious auditing, what were the commands, what were the code? Like I said, there's no way to stop it, but I think on the back end, I think this whole sandboxing and limiting the blast radius is pretty much what most people are doing. Well, what most people should be doing.

Nicky Pike (00:17:22): Yep. And I see that we get the same pattern there that we saw in Kubernetes as well. Kubernetes started as kind of this grassroots developer driven effort. We had complete chaos for a while, people out there doing things that the IT team didn't know about, that the platform team didn't know about. And then there was this reckoning where it's like, okay, we got to get a handle on this stuff. Hey, platform team, you need to start standardizing, you start putting some policy around this. And we're seeing that same thing with AI today. I agree with you. I think when we look at the zero click exploits and things of that nature and what can happen, you have to start using infrastructure to really contain and guardrail those agents. And I think your point was spot on the platform team needs to start looking at what the use cases for the agents are and making sure that the agent doesn't have any extra permissions that it doesn't need and they've got to build that around in policy.

And this is where the infrastructure comes in and we're all talking about what can we do to make developers more productive, but at the same time, very few people are talking about, "Hey, platform team, y'all were never invited to this conversation, but guess what? This is your responsibility now."

Gari Singh (00:18:24): A couple years back, it was all about running AI infrastructure, like how do we run GPUs and all that, still being used for that, but now there's been some good releases that have came out like the agent sandbox idea for Kubernetes, how do we contain what are the right things that we need for running agents on there, which allowing things to delegate on Kubernetes, for example, to in our case like gVisor or Kata containers or whatever, which are again, secure execution environments to limit the blast radius, including things like making it easier to use some of the already built-in things like what URL should you be allowed to do, which will then generate network policy. So I think we are starting to look, at least on the Kubernetes side, what's this next layer up for platform engineers to do that? And then people need to pay attention to other stuff, right?

I won't go too much into Kubernetes, but we just released in 136, I think it is, or 1351 GA, the ability that you can map the root user in a container to a no-op user on the operating system. So there's all kinds of this sort of, as I said, this sort of defense in depth. I think the problem is when you have too many switches, people don't know about them. And I think that's why the agent sandbox was a good idea. There's another thing that they just announced yesterday called the agent substrate. So at least trying to build this stuff to make it easier for people. But the end game is people can't ignore this like they ignored many other trends. So platform engine, it's going to come super fast. This is not like shadow IT, it's Ninja IT. I don't know, right? It's like fleet of Ninja IT, right?

Nicky Pike (00:19:56): Ninja

Gari Singh (00:19:57): IT. You just came up

Nicky Pike (00:19:59): With something new viral right

Gari Singh (00:20:00): There. We're

Nicky Pike (00:20:01): Moving out of shadow IT to Ninja IT.

Gari Singh (00:20:03): Ninja IT, right? They're like executing in secret and just going in their groups and I think people have got to pay attention and you got to try this stuff out and you can't ignore it. And I think that's otherwise you will be out of the game or you'll have these massive security things.

Nicky Pike (00:20:20): Agreed. Well, and there's this old adage. So me and you, we're both platform engineers and there's this old line from process and platform engineering that automating bad processes just makes bad things happen faster. So apply that to the AI era for me. What's the thing that platform teams are about to amplify that they really, really shouldn't?

Gari Singh (00:20:39): Multiple things are going to happen here. With the AI, like you said, if you don't have that infrastructure in place, it's just going to go awry. This agent is going to go in there and it is going to wreak havoc. They are going to unleash true chaos. We talk about chaos testing and chaos mess, the framework that Chaos Monkey, the Netflix, which you basically had to start to run yourself. Well, I'm telling you now, you unleash the AI, the AI is not going to wait for you to install Chaos Monkey. It's just going to start doing whatever it can. I mean, I really, really urge people to run an agent and ask it to do something and then see what else it does.

Nicky Pike (00:21:18): Well, it always reminds me, there was this old Bill Cosby skit where he went in about, he was talking about drug use and he was talking to somebody and they were like, "Well, cocaine, it's great because it just amplifies your personality." And Bill Collib goes, "Well, yeah, but what if you're an asshole?" I see the same thing with AI, right? It's there. If you're doing good stuff, it will amplify good stuff. If you've got bad processes and you're doing bad stuff, it's going to amplify that and just make the bad stuff worse. Yeah,

Gari Singh (00:21:44): Exactly. It's like people say, "Teach it how to do whatever." It's just going to, like you said, it's just happening at much faster speeds because you literally don't have to code anything anymore to tell it to do that. Automated process, you used to have to, maybe you had to write your Terraform and then plug it into this and plug into this, get act, whatever. Now this thing will do all of that by itself. It's super

Nicky Pike (00:22:06): Human speed.

Gari Singh (00:22:07): Yeah. I mean, not a whole hundred percent by itself, but you just ask it what to do and it goes and does this. And so someone's like, "Hey, here's our process user to deployment stuff. Let's just have this in there." If they're not bad and they don't have checks, it's not going to care and it's just going to work, probably find a way around them. Because the other thing, if you don't ground AI correctly, sometimes it's like its intent is to solve the problem. So it will use almost every tool in its toolbox to solve a problem.

Nicky Pike (00:22:35): I agree. I always describe it as like two ways I describe it. It's either like an intern all hopped up on Jolt Culla or it's just a happy puppy. It wants to do everything it can to please its master. And if you let it, it will rip a hole through the wall to go fetch the newspaper if you allow it to. And it's funny to watch some of the things that how people get surprised is like, I never knew AI could do that. I would've never thought to do that, but it looks for patterns, it goes and does those patterns and you've got to kind of watch it and guide it to say, "Okay, stop what you're doing. Let's rethink this because if you don't, it'll just get caught in that loop and it'll keep going. "

Gari Singh (00:23:09): Yeah, and just one thing. And I think that's the thing that a lot of people don't fully understand, right? Because if you just play with it through chat, it seems like request response, right? But if you don't really know that there's this agentic loop, these are not just like run a command line and it dies, right? This thing was running in the background. It's continuing to iterate, call the LLM, it has tools, it's calling back, the model's giving it instructions, it's figuring out instructions. It's this loop and the loop becomes self fulfilling and sort of self-executing. And I think that's where a lot of people don't fully understand. I think you do have to kind of understand how it works to know how to defend against it.

Nicky Pike (00:23:51): And I think one of the things that I think a lot of people are underestimating is the monitoring and the surveillity of what agents are doing because when you're in a chatbot, there is a back and forth. You're kind of human in the loop as part of that. But when we start talking autonomous, "Hey, go fix this GitHub issue for me. " Well, the fact that it can not only write the code for it, but test it, then you see where that loop can happen. And that's where people get surprised by billing events or they end up polluting their code base because it'll go try something, it'll test it. Well, that didn't work. Let me try something else, but it's

Gari Singh (00:24:21): Not

Nicky Pike (00:24:21): Backing out all the stuff that it did before. And you've got to have some systems in place to be checking on that and make sure it's not getting caught in the loop so you don't get surprised by a bill at the end of the month or you get 10,000 lines added to your code that you're going to have to bring out.

Gari Singh (00:24:33): Exactly, exactly.

Nicky Pike (00:24:35): Now one of the other things that always interests me is people are saying, well, they're worried about the fact that, well, AI is going to make it to where we lose our cognitive abilities. We're just going to trust AI. But I'm kind of seeing the opposite thing because the capabilities and the new things that are coming out are so rapid, right? We started out with MCP servers, we got A to A, we've got skills coming in and I wanted you to talk to me. So you've got an MCP server for Google. So talk to me about that because the self-install open source version, which is in your words, dangerous, right? And then there's the remotely managed one with the enterprise controls breakdown. So for a platform engineer who's watching this, why does this distinction matter and what does the managed version actually buy them when we're talking about the Google MCP?

Gari Singh (00:25:20): So yeah, we have sort of two versions of it. And a lot of MCP servers run like this, right? You go in and you install extensions, you bring it down, and everybody's got these MCP things and the MCP service to make it super easy when it started, right? They're like, "Hey, we'll just support communication via standard in. " And so they basically run as a binary executable right next to whatever your coding tool or whatever it is and we communicate methods on standard out. But at that point it's running on your machine. So it's only governed by what your machine is there, so there's no blocking it or whatever and then typically it's going to use whatever credentials are on your machine so people are kind of now in a free for all. People who didn't know how to do stuff could now do stuff that's probably, they shouldn't have been ... It becomes a little bit more dangerous because it's kind of an enabler versus at least when you go on the stuff that's more hosted or managed.

And again, you could run our open source one, but UIT should probably run it over HTTP as a managed server and probably prohibit certain binaries and whatever from being installed or put in some type of controls around your IDEs so that people can't just download, just like you do for anything. You can't download software because then you can at least have, okay, here's what the permissions that it has to run as. Here's different roles that you can run at. Here's full auditability, a full sort of trail. And that's why I think you need to have, from the hosting side, I love it because you don't need the tools and the executables to run it, but you also have that governance layer just like you did for any other API that you called on cloud or whatever. But if you're going to run the self-managed, then self-managed should not mean individual developer manage in my opinion in some cases, especially for things like cloud infrastructure.

Unless you're 100% sure that that person only has read-only access with whatever credentials they have, then it's probably okay. So yeah, I think that's where, again, it's like all these thoughts, because you're just wrapping APIs. I liken it to this. There was a long time ago, as you know, you said we're older, I'm older, whatever, people may remember SNAW networks or SNA networks, mainframe protocol, wire stuff. And these things become like closed systems. So at one point Microsoft in 1990 ... I'm not dissing on Microsoft, I think in 95, 96, recently around that time, Microsoft built basically these VB modules that allowed you to communicate, translate VB stuff to SNA networks. So now all of a sudden people could build applications in visual basic that talk to the mainframe. Before, you had to actually know what you were doing. Now you didn't. And so to me, that's the reckoning, right?

You're dangerous because you don't know what you're doing and you have a tool that can do anything that you ask and that's why you want to have those controls in place.

Nicky Pike (00:28:13): Everybody knows I love my analogy. So when you're talking like the open source MCP that you got for Google, we're giving you all the ingredients for a cake, you go figure out how to make it. The enterprise version is more like, we're putting it in a box, here's the instructions and here's how you actually do it. So it makes it the enterprise comes a little bit safer because we're assuming that you need these controls whereas the open source is, "Hey, go do what you need to do, do whatever you want, figure it out yourself." Is that a pretty accurate statement?

Gari Singh (00:28:38): Exactly. Exactly.

Nicky Pike (00:28:40): All right. Well, the other part of this is so elicitation, right? The idea that an agent has to confirm with the human before it acts. I mean, this sounds great, Gari, until you remember that most developers are going to turn it off because they don't want to become that little peck and chicken on Homer Simpson's desk just hitting yes all the time. So they want to go faster. How does elicitation really survive contact reality? What stops a citizen developer from just flipping on the AI into Olo mode?

Gari Singh (00:29:07): Well, there's a few things I guess who writes it all themselves, who writes the whole thing themselves, I guess. Anybody who turns many of the tools into YOLO mode, there's certain things they just won't let you do even that's in there. But again, I would go to the same point of the communication with those systems that were really asking for you. And again, that was another good reason for requiring certain things to go through the managed version or this other version because they can still require it. You can build it on that sort of server side such that even if the thing pretends to ignore it and says, okay, it still actually wants you, because ignoring it doesn't actually give a response basically, right? It's more like YOLO mode is more like it asks you if you wanted to run Bash and it's like, okay, run BASH.

But when you at least talk to the foreign systems, like the MCPs or whatever, at least when They run server side or whatever it may be, they still expect you to send that tacit acknowledgement. And at least for now, the tools aren't auto acknowledging that's in there. But yeah, I mean, you are right. There is a sort of danger. One of the things that was released at Next when we had in the chat thing that you could create servers or whatever, that's also why we have pretty strict roles so that even if you do ignore it, you still don't have the ability to do it. We actually have a separate role for delete. So there's a person who can read and write. There's a person who can read and then there's a delete because you don't want to say delete the cluster. So you can at least do that preventative stuff.

But you're right. Again, running in YOLO mode with ungoverned MCP tools, whatever it is, can spell the deletions that you probably read about from all these people with their horror stories.

Nicky Pike (00:30:54): Yeah. I think this brings us back to why platform teams are so important is platform teams are going to have to account for that possibility. There's this old age in the military, we're going to make something GI proof. And what that means is we're going to make it so that even, forgive me, the dumbest person can't screw this up. There's a reason that we put warning stickers on hairdryers, do not use in the shower because people have done it. But we can't trust the fact that the sticker's going to work. We actually put the GFCI on the end of the outlet. So if they do go use it in the shower, it stops them. Platform teams have to look at the exact same thing. They've got to assume, hey, we can tell people, we could put blocks in place to say, don't do this, but we've got to assume that somebody's going to.

That's where we get back into the defense in depth, the hard agent restrictions, being able to put boundaries around what an agent can do. Even if the human says, yeah, go out and modify my production database. We've got a block in there from a network perspective or something that says, no, you can't go do that.

Gari Singh (00:31:50): Yeah, exactly. I think there's still a nice tie to some of the things that you have processes. There are going to be a set of people. Maybe this is where they're just getting started. Maybe they didn't have all this in place and then maybe they have some deep knowledge of AI because they're probably building AI themselves. They're like, "All right, well we're not going to do IAC these processes. We're going to do AI, have AI do everything for us." But they'll know how to put some guardrails in and some other things in those systems. But I think even if you already have a system for deploying stuff that your normal deployment is GitOps, then a lot of this stuff can make 100% sense. Don't give right access. Don't give access to patch or apply, give get and whatever. And then your only way of getting that onto my system is to send it through the sort of GitOps flow.

And I think that's still wholly fine that hasn't slowed things down or whatever. I think what's happened now is that you don't have to build all these weird things that you were trying to build to ... How many people have built 27 different ways of generating YAML? Helm, XML to YAML, some JSON format or whatever. You can now push that out to the edge, to the developer. You can give them a skill, a few other things. You can still have quality gates that reject it in your CI, but here's my thing. It's going to follow my best practices. It's going to develop my YAML. It's going to build my container, do all my other stuff, create my manifest, and then it's going to just send it to my GitHub. So you've still sped up the whole thing because every time that platform engineering doesn't have to come up with a new way of onboarding some new thing or whatever, they just have to have their old kind of gate that was in there and they no longer have to build all these facades and other things to make it easier for the developer or citizen developer to do that.

So that to me is where you'll have that stuff. Now you as the platform team may start to build a set of agents that you use that maybe do have mutate access or whatever because you kind of know what systems you want or whatever. But change control, I think, doesn't go out the window and it doesn't make this any less powerful. It's just that you sped up the whole front side of the pipeline. And then even on the pipeline side, you can do a lot of stuff in AI where you don't have to write the rules and whatever. There's lots of tests and evals and whatever that you can do for doing basic checks. So I think you just have to figure out how you interface all this stuff with your existing pipelines. What things you've built can be replaced or what things that you may have have to build, you'll no longer have to build and build those optimizations in because you can't stop it and people are going to be like, "Why aren't you going fast?" And then people will go around you and then people will start deploying who knows apps.

These things are so weird. They'll deploy to someone else's cloud. People make the mistake of letting it buy something for them or it figures out access and all of a sudden you have my Apple, I couldn't deploy it to my infrastructure. I'm being a little extreme, but it is-

Nicky Pike (00:34:52): It's not that far out. It's not that far out though. We've seen some weird shit out there.

So there's a thread there that I want to pull on because you're talking about a lot of the checks that we're seeing and workload identity, pod identity, service mesh identity. These are all patterns that are coming back up. The only thing is now we've got to wire them up for AI speed. And right now, something like only 22% of teams are treating agents as independent identities right now. The rest of them are just sharing creds. So for the platform engineer who actually has to build this layer, what does Monday morning start for them? Are they looking at pod identity, service mesh, both? I mean, neither. What do you think they should be looking at right now when we're talking about things like this?

Gari Singh (00:35:36): I mean, I'll say as a caveat, I'm not a huge service mesh fan, only because I think it got overused. I think that it does fit in here. There is the same stuff though. If, for example, you were not able to or your people weren't able to build some concept of identity, authentication or whatever into their specific agent, which is now deployed, say as a pod, then yeah, the whole notion of the service meshes and the gateways and the routing and AmbienS makes this a lot better because you don't have to do sidecar routing. Definitely could be your architecture going forward, perfectly fine and does solve that problem because it does have the concept of injecting identity in there, who can talk to who, where you can talk. So I think that's one side. And a lot of times if you're running your own infrastructure, that's probably what you'll have to do because you're not a cloud provider.

Cloud providers like ourselves, Microsoft, Amazon, we all have different, we call it workload identity or workload Identity Federation, the ability to basically have a pod take on an identity on its behalf, pod identity. They're all different in different places, but again, those can work as well. And then the same concepts, I think underlying service mesh, I think people are starting to build that you can basically just inject the identities straight into the pods themselves, like agent identity in the sort of layers. So yeah, people, I think, need to get familiar with this idea of these different layers. How do I inject ephemeral credentials or short-lived credentials scoped down to whatever that particular agent or whatever I may be able to do into that sort of workload. And yeah, I mean, the meshes are always a good start for that. I think for most people, I would look at platform specific capabilities if you have the luxury of deploying on somebody's cloud.

Nicky Pike (00:37:18): Yep. I 100% agree. I think it's going to be a rethinking of the old patterns, but how do we apply them? Because all this stuff's important. And that kind of brings us into the implementation and scale on this is we talked about Citizen developer. It's top three on a lot of the customers and CIOs that we're talking to now. We've got developers that are spinning up agents, they're building flows, hitting APIs. Now the platform team, they don't want to handcuff them, but going back to the YOLO, we don't want them just YOLOing through our production systems. So where do you think the line is? How do you think that platform teams can actually hold that line without becoming a villain, without becoming a system that developers or citizen developers want to work around?

Gari Singh (00:37:59): In order to bring tools up, I think they're going to have to meet people where they are. What are the things that you can provide that work in the context of this new agentic inner loop? If you want to gate what people do or have these types of stuff, you can still make it easy for them to do things. Just provide what are codify some of your rules now into skills that need to get delivered out to the edge to these developer tools, right? Codify a few other processes, right? Potentially streamline where people can deploy. I think you'll also want to probably leverage AI to more quickly test and bring on new capabilities. You can't no longer be like, "I'm going to be on Rev. We only support JDK17." You're going to have to figure out how you leverage some of this stuff to automate and bring that stuff because that's the other thing, right?

On the AI side, you're always going to advance even in the software capabilities up versions of the stack, whether you're using the ADK, Claude, this or whatever, you can't say you're locked into version 1.6 or whatever, whatever it is, there still is that sort of concept or our model 4.6 because somebody wants to use 4.8 or 3.1 or whatever, 3.5. So you've got to stay up with that speed. So one, push as much stuff to the edge as you can, assuming that they're in the inner loop, whether that be the skills of the MCP. And then two, figure out how to automate your good practices and codify those kind of yourselves using AI. I mean, if you can't beat them, you're going to have to join them.

Nicky Pike (00:39:32): So you say something there. So there's something that I talk about quite a bit and I think you kind of danced around it. I want to get your opinion on it. So again, going back to the intro here is right now AI is all focused on developer productivity. How can we make them faster? And we're hearing anything from one to 15X is what we're doing with productivity from developers. But in my view, that was never really the problem. And I think you kind of danced around this, which is, hey, our developers are 15X more productive, but they're still hitting the same wall on the outer loop. And I think platform engineers have to start looking at that outer loop. How do we speed up testing? How do we speed up all of our checks? How do we speed up getting prep and build? Because if your developers are pushing out more code but they're still hitting that same gate going into the outer loop and that slows everything down, you're not going to see business value.

And that's where AI projects, in my opinion, start getting installed or they start getting abandoned because yeah, developers are more productive, but we're not seeing any value out of it because we can't make our outer loop go faster.

Gari Singh (00:40:30): I think there is, so of course you're going to have to start adopting it, but yeah, there's other things that you can do. If you want to speed up, if people have gates on test and other environments or whatever, okay, well now be ready to deploy. Maybe you're going to have to deploy a little extra environment test in the Kubernetes world, like test clusters or build in some automations or let developers have some limited access to spin up these whatever clusters and whatever they can do. So they can at least do because now they can do a lot of the outer loop stuff kind of themselves. Again, the AI can run a bunch of these tests for people. You can actually push all of your pre-submits into somebody's bucket and then have as the rule that in your claude or your Gemini or your ant-gravity, that when every time before there's a push, run all this stuff.

So a lot of things that maybe you felt you had to build infrastructure for, couldn't scale or were pissing off developers because they're like, "I built all this stuff. Now I deploy it and it fails." And they're like, "Ah, God, I'm going to go around this guy and go set up my own cloud project over here because their clusters don't take my applications." You can push a lot of that to the edge and then I think to where you were going, also I think the platform engineering teams are going to have to start standing up some of these environments that people can target more with the out of loop capabilities that the platform can do. And then where you're really going is we really need to start building platform agents. I knew where you're really going, but all that stuff I was saying what people will at least could do it in the meantime, but yeah, at the end of the day, you've got to figure out where your value is and your value is in understanding what needs to be done, not in necessarily building it all.

And I think building it all is what often slows things down and the monitoring all this other stuff. So you need to go figure out where the value is, right? But things like all the reporting, all the usage, these are all agents that can be in there. Monitoring where people deployed, almost all these things that you were trying to prevent or wanted to do or felt you always had to build a tool for every time something new came on.

Codify the rules, build your system design and then you've got to push that into maybe at first you're just using AI tools to build the IAC or the infra, but later on you're going to start to put this stuff into agents that are just going to do a bunch of this stuff for you. And that's a lot of what we're kind of working, but at least I personally am working on right now is like, yeah, what is the right stuff? The SRE stuff, the troubleshooting, monitoring these people's applications, giving you this reporting. You're going to have to start building this out or start looking at some of the solutions that are out there. So there's a lot of power on the infrastructure side or the outer loop for AI and automation, right?

Nicky Pike (00:43:22): Yep. Well, and the one thing that we got to consider on this, I mean, we've all seen the news stories. There seems like there's a new one coming up every day where AI's done something that wasn't supposed to, there's been a security breach. And in fact, we saw there was a survey that came out this year that saw that like 81% of teams are plast the planning phase for agents, but only 14 or 15% have full security approval. And personally, that gap is where the next breach is going to live. So for platform engineers, say working at a mid-size company and they're watching this, what are the first three things that they should actually do this week? Not a roadmap, but what are some things that they can sit down with coffee on Monday morning and start planning out from a security aspect in your opinion?

Is there things Kubernetes based? Are there things that are just playing infrastructure based that we need to rethink differently? What do you think those things are?

Gari Singh (00:44:11): Yeah, I mean, I would say, I mean, you brought up one earlier, right? I think that they should just go look up and start taking a look at what people are talking about with this agent identity stuff. What are we really talking about and why? Because now agents are like people because it's no longer that I'm just like the app that querying a database because I'm a data-driven application and I needed my ODBC, JDBC, whatever protocols we're using credentials. These agents are now like performing actions. They're literally running in the Google world, they're running the equivalent of G cloud CLI or coup cuddle commands. So understanding that sort of identity side. Secondly, I would highly investigate right now look up like sandboxing technology. In the Kubernetes world, everybody should be looking at, I think, the agent sandbox concepts. Whether you run it or not, you should just read it because it'll tell you what it was built for to prevent bad things from these things from happening.

If agents can generate code, you got to, at the extreme example, how do you limit that code's blast radius? And that's going to sort of explain it to you there. And then the third thing I would do is either have AI build you an MCP server. I would actually start playing with, you've got to figure out playing with that technology, pick something that you do every day, use some tools or whatever, see if it can generate the Terraform if that's what you do every day or update it or maintain it or pick one of your processes and build one of these things and start using it. Because to me, concepts are concepts, but nothing's really tangible until you actually go have it do it. And you can just do it with whatever, Claude, Gemini or whatever. Frankly, you don't even have to build an own agent.

These things are agentic harnesses and just start asking it to do stuff that you normally do and you'll be amazed at what it will figure out on its own. And then that will start you down the track of, oh, here's the art of the possible, here's what I have to watch out for. So I'm telling everybody, you've got to get your hands on it and start playing it and not just build Hello World. It needs to be deploy me a Kubernetes cluster, find all of my pods, find the security breaches. Can you find this stuff? Create me a new account. Put all this stuff and you will see if you have those things on your machine, then it will figure out how to do it. And then that's going to start one, maybe scare you a little bit so you'll learn what you have to secure based on the other stuff.

But on the other side, it's going to inspire you in the fact that, oh wow, there's a lot of stuff that I will no longer have to do. All I need to do is tell it a little bit more specifics about what I want from skills. So agent skills, I guess would be the other thing I would look up, like understanding how to quickly write agent skills that can work with these harnesses because that's going to make it even more productive without having to write ADK or LangChain agents off the bat.

Nicky Pike (00:46:58): Yep. I'm going to add a couple things to that and a quick shout out to Google here on this one because Big Sleep proved exactly what you said. We can turn AI and it can go find vulnerabilities that we don't know about. So use AI to go out and do that. I'm going to go back to one of the other things that I stated, observability, right? This is where agent identity comes in because you can't govern what you don't know is happening. You've got to be able to understand what your agents are doing. So agent identity is going to tie back to that, but start looking at and even working with AI, go out and figure out what the agents are doing, look at products and gateways and things where you can actually get those

Gari Singh (00:47:34): Logs.

Nicky Pike (00:47:34): And once you understand what an agent's doing, what it's reaching out to, what tools it has access to, now you can start putting that governance in there. And then again, policy is code. As you start learning these things, codify that something that you can change, something that you can enact and modify as you find new things because we're growing so fast, whatever you find today may not be relevant in four weeks even. We may have new capabilities. So 100% agree with you on all those things, just a couple things I'll add in there.

Gari Singh (00:48:01): Observability is a big one. And I will say that it seems like, not that there was a battle, it seems like almost everything, all frameworks, all harnesses, all tools are all kind of instrumented with OTEL these days. So yeah, I would definitely pay attention to that. And like you said, on the observability, you can even go so far as to what tools did it call, what else stuff did it call? All that information is kind of captured, right? So that's a great call. Yeah, I would include that in the top things exactly.

Nicky Pike (00:48:29): All righ. And on that thing, so what's one of the things that developers and platform teams are currently asking for around AI and containers that Google is not giving them a straight answer on? They'll be a politician here. What is something that you're hearing that you don't think Google's really answered out for them, but the people are asking for?

Gari Singh (00:48:47): There's an interesting problem in cloud right now on whatever you want to call it, capacity, obtainability or whatever. We all know there's memory shortages, all this type of stuff. So I think the main question everybody always asks is, is AI, can you just find me all the capacity? When are you guys going to just enable AI to tell me where all the capacity is and magically deploy everything form? And I don't think anybody's giving a good answer on that because I think the main problem is the AI can't magically make that happen. You have to have some underlying stuff to this. So it's a valid question, but I think that's kind of like the ultimate dream is like, I've got to run all this stuff. I don't want to have stockouts or whatever. Where is it and get me the best price, kind of like the spot capacity advisor.

So I would say that's probably the biggest question people are asking us on the infrastructure side and I don't think that anybody's like giving, I don't think us, Amazon or Microsoft are giving very good answers on that.

Nicky Pike (00:49:46): No, I agree with you. That's something I didn't think about. Right now there's a big concern water for the data centers that are running AI, electricity for the data centers that are running AI. Compute because nobody can build a gaming computer right now because you got to mortgage your house to get memory.

Gari Singh (00:50:02): That's

Nicky Pike (00:50:02): A great question. I think whoever finally gets to answer that and they can actually bring that down will probably be the one that wins this fight because everybody's asking that question today.

Gari Singh (00:50:13): Yeah. And I think everybody sees AI as the AI as the thing they should answer. Either right, it should answer it. It has the capability. Once we have it, you can answer it.

Nicky Pike (00:50:21): We know that AI has the capability. Now the question becomes, do we have the capacity to give AI what it needs to run for us from a compute and data center perspective? All right, Gari. So rapid fire time, I'm going to ask you some very quick questions. First thing that comes to your mind, don't think too hard about this. Yes or no, little bit of backstory if you want, but couple real quick questions here. Kubernetes for AI workloads, is it genuinely production ready or is this still a work in progress that we're just kind of dressing up for a Keynote demo?

Gari Singh (00:50:51): I'd say it's ready if you have to do some work, but it's ready. It has all the primitives. I'd say the layers that we're building on top right now aren't ready to be used 100%, but those should make it simpler.

Nicky Pike (00:51:05): All right MCP servers in five years. Are they the new HTTP or are they the new SOAP?

Gari Singh (00:51:10): I think they're the new SOAP because it'll disappear in five years.

Nicky Pike (00:51:14): Gotcha. So you built Claude Code with Claude Code in six hours. What's the next thing that you're going to build with it that might scare people?

Gari Singh (00:51:21): Oh, I don't think it'll scare people, but it's kind of funny. I'm building a chaos engine.

Nicky Pike (00:51:25): Nice. I'm a huge

Gari Singh (00:51:26): Fan

Nicky Pike (00:51:26): Of K. I love Chaos Monkey and Gremlin and some of those things. I'll have to tell you a quick story someday about what I used to do in my cloud boundary days for chaos, but that's a sidebar. IBM blockchain era, invaluable learning experience are the industry's most expensive collective hallucination.

Gari Singh (00:51:43): Invaluable learning experience, I think. At least from my perspective.

Nicky Pike (00:51:47): When agents start making infrastructure decisions autonomously and they start asking forgiveness instead of permission, is that good thing or is that something that's going to keep you up at night?

Gari Singh (00:51:58): Good thing.

Nicky Pike (00:51:59): The Gari Singh bro hug. Is this real or is this just marketing BS to increase your brand?

Gari Singh (00:52:04): It's real.

Nicky Pike (00:52:05): It is real. I'll validate that. All right prediction time. It's 20:30. Walk me through what a platform engineer's actual day looks like, not the sci-fi version. What do you think the Tuesday morning my pager just went off version of this is?

Gari Singh (00:52:17): I would say there's probably not a platform engineer anymore. I think somebody still has to know what's going on with all the applications and have some human in the loop. I think mostly their day is checking in with which spots or agents have actually alerted them. So I guess maybe some of the stuff they do today, but they're no longer going in and bringing up dashboards or whatever. Something's proactively doing them and they're probably just asking questions that are out there. They probably walk into some room or whatever, their computer or whatever, whatever. Actually, probably nothing. They probably have those magic glasses right now that have the voice. They'll ask the question, whatever it may be. They'll get their alerts on this projected screen that's in front of them, sort of move around. You get the point, but I think that's more of what their job becomes.

Nicky Pike (00:52:59): So you're thinking more like the Tom Cruise movie where they're throwing applications into different clusters just on open air screen?

Gari Singh (00:53:07): Yeah. I mean, if you haven't put on those fancy glasses that have that projection screen, then it starts talking to you because basically everything I think moves to chat and voice, natural text, natural language. Yeah, we'll have those 3D visualizations. Everything, all graphics will be generated on the fly for you so it'll make whatever pictures it needs. We're already seeing that with ADUI and yes, I think that all becomes a reality.

Nicky Pike (00:53:29): Nice. Man, looking forward to that. It may come faster than we think it does, to be honest. All right, let's get spicy on this one. So 2028, most of the high profile enterprise AI governance failures that we're going to read about, the lawsuits, the breaches, the board from firings, those will be traceable back to container and MCP infrastructure decisions made here in 2025 and 2026. Do you think that's true, false, and why?

Gari Singh (00:53:53): Whatever infrastructure decisions are made today, it will be true. For two reasons, I think. One, because even though just talked about everything to being speed, we know that basically these processes can take a while to roll out at the places where these breaches will become important, like the major banks and major stuff. As fast as they move, it's still going to be a rollout that's on there. So I think yes, if you make the wrong decision today, you're going to iterate on the wrong decision versus making the right decisions today, you'll be able to quickly move and iterate on that. And then yeah, because in two years there will be too some high percentage of, I don't know what percentage people are predicting, but most of the applications will have been written and managed by some level of AI. So I think you hit the peak probably of that wave in 2028.

So your infrastructure has to be ready for that. And we know that the places where the breaches will be the worst, it's going to take them that period of time to get that infrastructure rolled out. So start to get the basics right today, the basic principles of what we talked about right today on your checklist and be ready to switch those technologies as you go. If you start down the wrong path, which is probably ignoring it, that's really the wrong path, you're in trouble.

Nicky Pike (00:55:05): Okay. I'm going to do a follow-on question on that one because something just came to mind. We saw the movement to the cloud, we saw our repatriation from the cloud back to the data center. We're still seeing a litle bit more of that because data sovereignty with AI is becoming a thing. But based on what you just said, do you think that there's a possibility that we're going to see public important because with the speed at which we're seeing changes in AI, the ability to write that infrastructure today, what you write for now may not be valid in six months because of changes. Public cloud may give you the opportunity to reconfigure and become much more agile when it comes to infrastructure choices. Do you think that public cloud may become more important again because of that and how do you think we solve that data sovereignty problem if it does?

Gari Singh (00:55:49): I would agree. If people can't buy new hardware, new types or easily rewire their own data centers or whatever as fast as the cloud can in terms of integrating new technologies, rewiring VPCs, networks, all that type of stuff, yeah, that environment is just faster for doing that stuff.

Nicky Pike (00:56:06): I think we saw this repatriation back from public cloud because of cost, but now with AI, we're seeing the data sovereignty question become more and more. People want to keep their data in house. But when we're starting to talk about AI, skills came out of nowhere. That's a new capability. We're making infrastructure decisions and literally this just came to my mind while you were talking about whether we think this is going to happen, but it seems to me that yeah, being able to rewire, reconfigure your infrastructure to data center may become difficult because of the speed at which AI is changing. And I wonder if that's going to push things back to the public cloud because it's much quicker there to either build out a secondary and migrate or to just rewire things through infrastructure as code in the public data center than it is in the private data center.

Gari Singh (00:56:53): I think for the masses, that's going to be the sort of case. There may be the people who have the big intel investments will be in there. I mean, the other side of it, of course, is the, who knows what'll happen in the whatever years, but in the foreseeable future. The amount of infrastructure being put into cloud providers and the capital being put in there probably prohibits a lot of people from getting it themselves at this point. I mean, we're getting all the tech that's required to run this stuff. So I mean, I think there's two things, right? It's like, how do you keep up? They're both related. All the latest and greatest is always going to the cloud first, right?

Nicky Pike (00:57:29): Yep. That's an interesting take as well is that the public cloud is buying up the infrastructure before the private site can get it. That's something to look into. All right, buddy. Same question we ask every guest after all of it, 15 years inside of IBM watching blockchain go from revolution to reality check, evangelizing middleware before the world even knew it needed it and now you're sitting at the center of Google's Kubernetes and AI infrastructure story. What does it mean to you to be a coder?

Gari Singh (00:57:56): I have always loved the combination of why I like code and coding is like you have ideas and just building stuff that people want to use. That to me is what coding is all about. Especially now I think I've changed as I got older. And then I guess I'll say this, it's changed a litle bit now as the AI stuff has made it even better or worse in the sense that it's now about all the ideas that we have, knowing how to do it and now having somebody having like 15 assistants that can do it for you, that's great. And I love it. I'll just leave it at that. But to me, being a coder, it's the best thing out there. I've always liked to use technology to solve problems and that's what coding allows you to do.

Nicky Pike (00:58:37): All right. Well, man, that's going to be a wrap. Before we end the show, is there anything else you want to say? You got any appearances coming up where maybe somebody can come experience that Gari Singh bro hug? What do you got going on?

Gari Singh (00:58:49): We'll be at KubeCon in the fall, so I'll definitely see you there. And obviously locally, if you're in Boston area, we got the meetups. Check out the Boston Kubernetes meetup and yeah, nothing else. I mean, I'll just say thanks for having me on. And I guess my only words of wisdom, especially for the platform engineering side, if you were not using this, you've got to start using it now. I'm not a hyper or whatever, but you need to understand it and you need to use it. I guess the other thing that people don't realize is the most powerful people with AI using this stuff are the people who actually know how to build and run systems. If you know that stuff and how to codify it, you're no longer time constrained by what you can do because your ideas can just be implemented like that.

Nicky Pike (00:59:32): Yep. I couldn't agree more. If you're not already playing with this stuff, you are behind. You need to know this because just like we saw with Kubernetes, the platform team is going to become the people that are going to be told to go and standardize this to make the decisions, to help with the policy. So you better start learning it. And it is a lot of fun. I was a detractor, I love it now and you'll be amazed at what you can do with it. So last question, can we go ahead and say that you're a full-fledged member of the Evolution now?

Gari Singh (01:00:01): For sure.

Nicky Pike (01:00:02): Excellent. All right. Like I said, if you haven't been out and seen Gari you need to go out to, I'm going to double up on his Boston Kubernetes meetups. I've had the opportunity to talk at those twice now. It's a great group of guys and girls that are coming out and take part in this meetup and it's one of those, a lot of meetups died after COVID, but we see Boston coming back and that's a lot to do with Gari and people that are helping run that meetup. So if you're in the Boston area, go check it out. And other than that, have a great one. Thank you for listening to [Dev]olution. If you've got something for us to decode, let me know. You can message me, Nicky Pike on LinkedIn or join our Discord community and drop it there. And seriously, don't forget to subscribe. You do not want to miss what's next.