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.
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.
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.
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.
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.
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.
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?
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.
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?
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.
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.
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.
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."
