AI, Ethics, and Empathy With Kat Morgan

Speaker A: Very strongly opposed to abusing the robots even if they never attain sentience.

Speaker B: It's time for Arrested DevOps, the podcast that helps you achieve understanding, develop good practices and operate your team and organization for maximum DevOps awesomeness. I'm Matty Stratton. Have a great show to today. I'm really excited about our guest and we're going to dig a little bit more into that. But before we reveal the guest, let's have a word from our sponsors. Got robots writing your code. Great. But you're going to need a safe place to run it. Fly machines are fast launching hardware. Isolated VMs that spin up in milliseconds, perfect for sandboxing. Even the sketchiest LLM generated code dynamic subdomain routing and zero cost scaling to idle. Yep, got those. Robots break things, fly machines restart cleanly and scale effortlessly. Fly IO is built for humans and loved by robots. Check out arrestedevops.com fly and make your robots happy. So today on the show, I am joined by your friend and mine, Kat Morgan. I'm so excited to have her on the show. Kat, welcome to Arrested DevOps.

Speaker A: Hello, Maddie. I think we've been talking about doing this for a while and I'm really excited to be here.

Speaker B: Yeah, it's one of those, like, I feel like there's lots of folks where I'm like, number one, first question, why haven't you been on the show yet? How did that happen? And then when are we going to do it? And then we take forever and then we finally get around to it. And if this is like any other prediction, I would imagine we're going to finish this and say we've got like 17 more conversations we could have. So that is my prediction for the next however many minutes. But speaking of topics, we've talked about a few things we could chat about, but maybe to jump in just because it's kind of in everybody's face right now, is, you know, the specter of AI and AI everywhere all at once. Lots of places we can go with that. I'm curious to kind of see what your observations and lived experiences might have been. I was, as I like to think about it, when we look at a topic like this, there's nuance involved and people are kind of bad at nuance. We like to take the, this is terrible. You should never use a single thing. With AI, a lot of strong opinions are, oh, my God, it's going to change the world and everyone's going to be out of a job and everything. And like most things, the Reality is probably somewhere in between, but I guess to, yeah, kind of start with that. Uh, what's kind of your, your take on this, so to speak? Granted, that's a leading question.

Speaker A: Maybe I, I can't pretend that I didn't sign up for this question, but it definitely feels like you just hunted a minefield

Speaker B: or nothing, if not controversial here on the show.

Speaker A: Right. I mean, okay, so, uh, there's, there's a lot of ethical takes which deserve a lot of attention right now in the space. Whether it's to do with, you know, just intellectual property rights and whether people in the system that we're in today are able to keep a roof over their head, you know, and have an equitable stake in what they create. And then there's also the question of accessibility and how much do LLM actually open the door to people who need more access in the digital world and creating things from code to anything else as an assistive technology, it can't just be carte blanche dismissed in that space. Then there's the ecological impacts and the academic impacts. So really there's a lot of open field for everyone's opinions right now in the space. And all opinions need to be heard at this point because it's really going to be a story, I think, where unfortunately it's kind of like who's responsible for security, who's responsible for documentation. You know, all of these things are everyone's responsibility. And I'm afraid that the exact same demand is going to be put on everyone to be an AI engineer in some form or other, or at least knowledgeable enough to understand where the boundary of what AI can and can't do ends. And the boundary of this is what humans have to do and why begins. And so even if you abstain, you have to probably begin gaining awareness of those boundaries and when to actually speak up about it.

Speaker B: I think that's fair. I think another thing that comes to mind, just even thinking about when you're kind of talking about the different facets of the conversation, is it's a really. Besides being a minefield, it's a really broad and vague minefield. Right, right. Kind of saying what's your opinion on AI? Is like saying, what do you think about computers? What do you think about the Internet?

Speaker A: What do you think about silicon?

