Kelsey Hightower's advice for platform engineers as AI looms

Transcript - Kelsey Hightower's advice for platform engineers as AI looms

Beth Pariseau: From Informa TechTarget, I'm Beth Pariseau, and this is IT Ops Query.

This podcast distills the signal from the noise about enterprise software development and platform engineering. Each week, we'll talk to expert guests about the latest tech industry news and trends that engineering and IT leaders need to know.

Don't forget to subscribe to IT Ops Query for more conversations on AI and the future of the enterprise digital workspace.

Kelsey Hightower is a highly influential figure in enterprise IT following a 25-year career in software engineering and open source collaboration.

He began his technology career as a systems engineer at the global payments company TSYS, then worked as a software engineer at the infrastructure-as-code company Puppet, a product manager at CoreOS, and finally as a distinguished engineer at Google. During his tenure at Google from 2015 to 2023, Hightower worked on Google Cloud projects related to Kubernetes, including the Google Kubernetes Engine, cloud functions and the Apigee API gateway.

He has also been a pillar of the open source community as a CNCF ambassador and was among the founders of the KubeCon annual conference for cloud-native technologies. Now retired, Hightower continues to work as a renowned public speaker, focusing on the fundamentals of distributed systems and platform engineering.

Thank you so much for joining me today.

Kelsey Hightower: Yeah, thanks for having me, Beth.

Pariseau: So, what do you think is the state of platform engineering overall? Do you think it's a mature discipline at this point?

Hightower: There are mature people who practice platform engineering. So, I think we have a nice shared vocabulary to describe the work. And I think that's good, you know, there's common tools people can use. So, I think that's the part that's a bit mature. You know, just like in real-world engineering or construction, people know what a hammer is, people know what a screwdriver is. It doesn't necessarily mean that everyone knows how to use a hammer and a screwdriver effectively.

And I think that's where the industry continues to struggle. Like, I think people are still trying to buy their way out of the individual skill set, individual discipline, required to be effective with any of these methodologies. So, that's the part where I kind of think -- since every five to 10 years we get a new big thing.

Pariseau: Yeah.

Hightower: A lot of people chase the big thing without necessarily recognizing that they've never gained, necessarily, the skills nor discipline to leverage the previous big thing. So, for example, all the technology that you needed to be as innovative, as big as Google existed 20 years ago.

Pariseau: Right.

Hightower: So, the thing you need isn't the thing that's coming out next week. The thing you need isn't the thing that came out 10 years ago, aka Kubernetes. It's the skill and discipline and ability that people that worked at places like Google had 20 years ago. So, I just hope that's the part that I hope people shore up on the maturity side.

Pariseau: Yeah, I mean, how do they do that, right? I mean, it's so much easier to buy a product, right? How do you recommend people start building the skills to take that kind of approach?

Hightower: See, this is the undeveloped leadership component. And a lot of this engineering work is all about making decisions and agreeing on an approach.

You can build a bridge a million different ways -- out of popsicle sticks, you can build it out of brick and mortar, steel. Budgets play a big role in this, regulations play a big role in this. But at some point, you have to make a decision. And once you make that decision, then the people involved in that particular project have to be willing to gain the skills necessary.

One big thing I think the industry has failed to do analysis on: Most people are building bridges for the very first time. Right? Think about it. Most companies that are doing e-commerce, they did it for the very first time. They didn't have any experience. It wasn't like this is the third or fourth rendition of their e-commerce site. It's their first version. And the people building it's like, 'Oh, what's a hammer? You want me to build this bridge by Friday? Sure, I'll try. I'll watch a few videos of other people building bridges. And based on that, I can absorb their experience and then have a bridge for you by Friday.' It just doesn't work that way.

So, I think how this goes is, like, you really -- you know how people say people are the most important asset? But they don't treat them that way. They don't necessarily treat them that way. I mean, we're really talking about honing people's skill sets, deeply asking them, 'Do you have that apprenticeship methodology in place where I can come in and learn from someone with actual experience?'

So, if you find your team trying to do something that they've never done before -- 'Hey, mobile is hot, we need a mobile app' -- has anyone on this team, has anyone at this company ever built a mobile app? No. Hm, we may need to adjust the team a little bit to bring in people who have built a mobile app and recognize that as a skill set gap that we have.

