AI-Native Ops: Making AI Safe for Production with William Collins
What happens when your “coworker” can generate code and changes faster than your team can review them, and production still has to stay up?
William Collins breaks down what AI-Native Ops looks like when you take reliability seriously: where reasoning should stop, where deterministic automation should begin, and how guardrails like compliance checks, version pinning, and controlled workflows keep AI from turning into outage fuel. Cory and William also dig into why context windows and tool sprawl matter in real systems, how protocols like MCP and agent-to-agent communication are shaping day-to-day automation, and why regulated environments can’t adopt new tech with hype-driven shortcuts.
If you’re a platform engineer trying to balance speed with safety, this conversation offers a practical way to use AI for the work that drags teams down, without giving up operational discipline.
Guest: William Collins, Director of Technical Evangelism at Itential, AWS community builder, and the co-host of the Cloud Gambit podcast
William Collins is a strategic thinker and catalyst for innovation. Over his career, he has helped enterprises build large-scale networks, driven modernization through cloud adoption, and excels at optimizing complex environments through good design practices and automation. Today, William works as Director of Technical Evangelism for Itential, where he focuses on evangelizing the Itential Platform, fostering strong relationships with customers to fully realize their goals, engaging with community, and advocating for the successful future of network, security, and automation infrastructure.
As a content creator, William hosts The Cloud Gambit Podcast with Eyvonne Sharp, a show that unravels the state of cloud computing, markets, strategy, and emerging trends with industry experts. He is also a LinkedIn Learning Instructor (Automation, Cloud, and Network Engineering Content), AWS Community Builder (Network & Content Delivery), and is a group organizer for the USNUA - Kentucky User Group (KYNUG).
Prior to Itential, William worked as a Principal Cloud Architect and Director of Technical Evangelism for Alkira where he helped grow the company from lean beginnings to being ranked 25th Fastest-Growing Company in North America and 6th in the Bay Area on the 2024 Deloitte Technology Fast 500. He also held various senior technical roles across the enterprise space in Financial Services and Healthcare, most recently at Humana as Director of Cloud Architecture. Outside of tech, his time is spent with family, woodworking, ice hockey, and guitar.
Opinions expressed are solely his own and do not express the views or opinions of his employer.
Links to interesting things from this episode:
Transcript
Welcome back to the Platform Engineering Podcast. I'm your host, Cory O'Daniel.
Today my guest has one of those careers that genuinely spans the full stack of infrastructure, from building large scale enterprise networks, to cloud architecture at a Fortune 50 healthcare company, to helping a startup from 0 to the 25th fastest growing company in North America. He has seen the industry from just about every angle you can imagine.
He's currently the Director of Technical Evangelism at Itential, an AWS community builder and he's the co host of the Cloud Gambit podcast, which I was lucky enough to be on last year. Excited to be flipping the mic today. William Collins, welcome to the show.
William:Thanks for having me. Excited to be here. Your guest lineup is next level. You got some good, good episodes. It's been really fun to go back and listen.
You know, it's like binging a TV show, so you gotta wait for stuff to come out. I'm like, "Oh, what's coming on next week?" I missed out on this podcast for a while and there's like this whole lineup of stuff and I do all this driving all the time. Like my kids play travel sports and it's great because I have all these things queued up. So it's been good.
Cory:I appreciate that.
You know, honestly, turns out like most software engineers are just engineers who like talking about nerdy shit and if you cold email them, they'll come on your show. Like when Mitchell Hashimoto responded and was like, "Yeah, I'll come on the show." I was like,"I don't know why you're wasting your time with me, bro."
William:You know, I switched to his terminal recently. So I was using like iTERM and different things, and I'm not like a Vim with plugins kind of person, and I started using Ghostty and that terminal is so fast and so refined. I'm a fan, you know. Mitchell's... you know, thank you. Thank you for the contributions.
Cory:Yeah, I've switched to it too. Like when I'm doing pretty much any like CLI stuff, I'll leave VS code just to be in Ghostty to test it, just because I feel like it looks so much better than... VS code just... I feel like it tries to torture you with some emulation of a shell that sucks. But Ghostty is beautiful, especially if you're starting to do two e's like it's very, very nice. We'll put a link in the show notes for that for anybody who's not familiar.
So one thing I'd love to hop into, I'd love to learn a little bit about your background. Just kind of like how you've kind of gone through the gamut and gotten to where you are today.
And then would love to like go into the AWS community builder stuff that you're doing a little bit as well. I feel like that's a title that I hear a lot and I actually am not familiar with the program whatsoever.
William:Awesome. I kind of got into technology by accident. So I had a major surgery when I was younger. I had this major back surgery I had to go through. I was at home all the time. You know, I was younger... I think sixth, no seventh grade... and had a lot of time on my hands.
And I had seen this... I was in a building at work with someone and I'd seen behind this kind of glass or this door that was open and all these racks of technology. You know, just server racks. And, as a kid, I was like, "That is, whatever that is, that's just the coolest thing I've ever seen in my life. Whatever that is, I just want to do it. That's it, you know, that's it right there." And so on top of that, like when I had that surgery, somebody gave me this "How to install Slackware" Linux magazine with like a whole bunch of thousand floppy disks. And like I couldn't do anything else. There was books that I'd read and just different things at home. But I just had all this time on my hands, so I ruined my parents... I forget what version of Windows... and I installed slackware on that sucker. And there was no going back from that. They're like, "We can't fix this. You can just have it. We're going to get another computer." So that worked out really well for me.
And then at some point I realized you could make money doing that stuff like just working with technology. And in high school I actually started an internship at ISP.
Cory:Oh, very cool.
William:You know, and that's where I started getting my network chops.
So I was already like writing. I remember the first time I put like four or five commands on a file and I ran it, you know, just a simple bash script, and I just thought, "That is the coolest thing." Like I still remember that feeling. Like I was so excited, it was just amazing.
And then getting into the ISP and then going on... I worked at a global, a multinational financial services and professional services company. That's where I got into... and it's all about opportunity. Like I had an opportunity, they had a team that didn't really understand... it was like a SysAdmin team dealing with like non human accounts and they were going through and doing all this stuff manually. I was like, I can write a bash script that'll knock that out in like a minute, you know, with all this account provisioning and different things.
Once I did that, I ended up landing a place on that team. I did that for a while and I became very hyper focused in network engineering at that point because... I think the thing that stemmed that was... it was actually when we were finishing like the whole VMware physical to virtual server migration stuff and I was a part of that on the server side. So like the way that you're teaming to like nix and you're teaming everything to network devices, it's different... you know, with the hypervisor stuff.
So I ended up working and building relationships with some of these network engineers and then they invited me over to, you know, have a spot at their table. Then that's when I got really hyper focused in network stuff and automation through the whole way.
Like I pushed bash scripting to like the brink and I finally was convinced to pick up Perl and then it was Python and then just Ansible, Terraform, anything that's saving me time really.
So all these things were going on and at some point, you know, cloud computing came along and nobody wanted to touch that with a ten-foot pole on the infrastructure side because you're putting your intellectual property in someone else's data center. And nobody would ever do that in the early days. I was hesitant about it too. I was like, "I think this whole thing's going to flop but I'm going to volunteer because it looks cool."
And I ended up just getting that kind of ground floor experience earlier on in the enterprise, which kind of set me out to grow. I moved over to a healthcare company, did a lot of stuff there with cloud. Two different healthcare companies. And one had a pretty good sized hospital system.
And then... yeah, I've been learning, trying to just reinvent myself and try not to fall dormant and just get in that level of comfort where I'm not growing, because then you find you're actually moving backwards at this crazy pace of innovation. So at some point I just said, "Hey, enterprise is tough." I kind of got... you know, I wanted a different look and I ended up moving to the startup space after about fifteen years doing enterprise tech. And I've been pretty happy at the startups I've been with. It's been a blast.
Cory:Yeah. And you're at Itential today, right?
William:Correct. Yep.
Cory:Yeah. Can you tell us a little bit about Itential?
William:So our founders, Chris and Ian... like, one of the things I love about this company is like, they were really early on in taking like an API first approach to building their platform. Which makes sense for a ton of reasons, and I love that.
And basically, I think if you look at a lot of our literature online, you'll think that we're like network only or network focused maybe, but it's really general infrastructure.
So, I mean, really, anything that has an API, we can work with it and we can, you know, take old stuff, new stuff, and kind of set up a repeatable way of executing a workflow across different technologies. You know, maintaining compliance, doing compliance checks, and really putting... I think the key value in my mind is just the guardrails that you're able to put around these things, which becomes really important if you do start doing AI things in an enterprise context.
You want to make sure that you have your deterministic stuff that's happening at the end of that tunnel. But then where does the reasoning stop and the deterministic outcome begin? Keeping the end result to be very deterministic is very important. So that's kind of the play there.
Cory:Yeah. So what's really interesting with that is like the determinism and reasoning bit of it. And I feel like... for everybody who wasn't on the call before we hit record, we were talking a little bit about just like the general vibe of the space right now. Because it really does feel like... there was a whole booster network like a year or two ago that said, like, code was solved, and then it seems like everybody woke up after Christmas.
It's like people went away for the holidays, they came back, and now everybody... even the people that I was seeing very resistant to the idea of AI in the DevOps space... is now talking about how it's here and it generates the things. But you also still see so many people struggling with getting good output from these today. And it's the lack of... probably guardrails in many cases.
How do we think about, or how do you think about these new co workers of ours, these agents that can just produce code at a volume at which no Ops person has ever had to deal with? Like our entire job has been maintaining stable systems in the face of changes from the Developers. And now that change is almost constant.
Like, how are you guys thinking about that? How are you reasoning with that as a person?
William:First of all, if we're really honest with ourselves and we look at the full... kind of the.. you know, the diffusion of innovations theory, like the proliferation of technology through a given market. You have your hyperscalers that are like building the stadium and the speakers, the electricity, all the things. And then you have your folks that are going to like, where the puck is going. And then the companies that are not going to adopt anything unless they absolutely have to... it might be a lack of skill or, you know, a lack of other things.
But I think it's important to, you know, frame that well. If you look at the actual adoption, Gartner has numbers out... I think it was, when I was looking last, it was like, you know, zero point something percent of companies are adopting this, but it's projected to uptick to like 15% or something in a few years. It was like one of those things.
You know, adoption's hard with technology anyway. Doing AI in the right way is very hard, but you still have the same dynamics and there's so many parallels, Cory. When cloud computing hit, like there are so many parallels, it just breaks my brain.
So I remember sitting in a meeting and the first time I ever heard "digital transformation" and what that meant to the company I was working with at the time is, "We're going to get rid of all of our data centers and mainframes and we're going to have everything, all our thousand apps, in the cloud inside of like 18 months." And I was just like, "Whoa, that's what digital transformation is? That's crazy."
You know, and that's a lot of what... kind of like the hype surrounding AI. Like there's these grandiose... like, we don't focus on the things. Like what I use AI for mostly is like managing Git flows. Like a lot of busy work. It saves me so much time.
Cory:Yeah.
William:Like the fork and pull model with open source is no slouch. Not that it's hard but like all the things take time to write and do things with. AIs are really good at doing those things, but we tend to focus on these grandiose... you know, like, we're not even going to talk about cars with wheels or, you know, just electric EVs, we're going to talk about flying cars that are, you know, flying around the stratosphere. Like, we're making these gigantic jumps.
So I think it's important to just frame that along with... what I'm seeing right now is like, there's two camps of folks out there. Like, there's the one side that says, "Hey, I'm going to, like, go make a Keurig and this AI is going to write me a production grade, you know, billion dollar company and I'm going to come back and, you know, record a YouTube video about it, and now I'm a millionaire." There's like that camp and then there's this extreme on the other end that's like, "Everything's slop. Everything AI touches is slop, slop, slop, slop. Dead, dead, dead." You know, extreme everything is slop.
And I feel like in reality, and this is where we tend to focus at Itential especially, is like, there's a reality to this. And the truth is probably somewhere in the middle, like most history tells us. Like, there's a balance, coincidentally. Like, it doesn't have to be a hot take with every new technical innovation that comes our way. And I think digging into that messy middle is where a lot of the value can be found and where a lot of the good conversations can be teased out.
That's my take on it, anyway.
Cory:Yeah, I've been writing in a very similar vein recently. Like, I feel like the entire industry is just people that, like you said... it's like, "This isn't going to work, it's all slop" and "Magic is going to happen." And it's like the reality is, if magic does happen, the other side of that magic is fraught with terrors, right?
Like, if this all just magically works, about twelve people become the most powerful people on the planet, right? Like, we're just chained economically to these twelve things, right? But on the far side, these people are just like, "This isn't going to work whatsoever."
It's like, it is and it does. And, like, one of the things I struggle with is like, this new workflow is so beneficial to me. Like, I can't imagine going back to writing software like I used to. Like, it would truly just grind me to a halt. I'd probably be very bummed out.
At the same time, at the end of almost every day, like, I feel token anxiety. Like, I get to the end of the day and I'm like, "My computer could be doing more shit that's productive and I'm over here wasting time eating food." It is a very, very tough balance. And the reality is, we need to figure out how to get this middle ground to work.
And I don't know how I do that personally, but there is big value to this. And yeah, it will produce slop, but the importance there is these guardrails. How do you stop it from producing slop? And the really funny thing that I kind of started to see is it's the same stuff we've been doing in Ops and DevOps and platform engineering forever.
Like, we've always just been trying to put guardrails around unsafe code going into Production, and now we just have it going into Production much quicker from a lot more software developers. And so I feel like a lot of the work for Ops is... it's the same work, we're just doing it in a different way.
And there's so many folks that have been saying, like, "Oh, our jobs are gone." And it's like, "Dude, if anything, we have become way more important because Prod still has to run." It is a very interesting time. It is very damned if you do, damned if you don't.
William:Yeah, and a lot of the skills... I've been using skills a lot lately. I'm trying to follow the open standards of things as far as, like, my workflows.
And it's so funny, I recorded an episode with Eyvonne the other day where we were talking about how it's almost like we've gone back and we're doing waterfall again, in a sense, because you have these gigantic skills files that basically define the whole. It's like a consolidated and faster version of waterfall in a way.
You're clearly documenting every outcome. You have the whole thing. You have, "Okay, this is what good looks like. This is my checklist at the end of all the things I want you to check." You have all these things in this gigantic monolithic file. And AI does really good with that. It does incredible. And then you iterate after that, of course. Like, if adjustments have to be made, you make those adjustments.
But it's just interesting thinking, like, "Wow, it is kind of like waterfall in a sense." You know, this is where we're at.
Cory:You know what's really funny about that? So since I've started like leaning into this... I'd say its probably been about five or six months that I've been doing like AI-based development or AI-native development or whatever... and I've always been a test driven engineer. It's just... I lost a bet in two thousand six, I lost $500 over TDD being better than what I did and I just never went back. That bets for another time.
But what's funny is, the way I drive most of my prompts is I write my tests first and I say, "Go make this so." And that is kind of like seeing the spec kits of the world. That is what we're coming back to. And it's funny because you do have to think about the outcomes. It's a lot more different than the agile way of, "Let's just get something out there and see how it works and then iterate on it."
It's like, well if you have vague requirements and you give them to a vague randomness machine, they're going to get more vague. Right? And like the more specific you are and the more you think through it and the more code quality tooling you have around it, the better output you get.
That's just it. And it is interesting, I've never really thought of it... of like kind of going back to waterfall, but it does feel a bit that way.
William:It's kind of like waterfall on crack. It's waterfall but much quicker in a sense. I mean that probably is like a really weird way to frame that, but really it's like waterfall on speed because waterfall is known for being slow. But when you have like an LLM that's like your team that's building the code and doing the things, it doesn't feel like waterfall but in principle it kind of, I think, resembles waterfall more than MBT - iterate a little bit, get feedback, iterate, get feedback, iterate.
It's so funny and working with... especially at my last best startup I was with... when you're helping with the product side and you're actually talking to a customer and you're trying to encapsulate what they want at the end of the tunnel. Like if you just go with it and you build exactly what they wanted and then they use it... well, it usually isn't exactly what they wanted. There's some sort of thing there. Which is why those little feedback loops are very helpful.
You know, it's either testing, you know, with beta versions of things, feature flagging, all that stuff and making it to where they can test and really give feedback to make sure that it's hitting the mark on what is actually being asked from the product perspective.
I do think that AI speeds up a lot of these things, but also with those vague requirements, it's going to have more of its creative flexibility to fill in those gaps and it's trying to get to a working thing at the end of the tunnel so it will fill in all those gaps. Whether, you know, it's the right gaps that you wanted filled or not. And I think your test driven comment was great because I mean that's software hygiene 101.
You've got to think about and build the testing before you build the whole product. Like you don't build the whole product and then go back and, "Oh man, I've got to write tests so these people won't gripe at me." Like that's no bueno.
Cory:Unfortunately, that's where a lot of our engineering partners are, right? Like, there's so many people I know that are like, "Oh, I hate writing tests." It's like, "How do you...? I don't know how you live without them." Like, I would be frazzled and bald, stressed out as shit. Like, that is my de stressor, it's my checklist before anything I do.
There was this paper the Anthropic published a few weeks back about like the agentic harness. This idea of letting these things have their freedom, but having external systems, you know, like Itential, like being able to guide them in the right direction. And a big part of that is, you know, when we think about the context of these things, you know, there's only so much that can fit in their window.
And it's funny, like the more context you give them, the better their output is, right? And if that context is guiding them in directions, that's more of their memory that they're spending up with really good rules for how their code should behave versus a lot of memory for them to get interesting and very random.
But like thinking about how Itential ties into these agent workflows, how do you fit in that workflow with DevOps or platform or software engineers? And how are you all thinking about that interaction between the person and the system that was created by agents, and agents and the actual system? How do you see us all participating in it together?
William:I love that question so much. But I want to go back to what you said before you asked the question about the context window. I think this is something that's so misunderstood, and unless you have a little bit of understanding around it, you don't understand why certain companies are taking an approach that they're taking with these things.
The context window is of course, this technical limitation that affects how we see systems. There's something called an attention mechanism which basically... every token attends to every other token, is like the gist of it.
So if you have a very small input sequence, that's fine. But as that input sequence grows, the number of interactions grow quadratically. So if you double your input size, you quadruple the computational stuff. Because longer context windows, they're going to be slower to process. Very long prompts are gonna, you know, you're gonna token your bank account to death. You have diminishing returns on performance with these big windows. Like, you're not actually getting... you provide too much context and you're gonna confuse the thing and you're not gonna get the responses that you need.
So the way that we thought about it from the beginning... We have a gentleman by the name of Peter Sprygada who was like the brains behind Ansible for networking. He's very much like, "We're not just going to jump into the fray and then build something without understanding the value."... So when we first decided to enter into the foray of a zillion MCP servers... what a lot of companies were doing... it's kind of like when REST came along and there was so many, there's like a proliferation of REST APIs everywhere, and then you had REST gateways and things, API gateways and whatnot.
So, I talked with Peter and as we were like thinking about all this earlier on, the goal was, "Hey, let's not just do this whole... you know, we have all these API specs, we could just take those and shoot them through a machine and out pops a tool for every endpoint in our... you know, we have thousands of endpoints, so we'd have thousands of tools... well, that seems like a really bad software engineering practice. So why don't we actually do it the right way and make like a stable MCP server core, separate the actual tools that you can build and introduce, and be able to filter those tools with what you need so you don't bloat the context window?" Because we wanted to start out, like thinking first principles with the architecture and that's what we did.
It's funny because I think in my mind I'm like, "Okay, we were a little late on getting our MCP server out, but I think we're very early in getting out an MCP server that was actually thought through." So there is a distinction there. And then from there, as far as how we see it, we have to look at the bread and butter of what our platform does.
What it does is it gives enterprises and service providers and such a platform that can chain together all these different things and provide a deterministic outcome every time, that's grounded. You know, compliance, guardrails, all the security things that kind of meet these companies where they're at.
So then if you think about what is so hard, even with Terraform - automation, software development. Like a lot of the times the innards, the core of what it does, is not super, super complicated from a user experience perspective, but what is complicated is all the different inputs that come into the machine. Like it's such a vast array of different things.
How do you know if an input coming into the machine is in the right format? How do you know if it's... like there's so many different things and so many different approaches for getting structured input into the machine across all these systems.
I think that is one of the beautiful places to start with AI, is to wrangle and get under control all the various inputs from all the various places and get things going through this existing deterministic, structured workflow that you already have. So you're getting the same results every time.
Because, I may be wrong, but with core infrastructure, with bare metal in data centers, especially the places that... you know, I talked to a lot of folks that still don't have robust like out of band management, they don't have a Raritan connecting to all their devices. So if an agent were just to go in willy nilly and read, I don't know, Cisco or AWS documentation and say, "Hey, I'm going to go in and do X, Y and Z on my own." Well, the outcome of doing that, or generating the code to do that, could technically cause an outage because of all the different versions, you know. Is all the infrastructure as code... have you statically pinned all your versions across providers and modules and all this stuff? Or are you just, you know... I talked to somebody the other day that was still in an environment where they're just using the newest of like everything and then stuff breaks all the time. And he's like, "Yeah, I've been trying to get them... like we gotta pin our versions and do this, this and this. But they..."
Well listen, like that's a serious problem. So if you have AI going through and doing that fresh every time, that's typically going to be the result. So I would say our approach is trying to stay practical, like trying to meet these companies where they're at and use AI for what AI is good for.
While understanding there is a North Star, there's a lot of architecture, there's a lot of fun stuff out there that folks are doing, and all that's great. I think pushing the limits and showing what's possible, that's part... I mean I know someone personally that is like building a new project every day. And he's actually the person that turned me on to MCP and was able to convince me that that was a valuable protocol in the beginning, because my take was you just have to API the crap out of everything.
And well, let's face it, APIs and LLMs, they were two things that were not, you know, necessarily made for each other. So it's just, you know, APIs connect machines, MCPs connect the intelligence to those machines. It's different levels of abstraction. APIs, it's machine to machine, structured data exchange, stateless. MCP is all about the AI to infrastructure. It's, you know, the capability based interactions and it's very stateful. Like the whole handshakey process thing is completely different because they solve two different problems.
So understanding where the technology fits and how are companies using it and then you can start to inject the value of these agents and MCPs and such. I said a lot there.
Cory:Yeah, no, that's great. I mean, I think that's one of the things that's going to be very different about our world, right?
I mean, some people say we're already at the dead Internet theory, right? The idea that the Internet's mostly bots. There's a ton of AI running around, but now they are interacting with our APIs and they're very much APIs that were not... like the idea of REST and GraphQL, et cetera, WSDL, whatever it is, did not take into account the contributors that we're going to have over the next year or so.
Host read ad:Ops teams, you're probably used to doing all the heavy lifting when it comes to infrastructure as code wrangling root modules, CI/CD scripts and Terraform, just to keep things moving along. What if your developers could just diagram what they want and you still got all the control and visibility you need?
That's exactly what Massdriver does. Ops teams upload your trusted infrastructure as code modules to our registry.Your developers, they don't have to touch Terraform, build root modules, or even copy a single line of CI/CD scripts. They just diagram their cloud infrastructure. Massdriver pulls the modules and deploys exactly what's on their canvas. The result?
It's still managed as code, but with complete audit trails, rollbacks, preview environments and cost controls. You'll see exactly who's using what, where and what resources they're producing, all without the chaos. Stop doing twice the work.
Start making Infrastructure as Code simpler with Massdriver. Learn more at Massdriver.cloud.
Cory:It's interesting. I've even seen a few sites where they've started to change their language. I actually stumbled across this site the other day where there was an option where you could check whether you were a human or a bot, and the content changed dramatically between those two tabs. Just thinking about this, it's like this isn't just how we generate code anymore, a lot of people are just going to ChatGPT or Claude and being like, "What tools should I consider?" They're not Googling it.
William:Yeah.
Cory:So it's like starting to see even SEO get muddled into this world because you have to influence the bots to recommend stuff to people, because that's the way people are discovering things now.
I feel like a lot of what was beautiful and exciting about the internet for all of us nerds over the past 20 years is... the face of the internet's changing a lot. And like, a lot of what we saw as open web is getting gardened up pretty quickly. And it's like, it's not just our APIs that have to change, it's a lot of the web.
William:Yeah. It's funny you say that, because I have, like, a ridiculous lab in my basement. It's just insane. I am committed because, like, one of the reasons... again, I fell in love with technology for various reasons and if I sit behind a prompt that's just doing all the work, for me, it kind of takes... It's like woodworking. I love woodworking. It's my get away from tech thing. I build a lot of stuff. I'm building this thing for my kid right now to hold his hockey medals and stuff. It's like I took all these old broken sticks. I'm using the epoxy resin, I have this spray and it looks...
Cory:Oh very cool.
William:It's so cool, but it's like the journey in putting all that together and making the cuts. And I have this like thing, I put myself through so much pain cause I come up with all my own stuff. I don't like to use existing designs, but that's part of the fun, that's what makes it engaging for me.
So that is kind of like how I am with the technology in a sense as well.
And the more that I've given over... you know, not that I've given a ton to AI, but I've had it do quite a few things and you lose that part of it. And I think there's trade offs and kind of consequences of that that we're going to see in the future that are not going to be recognizable at the moment.
Where younger generation coming in and building things is going to rely so much significantly on this technology that some of the foundational stuff... it's like my advice, I always get this advice about, "Oh, I'm getting into AI, what do I need to learn?" And I'm always like, "Learn Linux, go." I have a Linux handbook, you know, a few Linux books that I recommend. But just learn Linux, learn to get over on the CLI, learn how file systems work. Like I have this list and they're just like, "Huh, this isn't AI." Like, "Yeah, but this is like the one technology I think that's been prevalent under like every part of technology I've worked in, including AI." I'm in Linux now more than ever because of AI.
There's some fundamentals like if you're going to place yourself in software engineering and that's where you want to go and that's the love that you have for your career. Learn software development, learn a language, like go back and do the whole computer scientist thing. If it's network engineering, learn and understand TCP/IP, HTTP, like learn how these protocols work. Those are... I mean they've been there, they've been the bedrock of everything like BGP, TCP under the hood. You know, it's so important, it's so fundamental. Learn a little bit of DNS.
Like learn the things that actually built that vertical that you're trying to get in. And then the AI is a tool that's a force multiplier on top of that. But AI isn't just the "Hey, I'm a dumb person behind a terminal and I just have AI do all the things that flow out of my brain." That's not a world I would want to live in. Taking the people out of it, I think that's a mistake and I don't think it's going to age well.
Cory:Yeah, I think we're going to see a lot more... I think we're going to see... I don't know, man. I think it's going to look so weird. I think the Engineering Org is going to look strange in the future, but I don't see Operations going away. Like, these things do have to be troubleshooted.
But what you were saying a minute ago about like the creativity of it... I was actually speaking with my wife the other day about this. She's Early Childhood Development, much smarter than me, knows a lot about the brain. And so I'm like talking to her about all this stuff. I was like, "I am making features that customers want at a rate at which I was never able to do before, but I don't feel connected to my output."
Like a year ago, I would have loved my code. I would have thought about my code, you know. And it's just like, even the functionality, I see it now, I'm like, "Oh, that's great that that's there," but it doesn't feel like I made it, because I didn't make it. I thought about it and it just came into existence.
And then like kind of talking to her about like the whole process and like being exhausted at the end of the day, she's like, "You're literally just hitting a different part of your brain and you're hitting it all day now." Like there's a lot of different parts of your brain, but like the creativity part comes from... I think she said it's the default mode network is what it's called in the brain. And then there's like an executive function.
She's like, "You're essentially just like in the executive function of your brain all day and you don't have creativity, which is where you get this craft and this love for like your output. Because you don't have it anymore." And it's very weird.
But like taking that to the next level, it's interesting because you see other people in the Org that never had the ability to create and the way that they think about creation now is different, right? So seeing something like our sales guy be able to produce software, he couldn't do that before and now he's like, "This is great." He never learned to code, his craft is talking to a machine and it producing what he wants.
And so it's really interesting to see. Our generation of engineers are probably going to start to feel a lot less ownership of the code, but then you're seeing these other people that weren't software engineers feel a lot more ownership because like, "I didn't have to ask the developers to do this for me."
At the same time,our cloud just went from someone else's computer to literally everybody's computer. Because that sales rep at SDR is just running shit on their MacBook right now, right?
William:And producing more than ever, you know. Producing more quality work than ever.
It's funny, like... you hit on some points there... I built this CLI tool when MCP first came out because I got tired of... like I test and prototype stuff all the time and there wasn't a lot of good Dev tools and going and... like, I was at a point, because I was testing MCP servers, because they can be hosted in so many ways - you can host it on a container on your machine; it can be behind an endpoint for the platform or a product; it could be on your network, in another server or something on a different IP segment. You know, there's so many... and I was at the point where I was like version controlling JSON files for all these MCP hosts or clients on my MacBook side because there's just so many combinations. And if you open up Claude Desktop or one of these tools with the wrong file and everything, your server... you get like a thousand errors and everything's breaking. And I got so tired of that originally. So I built this CLI tool to manage the JSON config and everything.
And I ended up putting it up on the Internet. And then somebody that was using it was like, this would be really nice to add a UI. And I was like, "You're talking to the wrong person." Let me tell you, if there's one piece of code I'm not writing, it is frontend. That's not my cup of tea. And then after I started thinking about it, I'm like, "Wait a minute, I already have all the core stuff in there. I can, you know, I'm going to take a stab. I'm just going to experiment with trying to put a UI together, a simple lightweight UI that you pop up local host, whatever." And AI, like through a lot of compelling prompting and a lot of trial and error, put together a very good UI for this CLI tool. Like, really, really good.
That was my moment where I was like, "Okay." You know, I'm someone that's not a frontend UI person. I hate getting into UIs. It's not my cup of tea usually. I'm always like in CLI usually. And this was like a learning experience for me to say, "Hey, you know, if it did this for me, how much can it do for everybody else?" And you know, I was at the point where I was going to discount even trying to do that.
So going from, "Nah, like I'm staying away from that because I just don't do that," to actually bringing it in and then actually looking back at the code that was generated to try and understand it and stuff. Again, because I'm good with Go, but I'm not good the frontend. It was like a big, awesome learning experience for me.
And then the more that I started having AI look at the code base and I started introducing, like you were saying, new features... there was one feature I was working on that I couldn't get right. It was basically like the way that the tool would do like name spacing logic. So you'd have like multiple servers connected and it would... the feature basically prevents like identifier conflicts by prefixing the tool names with like a server's unique identifier. So it's like typically using kind of like a double underscore separator type thing. So if you have something called "Read_file" across multiple tools, you don't have conflicts. And there was a few things I couldn't get right. I plugged in AI and it was like two prompts away and I had that fixed.
I'm like, "Okay, I'm a believer in bringing this into my workflow." At that point, mainly because it saved me time. Like for you especially, Mr. CEO over there on the other end of this camera, I imagine your time is in high demand. Like you want to save as much of your time as you can so you can focus on the things that matter. You don't want to be doing busy work when you don't have to be doing busy work.
Cory:Yeah, I think I'm going to post a video about this in like a day or two... but like we've gotten to the point where... and we don't do this across all of our code bases, to be clear, but like where it makes sense... like we've moved to a completely Kanban based editing for almost all of our static sites, marketing site docs, et cetera. Like I don't even VS code anymore. We open an issue, we describe the problem, Claude opens a PR and fixes it, and then we comment. And pretty much the only time we do code is when we're putting in a guardrail. We're like, "Oh shit, we're gonna go set up this linter like to make sure it doesn't do this anymore."
It's funny, all of our work has just been always the Ops work. It's like, "How do we make sure that that crazy crap people want to throw in our really nice servers doesn't destroy our really nice servers?" And that's it.
And what's nice from the rest of the team's point of view is they get to focus on their intent, right? They don't really care about mobile first. They don't care about responsive. They simply say, "I want it to work this way."
We care about that stuff. And there's guardrails in place to make sure it generates that way. But like we're seeing like this complete change for a good portion of our work. But it makes sense there. Otherwise we're dragging down the frontend team who works on our main product to move around some copy. And it's just like, at the end of the day, that is an extremely critical thing for the business to do, but it has an extremely high cost.
At the end of the day, that engineering prowess in there doesn't matter. Like what matters at the end of the day is a potential customer sees it and goes, "Oh, this is the product that I need." Or a current customer sees it and goes,"Oh, this documentation was very helpful."
Like that's what makes them happy and if it's sitting around waiting two or three weeks for frontend to get around to it, for us to be able to say like, "Yeah, a human did it"... it's like, well sure, a human did it, but look at all these humans that didn't benefit in the meantime.
And so figuring out the right place I think is key.
That's also... I feel like for us Ops people that are still trying to figure out how to adopt this stuff, it's like if we can adopt it in these places... like you're talking about your Git workflows... stuff that's important, but it's tedious, you're looking up commands all the time and it's just like, "Eh, if I can push that out of my life, it allows me to spend a lot more time on the stuff, the shit we all have in our backlogs." I haven't met a single Ops person that didn't have an arm-length long backlog of stuff to do. Right?
William:Yeah.
Cory:And all of that stuff is stuff that stakeholders have been waiting on, wanting, needing, things to make stuff more safe. And it's like that's the work now. Like that is the job.
William:And that documentation play...funny that you mentioned that because that's exactly... I was talking to my boss about that the other day and we're working on doing something similar for a few of our things. And it's just such a smart approach, especially when it comes to docs.
Because if you already have an existing documentation... if you're using Doc, you know, source or whatever... you already have your docs, you can create a profile on your docs and then have the AI address user experience friction out of your docs. And then the AI is going to write that better than... I mean there's... I'm sure there's some humans that would do it better, but all of us don't. The folks that are actually maintaining and updating these things don't have the time to sit down and really think through this for days.
So AI is really good at doing that. It's really good at the writing and projecting the vibe, the experience, you know, of the consumer for your product specifically. And show you maybe where some of the friction is. It's so good, so why not leverage that.
Cory:Our docs were very thorough, but an absolute fucking mess. Like most of our community Slack is somebody being like, "How do I do this?" And then us sending them a link to the docs page because they just can't find it.
It's funny, we were talking to an AI company the other day that like helps... it's a very cool product... it's a little too expensive for us, but they make your docs like easier to find stuff. Like dynamic docs, like that kind of stuff. And I'm like, "Yeah, we can't afford that." And so I just went to Claude and I was like, "Is there a framework for like how to organize Docs well. " And it was like, "Yeah, there actually is." I'm like, "Can we just apply that to our docs? Like, don't change any of our words. Just, like, reorganize it."
We sent it to a couple of customers and they're like, "Your new doc site is absolutely amazing." And we're like, "It's all the same docs. It's literally just in different folders. All I did was reorganize it."
But it's one of those things where it's like, we see docs are missing, we go out, we write them, we toss them someplace. Thinking about, like, how to organize them based off of, like, where the customer is in their journey is hard, right? So we're just kind of like, page, page. It was just a phone book.
William:Yeah. And I think one last thing, that kind of... that piece of the conversation or the last few things we're talking about is... there's always been this... We get excited about the hype, and there's always, like, a reality check.
You know, I came from highly regulated industries like health care and financial services, Very regulated. I feel like you can't understand that until you work in that environment. And if you've been on the vendor side forever, it's just... take time to learn about the struggles that these practitioners have to go through to adopt and to maintain technology. It's much more complicated than you might think. And I see a lot of this attitude out there, "Well, you've just got to get in and get it done. You just got to get it done." That's not how it works for healthcare and government contracts and different things. It doesn't work that way. You can't do that.
There's a lot of rules and there's a lot of red tape, and you've got to hit every box, or you could get hit with a lawsuit that could take the company down. You know, you really have to pay attention to those things.
And so thinking about the right solution for the right problem and where the right technology fits... I went through this whole thing where I worked at a company and they... like, I did a talk on this ages ago called Microservices vs Monoliths, and the point being with the talk was it's kind of like it's a problem and a solution... Like, I would never go full on, you know, microservice Kubernetes architecture for some problem that I don't understand. Like, if we have a solution that's already working and it's like cloud storage spanning multiple regions and a few VMs and a scale set like, use that sucker until it doesn't solve your problem. But we had a new leader come in that said, "Hey, everything's going to be a microservice now." And we had like six different patterns that they wanted to hammer everything into. And then guess what we ended up with, Cory. We ended up with some distributed monolith.
And so I gave a talk on this, and I'll tell you what, I had some leaders reach out to me saying, "I wish you wouldn't have given that talk." And then I had like a tons of practitioners that both worked under me at the time and then other people from other companies that were actual builders that said, "Hey, this. Those are the right things to look at." And I mean, that just goes to show you, you don't say, "Hey, Kubernetes is the new, hottest rage. From the Org, you know, all the way down, we're just going to do in Kubernetes all the things." Makes no sense. It'll never make sense to have that mindset. You know, you have to think about the problem, the scale.
You've got to think about all these other things before you begin picking what you're using, before you begin integrating AI, before you start doing all these things.
Cory:Yeah. I think it's going to be really key.
And I feel like this is one of those places where we as practitioners, developers have to... I don't want to say push back on stakeholders, but we all know the CEO that doesn't know technology that's just like, "We're an AI company now." And it's just like, "Man, good luck with that."
But there's a lot of people that are kind of throwing that stuff out there right around now. And so being able to figure out how to get this stuff into places where it can benefit your team without being a detriment, right? And I think one of the tips I'd give people is, find that place where you know that you can 100% evaluate the output, but getting the output's going to be a pain in the ass. And it's just like... we have so much of that stuff laying around in our code bases. From making our test CI's run a little smoother, finding that thing that always breaks your build, finding those broken tests and fixing them.
There's so much little places that we can start to inject these tools that give us time back to start thinking about how do we use it more holistically across the Org. And so there's a lot of safe places to experiment.
I know we're coming up on time and I know that we've been on the ups and downs of AI here a lot. But I'm going to ask you two loaded questions here at the end. I would love to know, what are you looking forward to most in the research that you do and the evangelism that you do? What are you looking forward to most that's on your agenda of stuff to look into? And then second, what are you most fearful of?
William:What I'm looking forward to most... those are loaded questions.
Cory:I know, I know. This will be outdated in a week, I feel like.
William:Yeah, well, my first answer shouldn't be, I don't think, unless something major happens.
In the early days of MCP and a little prior to MCP, I went through this whole thing of trying to build the agent loop and doing all the things with APIs. And I learned the hard way that that just didn't... it wasn't the right solution to the problem. And I loved when MCP became mainstream. It's been growing, they've been innovating on it. It's foundationed up - Linux foundation, CNCF. You know, a lot of great work. And then you had a2a come along. So you have like the core, you know, exposing these tools and doing things. You have the protocol to kind of do that and then you have the agent to agent stuff.
What I'm looking forward to most, I think, is... those two feel like they're... like not completely solved problems, but they're the protocols that are winning out right now. And it makes a lot of sense. And I'm glad that they're part of the foundation that they're a part of, and that they have the backing from the companies that they have and such.
But I think discovery... so a2a has its own discovery mechanism, but it's very lean, very primitive. And I think that's by design... I mean I'd have to... heck, I probably would have to ask Google and all the maintainers if it's by design... but I don't feel like they're going to make a huge discovery mechanism as part of a2a probably. Like it's probably a different problem to solve. But what you're seeing is a proliferation of solving that discovery mechanism from the bottom up instead of like the top down with standards. And I feel like there's... I mean there's so many different, interesting and novel ways you can do it.
But it would be cool if there was a standards-based... kind of like an MCP or an a2a... you know, some sort of protocol standards based with the right backing and the right foundation that everybody's sort of building on. Instead of all these ad hoc, bottoms up solutions that are served with like a particular vendor. So I'm looking forward to that. I think something's got to happen there because it's going to begin becoming more of a problem.
And the thing that scares me and terrifies me, there's... there's a lot of that.
I talk to my co-host on The Cloud Gambit about this all the time. And I've gone into this thing where I like quit looking at Twitter and the news or stuff for like a week at a time. And she'll like send me links. She's like, "I know you're in your lock phase. You need to look at this." I'm like, "Thank you so much." Because I literally... like, I put them in a locked vault on my phone. I don't even have... I can't even see them because it just drives... like I get into the crazy mode.
So I feel like what scares me is common sense seems to be something that's waning these days. I feel like it needs to have a resurgence. I talked to someone the other day that was using OpenClawd... I don't even know what the name is now - Clawdbot, OpenClawd, whatever it is. And this person had their personal email and accounts plugged into this thing. And I just... and this is like a super smart, this is a top notch engineer, somebody that I've worked with in the past that's like a very, very intelligent, incredible engineer... and I'm just thinking like, "How did these two things... how did this happen?"
Like, I set up Clawdbot too, but I put it on like an intel nook that was on a separate network and created a few burner accounts just to mess around with it and see what it did. Completely isolated, you know, I don't even use those accounts anymore.
But like, you know, we've got to have that common sense as we evaluate and we look at these technologies. You know, privacy... still very important. And that scares me, that we're giving too much away.
Cory:Dude, like privacy is gone. We all have the First Amendment right to have absolutely no privacy. Congratulations, everyone.
I know that was a politically complex statement. I apologize for the hate that I'll get for it. But, like, we have.
I mean, I asked one of my friends something the other day. It was... I can't remember what it was, but it should be something you should easily be able to answer. And he literally looks down and ChatGPTs it. And I'm like, "(A), why is that still on your phone? And (B), are we still friends?" Like, I was just like...
William:Did he check ChatGPT?
Cory:Like, I can ask a robot.
William:Are you still friends with him?
Cory:Am I still friends?
The Clawdbot thing is wild to me. Like, I don't know if you saw this, but apparently you can Lightsail launch a Clawdbot now on AWS, which I'm just like, "That's... yeeks!" That one makes my palm sweaty just talking about it, actually.
But I woke up the other morning, different friend... not the friend that ChatGPTed... and I had an email from him, and it was very long. And as soon as I opened it up... I didn't even read it, I'm like, "Somebody's hacked this motherfucker. This is not the way he talks." And then I'm like reading it a little more and it's like, "Hey, check out my, I don't know, newsletter thing. Here's a coupon code. It's 250 bucks a month." And I'm just like, "Yo, he's legit been hacked."
So I text him, I'm like, "Yo, dude, somebody hacked your shit." He's like, "No, that's my Clawdbot. I have it working on like, building a personal brand." And I'm like, "Let me tell you, you fucking tanked it. Like out of the gate, dog. Like, I'm gonna have a Clawdbot go build me a personal brand. It's asking me for 250 bucks for... I know your shitty advice. Like, I already know it, dog. I don't need to pay you 250 bucks to get it. I get it all the time for free."
But it was just like... common sense was just gone. It's like, I want to build a personal brand, I'm going to have this bot harass everybody via email to get them to sign up to my substack for 250 bucks a month. I'm like, "You are..." I mean, I don't know, maybe Clawdbots are signing up for it. Maybe other Clawds are like, "This is a great newsletter, what a deal."
William:See, exactly. That's exactly what I... yeah, that fear that common sense is like a rarity or is becoming a rarity.
It's like what are we doing? So that's why... that's definitely a fear, for sure. I think about it... it's actually gone into how I raise my kids. You know, it's crazy.
Cory:Yeah. How are you...? Sorry, I know we're over time. If you've got to bounce, please.
William:I don't gotta bounce. I'm good.
Cory:You've got older kids, it sounds like. I've got a three year old and a six year old. Sorry, we just turned this into... we're just taking over the "Startup Dad" podcast all of a sudden.
Like we're pretty restrictive. My wife's like a childhood educator. We're pretty restrictive on like technology our kids are using. I mean they're three and six, so it's not like they're out there hacking the internet.
William:Yeah.
Cory:But like we keep devices away from them. We have so many friends that will just like hand their six year old an iPad.
How are you thinking about... I mean especially with like regards to common sense and your kids... like how are you thinking about their use of AI and like keeping... because I feel like this next generation man... Like we watched social media destroy an entire generation of kids, and like we're going to destroy the way they learn and think with this. Like how are you reasoning about that?
William:I feel like I've taken maybe too much of a hard stance on it and I'm trying to be balanced. But one thing I noticed with one of my... my oldest is ten, going to be eleven, and whenever we got in the habit of when he was younger, giving him basically a tablet with a few games and stuff, his behavior started to get bad. He wasn't listening and he was moody. And we took it away and that blew things up for about a week. But then after that he was back to normal. So when he was around six, and then with all of our subsequent three, we are pretty much no technology - you're working on school, academics, you're going outside.
But the trade off with that, and this is the hard part... I don't believe that you can take those things away and just leave children up to their own devices. Like you have to give them things to fill their time. My kid's pretty good with travel hockey, he plays hockey and he's pretty daggone good. We travel everywhere and that takes up a good chunk of time.
And what I found is like once I was able to connect them to some really interesting things outside of a video game, they started growing in like all these other ways that I didn't even... as a parent I didn't recognize. So I'm not saying what is right or what is wrong, but I'm just saying this is what worked for us. The behavioral issues have been like pretty much non-existent now.
You know, they are more interested in talking to people and not looking down at something. And it's just... their academics are much better and it's been really good. It's been life changing I think for all of us.
But it has been a lot of work for my wife and I. Because, again, you've got to find things and you have to help connect those dots to fill their time. But yeah, we're pretty hardliners of... I don't want to say no tech... It's funny because my kids don't even like want to watch movies or play video games anymore. Which is a different thing because sometimes I want... you know, like on road trips... that's our one place where we give them the tablets out, is on trips. Like if we have like a 10 hour drive, and there it's like in that car they don't have anything else to do. You won't... so you don't know what's happening, they're gone.
Cory:They're zombies. They're absolutely zombies.
If anybody hasn't like gone through the week of pain that William was just talking about, taking devices, like on the other end of it, it is crazy. Like when you hand it back to him again, it's just like, I can do this [waving his hand up and down in front of his own face] in front of my son's face and he like... I'm like, "Dude, do you need eye drops?" Like, he's just like, "This is amazing!Things are moving."
But I feel like that's one of the things like... moats around our businesses are just being removed by all of this. There's this whole thing the other day where people were talking about tests of the new moat because it tells how your system works. I don't know if I buy that, but like valid.
But thinking about these kids, if AI ends up being as magical as everybody says it is, it doesn't matter if they ever learn how to use it because the moat will be gone to using it, right? I feel like the most important thing... and again, I'm not telling people how to raise their kids either... AI is furthest out from replacing humans just being humans, so how do we have fun? How do we engage with other people?
And it's just like, we're trying to keep as much tech away from them as possible, but we're already seeing it leak into elementary school. It's like, "Hey, the kids in fourth grade are using tablets and AI to learn about stuff." And I'm like, "Can you just have a teacher with a book tell them that? Like, she's in the room."
William:When I say, like, we went to the extreme... when that happened with us, we actually yanked them out and put them in private school. Which is another expense. No school buses, all driving. It was tough, but it was for that. Like if I'm sending my kids to school, I don't want you to just give them a tablet and some applications or else I'll homeschool them and just do that at home.
Cory:Yeah.
William:Like, if you're not going to teach them, what's the point of them going to a school?
Cory:Yeah.
William:And I can only speak about what's worked for me. I mean, maybe the other stuff has worked for someone else, but I can only talk about how, you know, my kids have gone through this and what we found that works.
Cory:Yeah, okay.
Well, William, I'm glad you came on the show today. Sorry, everybody that just sat through me and Will's therapy session. But, like, I feel like this is all that LinkedIn's been talking about recently... like everybody just moving towards it and people just kind of rectifying with like their feelings about it. And, I don't know, it's fun to talk about it to other people.
Anybody else, if you're listening, got questions, thoughts? Always happy to hear them. Hit me up at cory@massdriver.cloud.
And Will, thanks so much for coming on the show today.
William:Absolutely. Thanks for having me.