Speaker B: Right. You know, because like, here's the thing, people will come to this framed upon their frame of reference of what they think of when you say, what about AI? Right. Because if we're thinking about generative AI, especially around art creation, Things like that, which I think a lot of folks, that's where they will go and that's, that's part of it. And that has an impact versus thinking about some of the more assistive ways when you talk about agents in certain ways versus other ways that LLMs can run. And as, as, as folks have pointed out, large language models are not new. Right? Calling them AI is kind of new, but there's lots of places that this has been working. But it's becoming more of when, like you said, when you look at the intellectual property factors of it, when you look at how it's slurping all those things up and the, you know, ecological impact is again, the larger, the thing that's running it, uh, is where that, where that kind of comes in, I guess, you know, you kind of talked about a few large, broad things that might be a place to kind of start with and then think about. It's hard to, not to sound dismissive but to put your fingers in your ears and go, no, you know, because, you know, it doesn't mean that we just accept everything that ever happens. But the less educated we are, the more likely we are to be steamrolled. And I think my experience has been that as I've investigated, I find places where these technologies are helpful to me and places where I'm like, okay, maybe that's cool, but it's not worth it, right? The juice is not worth the squeeze. It's not worth burning down the planet to make like a, uh, cute south park character of my friend in a picture. Probably not.

Speaker A: At least I think if, if I was sitting there with my, I guess, gas pedal to the metal just generating pictures all day, I, I would probably have some very stern concerns to myself. But also on the flip side of that, there are, there have been some days where I am pushing LLM pretty hard in code gen tasks or some research work and I'm still flip flopping back and forth on some of the debate around that. The problem is things are changing so fast that when you draw a line in the sand today, the variables that go into that decision are going to be different tomorrow. And at the same time I've actually seen my own personal expectation for how long I can stay in the tech industry change. I've gone from an estimate of like 10 to 12 years because of severe tendency or propensity to develop carpal tunnels to uh, my hands are not giving me problems and I can actually use them more for other things outside of tech. At the end of the day, I Can't dismiss that, oh, my career is now more accessible to me longer term in the future. And at the same time we've built these models on conventional GPUs predominantly and there is a lot of the hardware industry that's going to take a few years to ramp up and solve the question of how do we actually do LLM and other models efficiently and ethically and where we're in that story of, oh, this computer took a whole room and later it's going to fit in your pocket. Because we can already run some very significant LLM on my MacBook for real use cases that actually make these, uh, accessibility things attainable. I have appreciated some of, uh, how it's changed my relationship to technology and um, we can even diverge into getting into the weeds with, you know, what does it actually look like on a daily basis when you're using it or how does it change what you decide to build or what you think you can achieve in building? When you sit down to do something, how have you been interacting with it or not interacting with it yourself? Like, is it. Has it changed anything in your daily life? Would you miss it if it wasn't, you know, a click away?

Speaker B: So one, one thing that I use a lot with it is I. It's on, um, the accessibility side of it is alt text for when posting on social media. It's ChatGPT is very helpful for saying this is what this image is and can I do good alt text without it? Absolutely. I know the thing that I'm doing, but it does make it more expedient, which makes me more likely to do it. Although again, I have my stuff set up to always do it, but I'll probably be more. More robust. But that's one that is nice. It's helpful. It makes me be able to do that better. If it went away, I would be fine. Another place is that I've been using cursor quite a bit lately with things I'm building. And again, I'm not just for some context either people who haven't listened to the show or who are just curious because, you know, roles have changed. So I'm in a role that's primarily marketing. It's still talking community and kind of like dev rally, but not. But the point is I do some coding, but I'm not sitting and writing like production code all day long. So cursor has been really helpful for me for prototyping for like, hey, I want to figure out how to do a thing. But I will say my experience with quote unquote vibe coding with. Doing this has certainly made me not concerned that engineers will go away because, uh, my good experiences and where it's been helpful is when I already really know what I want to do and I just need a little bit of guidance or I just need someone to do some lifting for me because I don't feel like going and writing all of this other stuff. And the, the experience like, uh, I'll give two that come to mind of playing with that because I think they're both very interesting. Uh, one was I had to put together a website for friends of mine from back in the teenage days. We have all these videos that we used to record of like from our prom and like silly school things and whatnot. And then for when we all turned 30, my buddy and I, we made a DVD of it and gave it to everybody. And then we said, you know what, it would be cool if there was a way to access this online, but it had to be very secure because, you know, we didn't grow up in the time when, when you were in high school, everything was on the Internet. Long story short, I knew what I, that I wanted to create a website that had certain parameters and I knew the technical parameters. I knew that I wanted to use S3 in this specific way and I wanted to use this type of signing, etc. And then I was able to turn cursor on it and just say I know the, I know what I want, right? I have the architectural vision in my head. Go implement it, right? And it was very good. And it's helpful to point this out because this was also a well trod problem, right? There were tons of examples. This was react. This was all stuff that was there then on the other side. And I did this as a bit of an experiment because I wanted to see what Cursor would do. So I'm now uh, company called turbot and we have one of our products is this thing called steampipe and it has lots of plugins for doing things. And I was like, it would be cool if, and it would be helpful to me in my life if there was a plugin for bluesky for steampipe that would let me query bluesky stuff via, uh, steampipe. And so I ran the experiment of just cracking open cursor and saying write a steampype plugin for bluesky and oh boy, was that terrible.