That means before we can set deadlines for having a mobile app, you might want to say, well, what's the deadline for getting people trained up a little bit? What's the deadline for making sure people feel a bit comfortable, knowing that this is going to be the first iteration and we lack the skills to determine if it's good or not? And so, we may need to revisit our entire process around engineering mobile apps because we've never done it before.

So, that's the part where I would like a little bit more engineering rigor to come into play. But look, it's only been, what? Four or five decades that we've been trying to do this, you know, software thing. So, maybe we need a little bit more time before we really start to, you know, think about those other aspects.

Pariseau: Well, it's not as old a discipline as, say, civil engineering, but yeah, it has been a while now. And it's interesting because it seems like there is just a little bit of a whiff of people trying to shortcut their way past people now with AI. You know? The idea that, you know, that's going to solve this organizational issue. And at a KubeCon session in November, you said something about AI being a surface-level technology. Can you say what you meant by that?

Hightower: Yeah, so, I mean, I think if you think about how these systems work, underneath it all, there's still some hardware, hard drives, CPUs, processors, the whole nine. There's networks, and then there's operating systems, right? The Linux kernel comes to mind, macOS, Windows. And then how you make those things do something. So traditionally, one surface technology we've used is programming languages, right? We write programs and then we put them on those servers, and then those programs pull the levers and strings through the operating system to make it do things, right? That's one interface to that.

And so, AI comes along. And I always write down on a piece of paper, 'What changes?' Does the hardware change? I mean, yeah, you need GPUs to train your models. But that aside, the programs you built still run on hardware, still run on those operating systems and still interact over those same protocols and networks.

So, the layers underneath are the same. This is not theory, this is not up for debate or discussion. Those layers are exactly the same.

EVs came out, the roads are exactly the same. So, the EVs have to have tires with treads on them, so they can drive on the same roads of yesteryear.

And so when we think about what AI brings to the table, on the surface, it can generate code -- same code we probably used to write. But I think it will also suffer from the same bridge-building problem. It doesn't really have any experience. It has reference. It has things it can draw from. But it has never been on call. It has never had to gain consensus over competing ideas. And this is why I think it works really well with a single person prompting it to do something -- 'Hey, team, go make your decisions, turn that into a prompt, and I will do what you tell me.'

And so, on the surface, that's great. But underneath the hood, the way we get to those prompts is still the same. You have to interact with people, you have to understand the real world, you have to understand your customer base. And then if you're really good with that, which most enterprises are not, then you can turn those things into requirements that hopefully you can prompt your way to success. And even if you did, you're still only dealing with this thing in the middle that still has to run on hardware and networks. And so all the security exploits are still there.

Pariseau: Right.

Hightower: The vulnerabilities are still there.

So, that's why I think of AI as kind of this thing that sits on the surface. And it's not -- now, when the computer changes, when there's no more classical Intel-type chips, when there's no more networks as we know it, and the whole thing is like a new machine? Then, yeah, maybe something's going to be totally different in that world.

Pariseau: Right. At the same time, it does seem to be here to stay at least on some level. So, how do you think platform engineering will evolve alongside AI over the next few years, say? Do you think AI will help or hinder? What do you see kind of coming in the near future for the discipline as AI continues?

Hightower: So, let's just say AI is trying to get to real intelligence levels. Right? So, we have thousands of years of experience of dealing with real intelligence.

Pariseau: Yeah.

Hightower: Right? Now, I'm not saying one singular person has the knowledge of 9 billion other people. I'm not saying that. I'm just saying collectively, as a whole, society has worked side by side with each other and machines, whether we're talking about hammers and nails and computer systems.

I think what we're talking about with AI is a form of automation. We're taking the experience that people have had over the last 50 years when it comes to computer systems and software, we're turning those into models and then those models get to draw from our experiences.

Either there's a belief that there are no more experiences to be had -- not by humans, right? We're done. Every potential experience we can have writing software is finished. And now those data sets are there. And now we just got to make the models better at determining which of the 9 billion people on Earth should it prioritize this experience from. Right?