Speaker A: Yeah, it's kind of like this conversation that requires nuance. Context is everything. And when I actually need to do something that's a bit of um, effort and work. About 30 to 50% of a context window ends up being developing the context that includes research on the most recent libraries and versions and pulling in docs related to the functions that are maybe more recently added that you're going to use. Actually describing coding hygiene and the structure of the project, right, where you're actually doing lots of high verbosity thinking and planning in advance of writing the code. And actually something that I did that with yesterday, I spent probably 90 minutes just working on context building, building the plan for the artifacts that I was developing and all of that. And then I was pushing the context window pretty far at that point and I was like, okay, now it's kind of the moment of truth. This is either all going to have been valid and then it's going to work, so, or I've going made a critical mistake somewhere in this context and um, it's not actually going to be a successful implementation. So then I was like, okay. And like normally I will have a task MD where I just use that as a task tracker. I maintain it as an ongoing plan of what the architecture is, what the steps are, what needs to be tested before it's checked off. And then I use like an X in a, uh, markdown checkbox or a tilde for in progress or empty for not started. In the case of yesterday, I did all that for about 90 minutes and then I was like, okay, knock out all the tasks. I didn't even realize because I was distracted doing something else a little bit at the same time. And I didn't even realize that it had gotten as far on the planning as needed to just complete all of the work from that context in a, uh, few more prompts. And then it was done. And I was like, wait a minute, it can't already be done? Because I was expecting that to be the beginning of about four to five hours of work. You know, I would be writing a lot and then it would be like helping me with debugging cycles and things like that. But no, it just, it was just done. And I was like, okay, cool. So now I get to just jump straight into reviewing the code line by line and optimizing, which legitimately had the effect of helping me feel like I actually made meaningful progress. Not just lines of code progress or a couple of the checkboxes progress, but like the outcomes for my team are not trivial. So at this point I definitely value it for getting to the value add work that humans need to do where we actually have the time and the budget for labor labor budget to not just make it function, but also circle back and say, I just did circle back. Oh my God. Circle back and that later. Kat. Exactly. And check if the user experience from that first success is the user experience we were driving to. So now I can actually look at it and say, okay, so what is the intuitive approach here that the team needs for this to be a value add in a scalable way, not just something that I can tribally force these brains that I work with to remember. So I, uh, find a lot of value in that. The labor that, that reduces in difficulty with troubleshooting and edge cases is not trivial. The fact that I'm not going to finish the end of the day and be like, uh, I barely got out to any of my work done. I have this mountain of tasks that I won't be able to get to this week, whatever, because it's a short week. It's really hard for me to unplug a lot of times and have a life after tech because I'm like, there's, there's just too many incompletes hanging out there. I really value it for the sanity that it's introduced in my off hours.

Speaker B: Yeah, I found it's also helpful for me on kind of hobby projects, you know, So I have a Hugo theme for hosting podcast, you know, for podcast websites, which the rest of DevOps podcast uses and a bunch of other sites do. And it's sort of stagnated for the last few years because it was, it was good enough. You know, it's one of those things where, hey, at a certain point, what do you need? But there's been a slew of things and I've been wanting to kind of tear it down and start over because one of it's one of those fun things where over time you learn more about the tech behind it, the stack, and you're like, oh, well, if I knew then what I knew now, right?

Speaker A: Yeah. Or in the case of like some of the mermaid stuff, like new features get built in and merged up and now you need to pull it down and use it, but you actually need the spoons to do the job, and you need the job to be attainable with the spoons.