So, if you take a million developers and you say they all write code in slightly different ways, which one should the model mimic the most? Is there a superior one? Do we combine the top 5% and have a mudge of those 5%, and that's the best software developer in the world? That's what we're talking about.

And so, let's say you come out with this tool. So, how does it live side by side? You have now the perfect thing that can generate code. I think the question shifts to, well, what code will we have it generate?

And that's when we get back into decision-making. So, side by side, if you tell me that platform engineering is going to be reduced to decision-making and nothing more -- let's just say we zoom out a million years, and AI is perfect. And the only thing left to do is make a decision. My guess would be, why would anyone in the world want to build their own platform? It would just be completely crazy. It's like, you know what? I don't like streets and freeways. I'm going to no longer drive on public roads. I'm going to start building my own roads, and I'm going to only go where the roads that I build take me. That would be insane. We would all laugh at that.

Pariseau: Yeah.

Hightower: And so, in this world that we're talking about, this hypothetical world, then everyone should just use some platform. Pick AWS, Google, whatever, because those systems will be almost perfect. And the only thing you would have to do with those systems is to describe what you want. 'I would like to sell cars.' And a website should just pop up that allows you to sell cars.

And then the question then begs ourselves is, well, how many of those permutations do we need? Do we need 1,000 websites that can sell cars? Are we going to reduce this down to a style and branding issue? And the way I would wrap up this thought process would be, well, maybe we get closer to the fashion industry. Every company has access to silk, leather, cotton, but why would someone want to buy a Louis Vuitton purse over the one you get at Walmart?

And so, it's style, prestige, taste, brand, reputation. And so maybe software starts to mimic that a bit more than the hardest thing being how to construct the software. Maybe the hardest thing is how to produce an experience, and then once you get that idea down pat, you can turn it over to the sewing machine to spit out the $10,000 purse instead of the $5 purse.

Pariseau: Right. Yeah, that's a lot of ifs and a lot of perfection to assume in the systems. Practically speaking, is there a way that platform engineers can influence the trajectory of AI, can maybe learn how to use it as just another tool in an ideal way?

Hightower: They can attempt to compete. And I'm going to say it very clearly: attempt to compete.

So, we saw this. So let's rewind the clock maybe 20 years because I think it will help us with some historical analysis. Platform engineering used to be data center operations. Right? A data center gets constructed, physical platform, power gets ran, network cables get ran, servers get mounted, cooling. And then those people maintain the data center, so that way there was a platform so you can run apps and services.

And then that gets into a more of a complacency. Whatever Dell is selling is what we're buying. Whatever HP is selling, that's what we're buying. We're not sitting around thinking about new memory modules. Most of those data center operators were not pushing the limits of hardware on their own. They didn't have labs and chip manufacturing at the height of what they were doing. They kind of just reverted to whatever the vendors were doing. That turned into, 'I am VMware certified.' 'I am Cisco certified.' 'I just use their tools.' And then, to answer your question, the impact for them was, well, you give feedback to your vendor. 'Hey, I don't like the way that this works,' right? And then multiple vendors provide competition to allow us to try to do the very similar things a different way.

Great. So, now, let's get to this version of platform engineering, which is largely, in my opinion, closing the gap for either open source or vendor-provided solutions. So, if you download Kubernetes, Kubernetes is going to get you, what -- 60%, 70% of the way there? The other 30% is platform engineering. All the customizations, all the scripts, all the config management you have to do on top, that is platform engineering.

So, where can we compete with AI? Well, here's the thing: You don't need AI to do something that you already know how to do. For example, if you told me, 'I need to move this pencil from the left side of the table to the right side of the table,' you do not need AI to do that. You can literally make a very simple machine that pushes the pencil from the left to the right and resets itself. That's straight up what you can do. And I think existing programming languages represent that type of symbolic programming logic: If this, then that.

A lot of things that we do can be solved with that kind of logic. It's very efficient. If you write a Python program that says, 'If a user of our platform loses their password, allow them to reset it if they're still employed by looking in the HR database.' You do not need AI or an AI agent to reset passwords. Oh my God, people, please.

Pariseau: Right.

Hightower: And so I think part of the competition would be, let's make sure that the most efficient ways of doing things possible are still at play. Do not lose your mind because you've forgotten the ways of the Jedi. You can totally use simple programs to accomplish simple tasks repeatedly and cheaply.

The other part, I think, for platform engineers is like, OK, if we have this new primitive, we should figure out where it actually works. We should figure out how to make it work. And we should figure out how to put it to use. If we fail to do that, then your vendor will be doing that. And the vendor will be selling to the business.

Pariseau: Yes.

Hightower: And I promise you, if that thing gets 80% of what you can do? The way business goes, I think people will favor the good-enough solution than paying someone what we're paying IT workers today.

So, I got a feeling that this trajectory continues, even in its current state, if we see 5% marginal improvement every one or two years, I think IT salaries start to revert back to something that looks a little bit normal, right? I think we forget that $400,000, $500,000 to $1 million packages was abnormal for the average worker in the world. So, I would not be surprised if we see these salaries revert to what construction workers get paid. We're just using a different type of material, right?

Because anytime an industry matures to this degree -- 'Hey, we need to install a water heater' -- that is a very known thing. There are really good tools to do that. And so the type of skill that I need from someone else goes down. Because they have really good tools that allows a lot more people to be able to do that. So, that's what I think is going to happen with platform engineering, is that the more this matures, the more it works, the more people will be able to do it -- which is actually a good thing. It's just, the inflated salaries will have to see a correction because it will no longer be this skill that only a few people can pull off.

Pariseau: And so, from an IT leadership standpoint, how do IT leaders navigate that path between the business and 'Oh my God, we got to get this AI thing' and employees who might be rightfully scared about what it means for their careers, and how do you kind of balance those two forces pulling you in opposite directions right now as an IT leader?

Hightower: As someone who has been an IT leader, I'll reflect on myself. There was a time when we didn't think very strategically at all. And I don't think it's our fault per se, because everything was about firefighting.

Just think about it. You're asking me to manage the ticketing system, the Oracle database, all the hardware, the VMware licenses, all the laptops, every one-off that everyone wants to do and could imagine, HR's financial system, all of these random things that are not even built in a cohesive way. In many ways, I'm not even making the decision to bring those technologies in. And I'm also being hired into a company where these decisions have been made decades ago. And they still need to be maintained and innovated on without the time and space to do those things.

And so, I think the IT role has been more of this, almost, 'You're here to maintain these systems and make sure that they work. We don't have time for you to innovate in the classical sense of innovation.' And so, in that world, if you're not thinking about any -- I'm talking about real strategy. Not this, like, Deloitte/Accenture stuff. I'm talking real time to sit down, understand your system deeply, and get to experiment and try things so that you are a better person at the job that you're doing.

Without that, there is no real competition in that. Right? What you're going to be asked to is, say, 'Hey, we're going to buy this AI system from this company. We want you to install it and make sure people are using it.'

'Hey, there's an upgrade to that system. We want to make sure it's installed. We want to make sure that you're using it.'

'Hey, we don't need you anymore.'

We've seen this multiple times. And I'm not saying that's the goal, but if you're not competing, that is what will happen. So, what does competition look like? Competition looks like first saying, you know, for 20 years, some very amazing technology has been available. Why have we failed to use that stuff at the highest levels? Cloud came out over a decade ago, IT companies still struggle with cloud. I mean, they struggle turning things off -- 'Hey, we don't know what to turn off.' So if you struggle with that, then there's something that needs to be adjusted here. This is not about what's coming new and making an adjustment. It's realizing that we've never found the time and space to get good at any of these technology revolutions.

And so, if that's the way we're still operating, AI is a little bit different here because that one is trying to be good on its own.

Pariseau: Yeah.

Hightower: The other technologies required an operator. 'Hey, here's a better tool for you to use.' This one is saying, 'I'm operating in a model where I can tend to operate myself. I just need a nudge in the right direction.' So now you have a tool, maybe for the first time in your career, that is designed to do your job. So, you are now effectively training your replacement.

Pariseau: Yeah.