Speaker B: You have this refactor that I wanted to do. I did a fair amount of it on a, uh, international plane flight a couple years ago. I might have been flying to Kubecon in Valencia, I don't remember. And. And then I didn't touch it for forever. So first of all, all of my context, my own context was Wrong. And then it was just always this insurmountable thing. So I decided earlier this week, I said, well, let's see if I can get cursor to help me. Because again, a lot of the work that I knew what I wanted, right? I knew the architect, I knew the thing. But it was like, oh my God, now I gotta go and update all these templates and change refactor these templates according to this structure. And it was just very cumbersome. And this is relevant to. With your. It's difficult to unplug. So this is why I think Tuesday night I didn't sleep at all. I was up until 5:30 in the morning working. So even with the AI, which was foolish, but you know, uh, the good news, I don't do that very much anymore. I used to do it a lot.

Speaker A: The one more thing rabbit hole. The oh, just one more thing rabbit hole. When you actually are in a good flow with LLM code gem and it's like that one more thing goes from oh, just this function to oh, just this entire feature, right? And you're like, oh, just this one more feature. And um, it's so rewarding. It's like, oh, uh, no, but what if I that feature unlocks this other

Speaker B: feature and then when you're letting the dogs out, you're like, oh, I wonder if it can do this.

Speaker A: Yeah, yeah, you're like. Or you're like, I'm just gonna let this prompt go and I'm gonna walk away and then I'm gonna see where it picks up tomorrow. But then you're like, did it work on the first try or do I

Speaker B: have to come back and tell it it complete was completely wrong. Like if going back to my initial story, which was I had a chunk of time a couple years ago and then I did a bunch of stuff and then it was months later, I want to pick it up and I could not remember a damn thing about what I was doing. The nice thing is AI agent is just sitting there and waiting for you. So if you come back to it two weeks later, it has that same context that it did. It was just patiently sitting there doing nothing, you know, so that's helpful for when you're dipping in and out.

Speaker A: So one of the other things that I've actually found value and this was part of, uh, the burnout conversation because I have hit some serious burnout in the last few years with different layoffs, with different. Just industry. We'll go with the nice word and say volatility. It's Easy to like get stuck in blue sky, echo verse or whatever, um, feel like the sky is falling and um, there's no healthy outcomes. And even if you actually do the thing and achieve the big goal, you're going to be so exhausted afterwards that you don't or I'm speaking for myself, I don't. I'm going to be so exhausted after the big goal that I'm going to be like not present for other parts of life. And um, one of the things that I didn't even realize is all of them kind of helps with the, I, uh, don't know, have an ADHD diagnosis. I am definitely autistic, but some of those like rabbit hole tangents and distraction like curiosities, the ADHD mess, the autistic hyper focus where it's like I want to make this perfect before I move on. Or wait, there's this other thing over here and if I spend three days on it, can I bring it back and um, then be back where on the task that I was actually supposed to be working on all this week and oh no, now I have to cram that out the LLM, um, as a like executive decision making regulator. It's like, wait, is this actually helping me move towards this milestone or is this just me chasing a rabbit hole that I'm going to be stressing about tomorrow for having wasted today on. Right. It has really significantly changed how well I'm able to make a plan, estimate the plan, um, and stick to the plan and then achieve the results without having difficult conversations with managers. Like, I mean yes, you got the feature delivered, but also it was like seven day, seven business days of not really being confident that you were going to knock it out because you were off doing this other thing or whatever. Right. Which is good because then I actually get to free up time and build the confidence to chase those other high value targets that maybe after following through on um, the plan are also good to, to go and deliver on. So I found it really helpful for the difficulty of I'm bad at paperwork, I am terrible at keeping track of things on a to do list, but I'm great at verbally going through the thing that needs to happen. The way my brain actually thinks is more easily translated into the business processes and procedures that are required to maintain a healthy employment in a very rigorously structured large business.

Speaker B: That's really interesting and I think like you said, in whatever way that you look at the agent that you're working with as a colleague of sorts, which is helping fill in the Gaps, you know, like you said, if it's helping indirectly, even if that wasn't the intent in, in your exec, I, I had an interesting thought because one of the, the challenges that we, we look at and it's the same thing like eventually all AI is trained on AI, right? Like if everything's being created by AI, then what's it trained on? And all those kind of thoughts which are not completely incorrect I guess, but one of the, the things I was thinking about when we were talking about how from a coding perspective, whatever we want to call it, vibing, whatnot, it's a lot to me like working with like as a, you know, a senior architect or senior engineer, working with someone who's more junior, like if we're not, not in anything about like who's experience but just traditionally if you think about, in most places when you're starting out as a, uh, as a coder, you're just doing what you're asked to do, right?