Hightower: And in a good world, in a world with good people with good motivations, this is what we actually want to happen, right? Because in that world, under the best conditions, if we get all of this automation, who cares about jobs? Why do I want a job if we can build enough automation to do everything and then people can just live? Now we've got to figure out human purpose, and there's lots of things there. But all the resources necessary to sustain human life are already here.

Pariseau: Right.

Hightower: And so, if this just comes down to how do we divvy up those resources in a way that people don't have to have a job in order to share in that, that's a different game. I think that's a whole cultural, societal shift that has to take place. But if you remove that element, why wouldn't you want the ability to fully automate everything?

And I think if you take that off the table, this feels like a net win.

But when I think about all the other aspects of this stuff when it comes to humans, for me personally, it starts to feel a little bit like a net loss. I'm a musician. I want to live life, be motivated by life, and then create a song for you to listen to and hear my life through that song. But if someone could just push a button that says 'Generate me a love song,' and that's the No. 1 on the chart, then what's the value of life at that point if it can just be a button push away and experiences don't matter?

Pariseau: Right. And at the same time, I was having conversations like this at tech conferences when serverless was big. You know? 'All these people are going to be out of a job, and it's gonna replace everything.' You know? I mean, do you think that that's actually finally come to pass with generative AI? Or is NoOps just as elusive as it's always been now?

Hightower: Yeah, we're not doing any ops until they build perfect systems. As far as I know, no one in the real intelligence world has ever built a perfect system. So, we don't even have a reference for what 'perfect system' looks like. It's not even in the training set. So, there's this idea that the ability to build a perfect system will emerge on its own, like it will just fall from the sky. So that, that part is what makes me feel like the people who talk that way are just really -- they've never seen a perfect system in their lives.

Pariseau: Hm.

Hightower: And so they believe that one will be made from an imperfect one. And that's the fallacy. So, like, when I saw serverless, I saw through that one immediately. Like, I have conference talks, like, I don't know what you all are talking about at all -- at all.

Think about it: Serverless runs software with a very opinionated view on how to run software, and you must conform. That's a good thing. Roads are an opinionated way on how to drive. We have lanes about this wide. We have signs and exits, so it's not surprising that a lot of people can drive, because you don't get to design roads before you drive. You have to drive on the opinionated roads. So in many ways, roads are 'roadless,' because you don't have to design them first, you can just use them.

So, when I saw serverless, I'm like, who's writing the software? You are. That's the Achilles' heel. People will continue to write less-than-optimal software. I don't care if it's the easiest thing in the world to deploy, it's going to be broken in subtle ways. Always.

Now, if we're saying that humans will no longer write software, and some way, somehow, a machine that is also imperfect will produce something that's perfect. Like, will a human one day give birth to the perfect human? It doesn't make sense. So, to me, when I think about this from practical terms, you have an imperfect machine that you believe is going to create a perfect machine from itself. I don't know if that is even possible.

So, that's where I stand with it. It's a tool that has learned from real intelligence on how to potentially do things. There's no such thing as perfection because we appreciate opinions. We want the website to be blue, we want a slider instead of a drop-down. These are all configurations and decisions. And sometimes, even if you implement these things perfectly, it may be the wrong decision. Your users may not like -- I remember when Microsoft tried to move the Start menu. They tried to move it from the bottom left, and people lost it.

'Hey, put it back. Put it back.'

'Well, we've done some research. It's not in the optimal place.'

'Don't care about optimal. Put it back to the bottom left, and it better look like the one that we saw on Windows 95. If you change it, we have a problem.'

Pariseau: Yeah. So, is it just about sort of, for the time being, platform engineers finding those imperfections with AI and kind of shoring those up to compete? As you said, about competing with AI. What's the best way for people to forge ahead with that?

Hightower: Find the imperfections in your team. Why can't we utilize technology efficiently? Why are we struggling with Kubernetes? Why are we struggling with VM still? Why do we struggle with networking? Why do we struggle with cost management?

If you start to answer those questions, then I think it's going to be a little bit easier for you to discover how to effectively leverage AI, right? Because you say, 'We're going to bring in AI.' The question is, when should we use it? Ideally, we should use it when there is the no more efficient way to do the thing.

So, I'll give you an example. We need to clean up disk space on the servers. When servers get full, they run out of disk space, and that can cause the server to crash in extreme cases. What is the most efficient way to free up disk space?

Number one, stop putting things on the server that don't belong. That's a discipline thing. So, you don't need a solution if you don't have the problem. So, stop putting things that don't belong on the server. 'Kelsey, tell me in practical terms what that means.' Do you really need to store logs on the server? Well, maybe a little bit of the logs, but not five years' worth of logs. So, let's just remove logs older than 90 days from all the servers. Voila. There are no more disks being full. Uh, I know, buy a bigger disk. Aha, you're cleaning it less often.

So, these are like common-sense things you can do before you get to AI. What people make the mistake of: 'Oh, let's bring an AI system in to manage data on the servers. Look at it, it's intelligent, it's finding all the log files, and it's only costing us $20 every time it tries to do this thinking thing.'

It's like, what are you talking about? For 10 cents, you can write a Python script that just looks at files older than 90 days and moves them to another place proactively. And it can run forever. That's what I mean.

So you're a platform engineer, you step back and you say, OK, we don't need steel to build a bridge for your pond in your backyard. We don't need steel. We can use two-by-fours. Totally. Go get them from Home Depot, we're done here. We don't need to bring in a crane and cut down the steel beam to the size of your pond. That's overkill. That's what I think platform engineering is about -- it's engineering, not 'Let's find a use case for AI.'

Pariseau: You mentioned that AI might be a little bit easier for people to navigate as its own kind of framework or library. That, you know, replacing DSLs might be an advantage to natural language interfaces using generative AI. Is that an area where platform engineers could put those things into practical use?

Hightower: So, I think we would think about -- so, if we stop treating AI like magic and we start treating it like a practical thing -- so what is AI really good at? Sometimes AI is really good at correlations. So if you have, if you're a platform engineer specifically, we've learned that if you put all of your logs and metrics in a single place, like Datadog or Grafana, then people can run queries on it. The problem is, they need to understand the structure and shape of your metric data. Right?

So, in order to find the server that's using the most memory, I would even have to know -- I would have to know a little bit about the structure, right? 'Select machine name where memory in kilobytes equals the highest.' That's way too much. That is not natural, by the way. That is something that is optimized for the computer, not humans.

So, where do I think LLMs, large language models, that can then integrate with those underlying things -- remember, those things are still there. The AI does not replace those query languages.

Pariseau: Right.

Hightower: But what I think AI does really well at is, though, is doing that translation component. Now I can say, hey, what server is using the most memory? And from that, the model can say, 'Hm, they're using Grafana. And looking at the current data, I think what they need is a query that looks like this, because we have 1,000 internet posts that show people that if you ever ask that kind of question, you probably want a query that looks like this.'

And now that we have the ability for this thing to kind of check itself, it can construct a query, and it may hallucinate and get it wrong. It can try to run the query, get an error, read the error message, go back and try to rewrite the query and say, 'Ah, I got it. Is this what you mean?'

And so now, as a human, we can say that is exactly what I mean. Or that's not quite right. You've given me disk space, I want memory. So, OK, let me try it again. And so now what we have is this nice iterative way of programming that, I think, existing languages never offered us, even if these things are still spinning out those programs.

And so, I think that is a net win. Like, even as someone who is kind of an AI skeptic, there is nothing wrong with building surfaces for real people to use, and then that expands the number of people who can now interact with these systems. That's why we have websites and mobile apps, it's because we try to have something a little bit more friendly for people to kind of do things with these computer systems than learn how to program them as a starting point.

Pariseau: Yeah. At the same time, to your point about the sort of scarcity of skills that platform engineers have capitalized on, that also -- if you democratize that system -- it does call into question the role of the person who used to be that translator between what do you want this platform to do and writing the code to make it work, right?

Hightower: And honestly, I think that needs to go no matter what. Mainly because I think the person that was making the request typically didn't have the vocabulary to make a precise request. And then they open the ticket, and we have so much back and forth that we have to create new roles. Oh, this is a project manager that now has to manage all of these requests and sort them out, determine if we're going to even address them or not. And you're sitting there, like, you know, all of us are being paid to wait.