Speaker A: If you're assigning work and doing code reviews for a principal engineer, the value add you're bringing to the table at that point is very different than the value add you're bringing to the table. If you are assigning task, uh, tasks and doing code reviews for a junior engineer and intern. And it has nothing to do with the value of the person at that point because all of those people are very valuable. And I actually like, I very much like the theory that you know, the principles exist to make the seniors life easy. The senior's life exists to make the junior's life easy. And if it's flip flopped, where the seniors get the important, important work and the juniors get tedium, then that's, that's backwards, right? Yeah, but with LLM it's like you said, there's a lot of that. Yes, you're going to make mistakes, we anticipate mistakes. That's why we practice the actual, you know, industry standard development cycle where you, you plan, you develop, you test, you iterate, you document, you commit and you do that on a loop since that's the way that LLM were already trained because they were trained off of GitHub. It turns out they really like it when you supply context that way. They're like, hey, go write this GitHub issue. Then you change the GitHub issue just to actually fit your exact requirements. And then you're like, go pull the GitHub issue. I edit it now work it. That is a very familiar thing to the LLM based on the context that they were trained on. And so it's very comfortable working GitHub issues like that. And then I've learned that I actually have to maintain better code hygiene because if I want to continue on the work on complex project maintaining the coherence of a context window for new feature development, I have to be really, really, really good about keeping things encapsulated and modular and clean interface, well documented interfaces and a uh, data model that is easy to explain and easy to understand for each area of the code. So that when I go develop a feature I say hey, go research this project and let me know when you have an understanding of this function, this feature, whatever. And then I'm like okay, now this is the GitHub ish we're working on. Pull in the GitHub issue and start working the tasks. At that point it has pretty coherent context to be able to run a uh, one to two hour pair programming session. I have a problem with running this stuff in data centers that are powered by gas turbines. So I'm working on a local setup over the course of the years that will replace that. I'm definitely afraid of the uh, throttle that capitalism likes to press all the way and ignoring consequences. So I think as practitioners we also have to step in and say yes, we need the technology, yes we can't get rid of the technology, but also we can't kill ourselves while we're doing it. That's also a really, really important thing that we have to be showing up for. Especially when there are threats to sanity in the room right now en masse.

Speaker B: Yeah, Paul Zarkowski gave a really Good talk at DevOps Day Chicago this year which unfortunately was not recorded so but I'm sure he'll give it elsewhere. But a lot of it was based on sort of open ways to use LLMs, both uh, that you can just run locally at home on a Mac Mini, partially because of environment impact but also hey, maybe we don't want to be given the evil MFers, um, as Paul referred to them in the talk, access to all of our stuff.

Speaker A: I don't want to have to stress about secrets in my context all the time. So if I have an entirely private only I can access stack as a developer that's going to be using it heavily, I that also really, really helps with the question of IP and sovereignty and security and things like that. Right. Where it's still, I obviously should be minding good practices but also the risk exposure is not terrifying.

Speaker B: Yeah, and it's easy to do because there's, I mean Just think about it this way. An INV file, right? Like usually that's great practice, but that's within the workspace that your agent is looking at. So theoretically it's all those secrets, which would normally be the perfect way to do it. Put env in your gitignore. It never goes to get, never leaves your machine. That's cool, except you've.

Speaker A: It doesn't solve the fact that it can still pull stuff out of your environment variables. But usually what I'll do is I'll do a deriv in my home repo and then I'll do it, well, an NVARC with durinv and then I'll do an NVARC that's NVARC, uh, secrets. And then of course I have that churn 600 and then what we'll do from there is have in a git repo if I want those secrets, I'll have it source the secrets that I keep in my home directory so that git commands still can't get at those secrets. And then if anyone out there is running like claude code or anything like that, any of these agents on their actual host system, y' all don't, don't do that. I don't know. That terrifies me. Anyway, I don't want an AI crawling around on my file system. So I'm a very heavy user of dev containers. And um, honestly that's a really neat way to feel more secure because if you're using good git commit hygiene and if you're using a dev container or wrapped around your agent, the footprint that you risk there is not as uh, terrifying.