That is a very expensive endeavor. You're being paid to wait at a lot of enterprises. So, imagine a world where I can now safely, hopefully safely, with the right guardrails say, 'I would like to interact with this system. I just need a report. Do we sell more blue shoes or red shoes?' That's it. That's all I want to know. I don't want to go talk to the DBA that then goes into Oracle, that then tries to craft a query, that then puts it into Jasper, so then I can click a button to get a report, but I've got to ask IT for permissions to access that -- well, come on, stop! Whoa, whoa, stop!

Pariseau: Yeah.

Hightower: No, no, no, no, no, we can't be doing that. So, I think it is a nice way to say, 'I have a request, I understand your request. If I don't understand the request, let's push that loop to the user making the request.'

Pariseau: Yeah.

Hightower: This is why I think this idea that you can iterate on your own prompt, and then it says, 'You know what? Based on this prompt, you have permission for me to try to generate a query. I'm going to generate a query and save it in my logs, and I'll let you see it if you want to do something with it. But here's the data I returned. Does this look like the data you were looking for?' That is exactly the data I was looking for.

I think what people then forget is that, what we can do then, is we don't have to keep going through the AI for every subset request. We can now say, 'I need to do that again.' And they can say, 'Oh, well, I already have that program generated for you from last time. Let's just make that a shortcut.' And so, you can just kind of click on the shortcut, and there's no need to do generative AI for something we already know how to do. And that's where the efficiency comes back into play.

Pariseau: Right, right. Yeah, there was some talk during that KubeCon platform engineering discussion about kind of looking at AI as a new front door for the platform.

Hightower: Surface-level technology.

Pariseau: Yeah, right. But it could be a nice front door.

Hightower: It's a beautiful front door.

Pariseau: Right. OK, well, is there anything I haven't thought to bring up in this discussion that, you know, is on your mind or that you would want to mention?

Hightower: No, I think we covered a lot of ground. I know a lot of people that may listen to this, that have these jobs, and they are just jobs. And the question is do we evolve the job? Or do we wait for the vendor to evolve the job?

And I think that's the kind of decision on the table. And I think people got freaked out when servers were first introduced to the business world. I think people got freaked out when scripting and programming languages got introduced to the world. We're just going to script everyone out of a job -- didn't happen. We got paranoid when configuration management, Puppet Chef and Ansible came out. We got freaked out when cloud came out.

And so, I think now we understand that there will never stop changing these things. These things will always continue to change. And this is why I always mention to people, I think there is value in training your own model.

If these tools are going to get really good -- as someone who's, like, discovering woodworking for the first time, a very mature industry and discipline, there are so many tools at your disposal. And so, what makes one woodworker better or able to execute better than another woodworker? They just know how to combine these different tools together to produce something like a cabinet, right? Like, hey, you could try to use a chisel for that, but we can now create these dado cuts with just one pass and get the depth that you want.

And so, it's like, but you still need to know the fundamental of how you would join cabinets together. So, I think now is probably the perfect time to go back and say, hey, what are the fundamentals to this whole concept of the technology industry? Let me zoom out and say, hey, what tools are available to me? And you might look in your tool belt and say, oh, my tool belt's outdated. Maybe I'll bring in a few -- and I got some that are still super powerful, but I've never learned how to use them correctly. So, they're just collecting dust.

And I think that's probably, now it's probably the right time to train your own model, get to a point where -- and I think you're going to be asked of this -- what value do you bring over the machines? And the closer that answer is to zero, you're going to have a problem.

So, start doing that analysis right now. Ask yourself, 'What value do I bring over the computers?' And I promise you there's a lot of value that humans bring over the computers. Go figure that out for yourself and make sure that those skills are as good as the other ones that you have.

Pariseau: Great. Always great to hear from you, and I really appreciate you taking the time. So, thanks very much.

Hightower: Awesome. Later, Beth.

Pariseau: Thank you for tuning in to IT Ops Query. To learn more about enterprise software development and platform engineering, explore our content on Informa TechTarget sites. Find us on YouTube at our channel, Eye on Tech. Subscribe to our podcast to receive the latest episodes as they drop. And if you liked what you heard today, give us a rating and review on Apple, Spotify or wherever you're listening. Thank you for joining us.