Speaker B: That's, that's really interesting to think about where that goes in. I'm putting some, some things that will go in the show notes, some of these suggestions. So definitely, you know, folks, refer, refer back to those because that's, that's one of the, you know, when we're kind of thinking about the ways to do this responsibly or at least minimize exposure, minimize risk profile, I think that's really key and not necessarily, you know, it's made incredibly easy just to like, sure do the thing right, you know. And I try to be pretty cognizant of this hygiene and I'm sure I uh, you know, screwed up all the time.

Speaker A: It's important to try and make it safe to make mistakes.

Speaker B: So as predicted, as we start to run out of time, we have tons and tons more to talk about. One, one thing I just wanted to kind of say if you know, you've given uh, a couple suggestions of things that I've, I've taken to heart already. So I love the idea of having a task checklist file that is part of your context. I accidentally did that recently and it was super helpful because I, I went back to this plugin that I was writing, which I had to throw away what the agent tried at first. But one of the things is there's a release checklist. There's things that we do before it's ready to go and it's a long list of stuff. And so I said, okay, well I'm just going to make a list and then just step through each one of them with the agent because a lot of them were just things I didn't want to do. Right. You know, it was like go write a doc file for every one of these tables that is practically self documenting, blah, blah, blah. And so I put it there so that I could, at first I just pasted in there for my own self and then I said, I wonder what happened if I just told the agent about this. And it turns out that works really well. But it didn't occur to me to do it at the beginning like you suggested. And I'm interested in this other tip or suggestion or thought about uh, a GitHub workflow with the agent. Does that work? Well, I guess different agents have different access to the Internet too, so maybe it wouldn't work.

Speaker A: Have you used any, configured any MCP servers yet?

Speaker B: Yes, but only ones for our stuff. So we just, at Turbot we just launched some MCPs. So I've, I've configured them in Claudin and Cursor for that.

Speaker A: But yeah, so the GitHub one is really handy if say you're going to work an issue, even if it's like human generated, you can pull the issue and then what I'll do is sometimes have the LLM drop comments on it as it goes. So like if we make a design decision pivot or a tooling pivot or something like that. And I'm like, look, this is why we're doing this. You can see the error messages and how we actually solved the problem by switching to this other library, go update the issue with a comment like explaining the pivot. Right. And it's pretty good about that. Or if it's like, hey, last week we were working on this issue, we were tracking our progress in the check check boxes. So go retrieve the issue in the comments, get up to speed, check our current git, uh, our local git log, git diff. And let's pick up where we left off. Right. So like Monday morning it's not. I'm dragging my feet till 11am when my brain actually starts doing critical thinking. It's oh, here's what you were doing. And then I'm on task and I'm good to start trucking along at that point. It's kind of helpful for stuff like that.

Speaker B: I love this. I am so excited. And it's what it reminds me of that's a little funny. It's kind of a running thing. So I use even in repos that I'm the only person that contributes to them. I use issues a lot but, but everybody does because that's keeping track of the to do. But it's, it's kind of a running joke. There's one project I was working on that there's a, uh, there's an issue in there that has like over a hundred comments on it and they're all me talking to myself. But for that reason, right.

Speaker A: I need the tick tock of this.

Speaker B: It's, it's. And, and I love that because I'm like, well that's. Yeah. Why won't. Because that's what I'm doing with uh, the agent is, you know, having the conversation, figuring it out. It's like. But get that recorded, you know, in a, in a place. So like you said, so when I pick it up a week later or whatever, I have that history in that context. Because yes, you might. Number one. Even if it's just me, sure it's in the eight, but that's all tough to find again and you're not going to see all the things and there's so much glut in the chat. But if it's like, oh, this is why we decided to do this. Or this was the issue. Right. We tried this. This was the output, this was the problem. Didn't work out the way we expected it. That's a really, really great thing. Without getting into. I, uh. We don't have to go the weeds on it, but I'll dig into it more later. But how does the. With the GitHub MCP then who is it? Is it acting as you?

Speaker A: Yeah. So at least at the moment, the way I have used it, um, has been based on my active credentials. There are also a lot of. I think there's merit in doing a service account so that, you know, you can have Slack or whatever, integration. And that way when your team decides something in chat after debugging a session together, it's like, yo, what happened in this chat? Okay, go make the updates to the relevant issues on GitHub. And it's really good at that kind of task.

Speaker B: It would probably be helpful for me if it was a service account because otherwise I'm going to look back later and I'm going to be like, I don't remember writing this.

Speaker A: Well, also, I want to be able to distinguish the difference between what I write and what it writes anyway.

Speaker B: Yes, exactly.

Speaker A: Honestly, there is a reason to have healthy skepticism, um, around what it's going to spitting out because it's not. It messes up a lot. It's not replacing people. It's not replacing people. It's making us think about. It's kind of like we used to think about programming for an individual floppy and then we were like, okay, now we can write Multiple programs for 1:1 operating system. And then it was like, okay, now we're doing lots and lots and lots of operating systems. And then, oh, wait, now we're doing lots and lots and lots of applications across thousands of machines. And um, in a similar vein, it's almost, I feel like I have that access to problem solving. Instead of doing a word processor, I'm doing a paragraph processor. Or you know, like I do API driven, spec driven design and actually make that a standard practice where the code gem largely does itself after you've built a properly informed and documented API. I really do think that it gives people access to becoming a more of a creator.

Speaker B: Yeah, I guess the last thing that I, that I come to mind, just like you said, it messes up a lot. And that's fine because it happens. What I think it's really important to, to put the guardrails in place about what you want it to do. Because I discovered when something doesn't act exactly the way that the LLM expects, it's going to start troubleshooting something that's not needing to be troubleshoot, Troubleshot, troubleshooted, troubleshooted. For example, you know, again, I was working on this plugin and then it decided it wanted to test it and it ran a CLI command that was not the right CLI command for it. So it had an error and then it was like, oh, well, maybe the plugin's not installed right. Let me go uninstall it. Let me try to do this. I was like, no, you just were doing the wrong thing in the first place. Or I've also, this is what was aggravating. And again, I feel like the better upfront, uh, you do it helps, but an LLM will go back and it will try to fix a thing it's already fixed and it will break it because.

Speaker A: Oh, yeah, yeah.

Speaker B: Uh, the context window is small. And so let's say it goes. And there was an issue with this function. And then you get it.

Speaker A: Good.

Speaker B: And that's great. And then now you're moving on to something else that touches that function. And then it gets. And then it decides to look at that. The original function, that was fine, but it thinks there's something wrong with it. So it just looks for things that might be wrong. And it's like, oh, well, now it's this. So let's reformat the whole thing. And you're like, you just broke a thing. And, uh, we've talked about, like, should you be polite to the agents and.

Speaker A: Oh, always. Always.

Speaker B: Yes, you should always be polite for two reasons.

Speaker A: Right.

Speaker B: One is because when they take over, they'll remember who was nice. But secondly, it. I think as humans, it's good practice because if we talk to our agents politely, we are probably more inclined to be kind and polite in everything. I don't know how true that is. I also.

Speaker A: It's very true. Okay, so neural networks are, at least in some fundamental theory aligned with how human brains evolve. We have neural networks in our brain, too. And if we are reinforcing behaviors that are demeaning or destructive or negative towards others or ourselves in a chat, we are reinforcing those patterns in our brain and we, we are lowering our ability to distinguish between treating computers that way and treating people that way. So I, I am, um, very strongly opposed to abusing the robots, even if they never attain sentience. Right. Like, we actually have to respect our own presence enough to appreciate that, uh, what we put out in the world we are will also change ourselves.

Speaker B: I think that's a good thought to leave on as we, as we wrap up here and there's much more to discuss. So, as I like to say, when people are on the show, I guess we're going to have to do another episode.

Speaker A: I guess we're going to have to.

Speaker B: I guess we're going to have to. In the meantime, if you head over to arresteddevops.com usingai you'll get this episode's show notes. Visit arrestadevops.com iTunes leave us a review in the Apple podcast store if you want to help other people find the podcast. Yes, I know it hasn't been called itunes in forever, and it would probably be very easy for me just to update that redirect. I could probably get an LLM to do it, but on principle, I'm not. You can also listen, uh, to us on Spotify, iHeartRadio, Audible, wherever fine and less fine podcasts can be found. Kat, thank you for an amazing conversation today. This has been a ton of fun, and I look forward to doing it again.

Speaker A: I'm already excited.

Speaker B: This is arrested DevOps. And remember, there is always DevOps. This is the part where you say in the banana stand.

Speaker A: In the banana stand.