Safe Production Changes With Agents  🔗 **Source:** [Safe Production Changes With Agents](https://www.youtube.com/watch?v=6bHxMYeatHs) Hello, hello, hello everyone and a huge thank you to joining us today for today's panel. This is a lead dev online panel discussion created in partnership with octopus deploy, one of the cutest of the mascot animals. This discussion will last about roughly 45 minutes after which both myself and the panelists will head over to the lead dev Slack to answer some of your questions in the panel Q&A channel. For those of us joining us live, I'm about to drop a link in the chat. The Slack isn't just for these live events. It's just a really great community of engineering leaders and staff engineers supporting and learning from each other. And at the speed of AI, there's more to learn about, right? Constantly. And as speaking as a journalist, we all need to share our lessons learned better. So we may have time to answer a couple of questions live. So please do submit those through the Q&A feature on Zoom and I'll sprinkle them throughout if they are topical. So thank you so much. So I'm not going to lie, part of what we're talking about is things you've heard before. After all, certainly the people on this call have been banging on about engineering best practices for over a decade now. But now there's just very much more code to consider being written and released by nonhumans. Is that an acceptable term for AI? We'll see what they say. So today we are going to talk about how to do it safely. Not all easy solutions, but if you don't do them, your business and your end users will surely lose. Plus, now's a good time to implement all those continuous delivery platform engineering testing, uh, behavior-driven design, and user centric best practices that you've been putting off because you don't have the budget for them. But now, if you say it enables AI, you may get the budget. So, let's just get started with some introduction. That's my new theory right now. Just say it's for AI and you'll probably get the budget, especially people's jobs. My name is Jennifer Higgins and I'm your favorite freelance tech journalist including with lead dev. Today I'll be joined by Heidi Jean and Dave ready to share their experiences and insights. And remember we all have a lot of experience on the call but everyone's kind of a novice with AI agents. We're still newbies or noobs as maybe the kids don't say anymore. So, can you please each introduce yourself and briefly say what do you think the title question, what safe production changes with AI agents even means? Dave, I'll let you go first for this one. >> Okay. Hi, my name is Dave Farley. I'm a consulting software engineer. Um, I say that because it's an internal joke because I like Sherlock Holmes and he was a consulting detective. Um, I'm like everybody else. I'm fascinated and interested in what the future of our work looks like. I think it's changing profoundly. And maybe because I'm a grumpy old man or maybe because I've just seen a bunch of things. I think that what we are seeing is a deeply profound changing that's saying some of the fundamentals are still fundamentally important and there are important ideas that we've learned about how to do a good job of software development safely that are even more important now than they were before. >> Fair enough. Yeah. And will they still be ignored? We'll see. Jean, I'll let you go next. Hi, I'm Jean Dipli. Uh, I'm an engineering leader. Um, and I've been in industry for over 20 years. Not as much as Dave, but uh, I've got a little bit of gray developing already. Um, I have spent my whole career in startups uh, across a variety of industries and uh, currently work at Kilo where we're building a platform for agentic engineering. Um, and specifically over the last 18 months, I've been focused on on helping engineering teams adapt to agentic engineering practices. Um, in terms of what safe production changes with AI agents uh look like and what I think about that, I I think you know your chance of success to use AI agents to safely take changes in production is wholly dependent on how safe it was for humans before you introduced agents. Um you know I think you know there's this common saying of AI amplifies everything in your software development life cycle and if the cracks were there before uh the agents they will continue to be there with them. Um so we'll see how how this evolves. >> Absolutely cracks to chasms right now. Heidi please introduce yourself. >> Hi I'm Heidi Waterhouse. I work at Octopus Deploy and I have been going on for years about how deployment and release are not the same thing. For the love of God, please learn to disambiguate those. Uh and I think one of the interesting things is that we really need to define safe. Does that mean there are never any mistakes or mistakes are small and uh tightly scoped and easy to fix? Because I think aiming for perfection while a good goal is um just going to make you crazy. Whereas aiming for affecting the fewest people possible with the smallest possible mistakes is is the best failure mode. >> Fair enough. And failure modes are abound. just nobody's talking about everyone's talking about their percentage increase of productivity that is warranting so much change that's not happening for the end user. So yeah, last year's DORA report echoed what we kind of all knew in a way but really gave solid feedback and statistics that AI is an amplifier of everything, the good and the bad, the ugly. If you were already what they've what Dora calls a high performing team, AI enables speed safely at scale. If you were less than that, we'll call it uh you're not a failure, you're just learning. It's just more code shoved into the pre-existing bottleneck. So I want to start off with popcorning which pop just everybody call out uh what the many things that you believe create stable systems are and that are even more important in the age and speed of AI and agentic AI. Just jump right in. What do we got? >> Working in small steps >> scoping. Yeah. Yeah. >> Easy roll backs. >> Easy roll backs. specifying what we want and verifying that we get it. >> Incremental deployments, >> keeping things um Yeah. No, that's the same as Dave. Never mind. >> Small. Keep it Keep it small. >> Yeah. >> Good observability. >> Yeah. It's across the board. All of the we're starting to iterate and repeat ourselves because across the board what we need to do is that we need to gather feedback quickly, respond to the feedback and adapt. And it's that do that and repeat and keep doing that in small steps with AI and guide it. Steer it >> and don't let it have too many permissions. All of the hilarious uh fail stories that we've seen about AI are about overcoped permissions. Mhm. >> It's all about having confidence in the process of taking code into production. >> Yeah. >> If your processes are set up to give you that confidence, your AI will will hopefully be okay as well. But if you haven't had that confidence before, if you push the button or it runs automatically and you hope for the best, um you're likely going to endure some chaos. >> I I think there's an intriguing idea. I'm sorry. I think there's an intriguing idea in in relation to what we've already talked about about it employing the good or the bad is that what that does is it makes your choices even more important because you're going to dig a hole and create a big mess really fast if your practices aren't good. And you're going to be flying. you're going to be creating good stuff really fast if your practices are good and that's increasing the differentiation. There was enough slack in the system in the past where without being too rude about too many organizations average kind of barely adequate performance was survivable. I don't think that's going to last very long. I don't think that average or you know barely adequate performance is is going to be a disaster. I think >> I think that sorry go ahead Sean. >> Okay. No thanks. Um I'll quickly add I think also that the fact that uh humans used to be a bottleneck and that actually allowed us the opportunity to catch up with with things that could go wrong. You know the process was slow and so you know there was an opportunity to spot things that went wrong. But as AI takes over some of these tasks and automates it, you know, the acceleration, you know, is there and it doesn't give us the opportunity to in interrupt it, you know, through human observation and so the systems are even more important. >> Yeah, absolutely. There's >> Yeah, I was I was going to say that one of the things that I think we've learned is that, you know, we used to be able to do heroic human intervention. There used to be like that one person who could save a bad deploy and hit the stop button. And we robots are not going to pull pull the end on cord. They do not have the the capability to say like stop. This is not okay. >> Okay. Is that a problem? Do we need human bottlenecks because code is going too fast? Now >> I I don't think that human bottlenecks are fast are fast enough for that to work. >> So I think we have to automate those things. We've got to I think this is a fundamental change. To be honest, if typing code was your bottleneck in the past, you were doing it wrong anyway because that's not the hard part. The hard part is understanding the problem and verifying that you that your solution fits the problem and all those kinds of things is much harder than just the typing just the translation into code. It means if that was if that was if that was the slow bit you weren't very good at writing code is in my view. So, so, so that so we've optimized to speed up the bit that wasn't really the problem and then we've left all the bits that were really the problem and they're still there and they can't keep up with the writing of the code now. So, I spoke to somebody not very long ago who reckoned that he was producing on his own 12,000 lines of code a day with aic assistance. Who on earth can honestly review 12,000 lines of code a day. I can't not not and understand it. >> Did his company We've always said I I think lines of code is the only interesting metric is to measure complexity in your company. We've know lines of code is a bad metric. >> Yeah. >> Do we want individual teammates writing 12,000 lines of code or overseeing AI overseeing AI doing it? >> No. But all of the company, not all of the companies, I'm I I apologize because Jean is representing one of some of these companies that are that are talking about agentic programming tools are certainly pushing that message that that you know we this is valuable. Generating code fast, developing software fast is what matters. How fast it writes the code is secondary it seems to me. And so so I I want to be able to build software faster. I think that's great and I can using aentic assistance when I'm doing the right things, but if I'm sloppy, it creates crap really fast. >> Yeah, I want to talk to our respectfully baby startup in the room. Uh, Jean, what percentage of your startup's code is written by AI? >> Would has it that it's confidently I would say probably 99%. Um and and that's not because we we're reckless and stuff, but we have um we're very early on, you know, try to adapt to what does the new build look like? Um we're still figuring it out internally. We're we're just as confused as everybody else out there. We in our engineering meeting the other day, we had a conversation. Like we see people talking about, you know, running 15, 20 agents in parallel and we're like, but I can't do that. And then you have engineers thinking like they're lesser um engineers because they can't run that many in parallel. But the reality is you as a human cannot um have that much of a split focus and deliver quality work. And I think what a lot of people, you know, talk about is, you know, they might have a bunch of things running in the background doing small little things and so on, but you know, when in my own experience, I find that, you know, two maximum three topics at a time I can focus on. Um, and so I think, you know, the there's a lot of falseeness out there. people, you know, looking for attention, you know, companies wanting to, you know, um, kind of like make big statements because it's in their interest for people to adopt their their techniques or products. But I think, you know, the reality is we're all still learning and we're at the beginning of this. U nobody that tells you for certain they know the future of what engineering looks like really speaks from experience. But we're in May, so a lot of people, probably four or five million at least, people graduated with engineering degrees. What What do they do with that? How do they They've always been It's always been a flawed system where it's been a bit too much green field. But if you were advising, as many of our listeners are advising hopefully junior engineers, because I think we all agree that you can't have senior engineers without junior engineers. So we need them in the industry. It's probably the least welcoming time for them. So what should they work on right now? What skill sets are they not being taught in slow curricula? >> I think you know it is probably the hardest time that I can remember in my career for junior engineers because there's this expectation of things need to move fast and nobody has patience for anything anymore. And what you as a junior need is people to make themselves available to share their knowledge with you. Now you can hope for the ideal or you can make the most of what the reality is. And in these LLMs, you know, you can get a good teacher as well. Um, you know, you can tweak it a uh its system prompt to, you know, make sure that it explains things to you and it doesn't just do it. you know, ask questions and don't let the the LLM implement it for you, but do it yourself until you understand it. You know, I I think the the the trap is that as a junior engineer, you're going to think that the AI is going to do everything for you. >> It's not going to >> I don't think that's just junior engineers. That's not going to teach you the judgment and the taste uh kind of like skills you need to learn to know what is the right thing to do because the LM will confidently tell you what it thinks is is the right thing to do. But do you know when to push back? And that unfortunately happens through, you know, experience. And that experience, you know, I mostly gained through other people, you know, whether it was code reviews or or kind of like, you know, listening to talks or whatever and and just team members sharing their experience. Um, and so it's a very unwelcoming environment at the moment where businesses are under pressure to to prove that AI can accelerate them. they need to justify their AI spending and and so it creates a hostile environment for juniors and so I do feel like there's a there's a a message in the industry coming up you know we got to slow down as well it's not as loud as the voices of those who say you know we got to move fast um but yeah it's it's a tough time but you cannot be despondent about it the reality is yes we need junior engineers because they are tomorrow senior engineers um but they're going to have to adapt adapt to the new reality and not just rely on on the organic transfer of knowledge that used to happen in in companies. Um, you know, if you're working remotely as a junior, it's even harder because you don't can't just tap somebody on the shoulder to ask them a question. So, yes, tough environment, but it is possible. You just have to um, you know, approach it differently. I think that one of the the things that we always should have been teaching and this is my bias is we need to teach them to write better. I think that prompt writing is a skill and that maybe that's a thing we should concentrate on. Like like Dave says, how do you know you're getting what you want? How do you write a test for an agentic system? like can you get it to prove that it's doing the thing that you asked for? Okay. Did you ask for it right or did you you know sort of handwave and it assumed the middle of the bell curve when you wanted something out on the edges. So, I think that um it's very interesting to see how many people lean on LLMs for their writing when writing is a very sophisticated form of thinking and we need that thinking to understand what we're trying to make. >> I I I I agree with everything everybody else has said so far very much, but I just want to take a slightly different angle on it. Um I um I think this is a horrible problem because as as Jean Heidi said, you know, certainly we and and you know people before us and since since us, you know, we learned by doing the the the things writing code, making like writing lots of code, making mistakes, learning from the mistakes, and figuring out what works better. that that's certainly the way that I learned how to do things and we are rem I I I would agree with what Jean said earlier is that when I'm using it's been a while since I wrote any code. I still occasionally write a code. I do it for examples to show other people what code looks like and I do it for fun because I like writing code but I don't do it for production. If I'm doing production the AI writes the code. I think that we are, if we're not already past it, we are at a tipping point where humans don't write code anymore. I think that's where we are. I And I think that people that are saying you've got to review it and understand all of the code does and all that sort of things. I think they're wrong. I don't any more than you know when high level languages came in. We used to look at the assembler that was generated and say do you know is it doing the right things? How often do you do that? We don't care anymore. That's gone. The code is generated. So, so programming has taken this step in abstraction. So, so if you perceive yourself and part of the our problem that we're in as an industry is that most juniors start off perceiving themselves this way. If you perceive yourself as your job being to write code rather than to solve problems with code then that's where you see the difficult part is that's where you see your skills and I don't think there are so that so I think that the best thing that juniors can do is look other places for where to apply their skills their technical thinking and I think that there is there's I would call it engineering thinking but there's a there's Something about the way in which an engineer decomposes a problem, thinks about how to carve a problem up, what these are, thinks about the ways in which things can go wrong and the corner cases and those kinds of things and analyzes in a disciplined technical way, all of these things. And those are the things that we have to prompt the AIS with because if you don't, they'll just write crap that won't work. So, so you know, we've got to specify things, you know, like this. You got to think you you need to have the kind of mind where you're going to think about those. You've got to understand the problem that you're trying to solve really well. And you've got to be able to work through the problem and learn bit by bit, step by step by step, you know, what the surface area of the problem is that you're dealing with and communicate that to the AI AI that's then going to generate the code. And you do this by specifying exe creating executable specifications tests if you like that specify what what it needs to do and then how you will evaluate that that happened and those kinds of techniques. But those sorts of skills I think are going to be in very short supply. So if I was advising a junior now I would say try and figure out how to learn those skills fast. I would say you can't go far wrong by learning how BDD works and think about that as a specification language. Think about that as the way of telling what your AI is meant to do and I think that will give you that will put you on the right track I think. >> So let's loop back and say BDD is behavior de driven development like what do you want as an outcome not how it gets there. Yeah, >> but what do you want to have happen? And yeah, that kind of thinking is going to be so vital. And it is something that we used to reserve for sort of mid-level engineers. Like you didn't get to do BDD until you had done grunt work on like how do I make this work at all. >> Okay, we have some questions from the audience that are excellent follow-ups. I'm gonna take the more recent from Greg. Uh, and then we're going to go into the reviewing of it all because that is the bottleneck with AI and we have a bunch of questions with that. But Greg says, "Do we need to fundamentally change how we teach people software development?" We always did. Uh, how much effort they should be putting into learning to code, programming, language, syntax. Uh, I would venture to say something we haven't talked about, but this is the problem with open source always anyway. the domination of the English language and is that going to bias people that aren't native English speakers or as compelling writers as those of us in this digital room? Yes, I I think we all agree we need to fundamentally change how we teach software development. How >> so I sorry go ahead please. >> Okay. I think that it's very interesting. I was talking to a couple juniors last week and they're like, "Oh, our our CS professor is so old-fashioned. Um, she's teaching us like um Java." And I'm like, "Oh, Java was what they were teaching when I was in college, which was quite a while ago." And I'm like, "Actually, it doesn't matter. What matters is that you learn that you can affect how a computer behaves. That you know how to structure something so that it communicates with the computer and that you understand how to make a small change and see the result. Like I learned to code HTML with a program called Hot Dog Pro which had the beautiful advantage of you didn't have to compile. You didn't compile HTML but whatever. You didn't have to upload it. it would show you in real time what change you were making so that you could see. I think that's what we need is like the ability to say like this piece of code changing does this thing which is BDD but we haven't really been explicitly teaching that >> like a new way of abstraction but tied to business goals to your end users. Yeah, I I it's not just business goals, I think, but it's what the behaviors are that you want of the system, but I I think that what we are seeing, what I am seeing in in the way that I use AI assistance anyway, and I'm doing things is genuinely a step to a kind of fifth generation language. So, this is kind of programming at a different a genuinely different level of abstraction. If you think about the way in which regular programming worked kind of weirdly in with the benefit of hindsight was that we concentrated less on the problem that we're trying to solve and more on the solo solution that we were trying to solve it with. So the the solution was often kind of implicit. It it kind of wasn't called out anywhere very much. If you were very good, you might have some tests that said something about the solution. But other than that, the sorry about the problem, but the solution itself was was, you know, was the code and that was the deep focus that's gone. So, so now what we're talking about is absolutely specifying the behaviors that we want of this system. I want to make a game. I want when this the bullet hits this thing, that thing blows up and this thing goes off the screen or whatever else. I'm going to describe the behaviors that I want of the system. But in addition to that, there are other kinds of behaviors that we as technical people are probably the only people that we'll be thinking about. And you'll say, so okay, I'm going to think about it's a big deal when two people are doing the same thing at the same time. So, if there's another player going on at the same time, what does that mean in terms of the way that things interact? What if that person fires a bullet and this person fires a bullet at the same time? Is that going to break or anything? I want to want to think about those sorts of things because concurrency is a complicated thing. If I'm building some Let's move away from games because it's I'm I'm starting to struggle with my analogies. But but you know if if I'm if I'm building a bookshop or something like this, you know what happens if the book's out out of stock? Those are business problems, but they're also technical problems. What happens if there are too many people trying to work with it at the same time? How are we going to deal with those sorts of cases? We need to figure out all of those sorts of behaviors. And that's a mix of understanding the behavior of the system and what we classically have talked about as kind of the architecture and the design of the system. So we need to worry about that stuff too and we need to think about how can I compartmental compartmentalize this so that my AI assistant doesn't go crazy and do something mad. So I still want a modular system. I still want to be able to change it easily when I learn more and get things wrong. I don't want the AI coming in and breaking everything. I still want to be able to validate that I got all of the things that I had before when it makes a change because I now now I'm not relying on the code anymore because it's probably going to change more of the code than I expect when it I ask it to change things. So all of these things those are the kind of engineering disciplines that seem at the core of what we're doing now. And we didn't talk security or anything like that, but does that mean that like you the the agent has to should by default selfch check that it's not leaking private? >> No. No. So So I I I think it will help if it does a bit, but we've got to think about that as well. We've got to think about those risks. We we can't rely on those things. But those are also behaviors of the system. So I want it to be secure. I want to make sure that when I pay by credit card, my credit card isn't isn't leaked onto the dark web. and you know and killed. >> Okay, so we know one of the biggest problems is reviewing all this code because it's exponential. So we have actually two questions that kind of touch each other on this from fabulous but anonymous attendees. So thank you for your questions. Someone said they're very interested in the Gentic review loop assuming we have strong CI/CD practices and observability in the rest. you make that. >> Um, a lot of companies don't still, but it seems that the big gap is the review loop. What's stopping us from yolo? You only live once mode. How do we enable humans in the loop reviews? How can we keep someone saying, "Yeah, it's good to go while opening that bottleneap up a bit." And then as the other question is if humans can't keep up with reviewing all the AI code which it's impossible then how can we verify that the right decisions are being made for example architectural decisions that are consistent with the existing like yeah so how do we make sure the answers what we're releasing is right and good especially you're not writing code anymore how can you know what good code is? Yeah. So, this this was a conversation I had with uh another engineer earlier this week, so I feel like I've got it loaded in my context window. Um I I think the role or or the the function of code review needs to change. Our tools are not geared to to facilitate the new reality that we live with. And our process and and expectations that we've placed on on individuals for code review isn't scaling. you cannot um keep up with the amount of code that an AI can produce. And not just that, there's a psychological component to it when I look at a PR with a lot of that's going to take me 30 40 minutes to properly review, but I know it took the another person 5 minutes to generate. There's an inequality in terms of the effort that goes into that and that makes me less uh desirable to to engage with it in that manner. Something that we've been experimenting with at Kilo is pushing more of the responsibility of correctness and ownership to the PR author you know and that doing basic things like you know you're expected to run AI code reviews as you develop uh locally even you know and yes we have an AI code reviewer that runs on the PR and you know it will pick up a lot of issues but what we're not expecting you know the code reviewer to uh to do anymore is you read the code line for line, load the whole context up because it's too much and it's too too too fast to to do all of that. And so through things like our PR templates, you know, where we're asking the author to specify, you know, how did you verify this? Uh, you know, add some screenshots or a walkthrough video of the feature. Um, you know, and obviously what the the the role of the reviewer moves to a higher level. then it's more like is this even the right solution to the problem? Um, you know, one of my favorite things to add in my PR description is what was the problem and how does this PR solve it? Because as a code reviewer coming in now, I think that's the most important thing you can look for is is this the right solution to the problem? Is the problem correctly? >> Yeah. Is this even the right problem? Um and and then you know through domain expertise and understanding of an existing system you know look at it is this architecturally the right way we want to go. Does this match the the systems we have uh and processes we have on our in our business and so I think the the the function of the reviewer is changing. The sad thing about it is that code reviews was a great way to learn about things and the you know now that we're seemingly engaging less with the the content of it um you know it's a it it takes away some of that learning and sharing of knowledge uh in in the system but I think you know through better tooling uh and uh more normalization of what code review looks like in the in the world of agentic engineering we can still get to to being able to understand and and learn and share knowledge through code reviews even. >> Absolutely. We have another question that I really love because I've heard I I love the idea of what's happening in team size. the interesting maybe it's my bias is not a codew writer though nobody will be now but maybe it's my moment but the idea that the most interesting changes and I think this is the lead dev audience in us all are not technical it's the people and processes to respond and Paul brings up a great point and I asked the room what do you think the future of pairing and mobbing practices are now that an agent is another and probably the only driver in the group. I don't think it should be the only, but we'll see. As an advocate of pair programming, as a review process, a sometime harness for testdriven development, and crucially a knowledge sharer, I'm seeing my team default more to working with an agent as a pairing partner rather than another human. I mean, I I call it throbbling now. I think there can be agents involved but two humans is definitely how to learn especially when we have that gap of maybe a junior senior pairing which juniors may be more comfortable with the AI maybe too comfortable in things but how are you seeing these like traditional agile processes adapting >> so I I I I certainly don't think that there's any barrier to the value of pairing along with the AI you get get the it feels a little bit closer to mobbing in some ways as somebody said because the you know the the AI is doing doing the actual code generation but um but I've I've done that a few times where I've paired with people as we we discussed the problem and and had some good results. I think that works well and as you said that's a good way of learning spreading knowledge amongst the team working together. I think that works effectively. Um, and I think it I I've never I've long been thinking that pull request models for code review were second best anyway. And I still think that they still are. So they they lag too much that we want the we want that conversation at the moment when we need that conversation, not a few hours later. So So pairing pairing is good. It puts us in the right place. I recogni when people started saying that working with AI assistants probably a couple of years ago now started saying that working with AI assistants was was like pairing I didn't see it that's not how it felt to me they felt like smart complete to me at that stage but now they are now now working working with an agent I I use Claude mostly when I'm programming working with Claude it feels I feel like I'm working with a slightly weird person it It feels it feels like that. Um and and that's a good that's a good thing from my point of view that it feels like a collaborative effort on our part. He he it does a bunch of things um that I don't do and I do a bunch of things that it doesn't do and together we get a better better result. So So I'm okay with that too. But I I think that pair pairing is a good use of time and may be part of the solution for what we do about the junior problem because the junior problem's a serious one because we're going to run out of seniors really fally soon. You know, at the rate that things are going that there's not much hiring of juniors going on at the moment in many parts of the industry. That's not a good thing. I think one of the one of my big hesitations about AI is its non-deterministic nature. >> Um, humans are also non-deterministic. So, it's not like they're perfect at reviewing code and they might give you different feedback on the same PR on different days, but for learning purposes, it seems to me that I want something that will be predictable and honestly for for all purposes like the ideation everything that's fine, but I find it distressing to think about differing things going out um without me realizing that they're different. And I think that's why I'm AI hesitant is because like I don't trust it. And I think that one of the things that we can do with pairing is say like, "Hey, you gave me a different answer last time. Why why?" >> Um because sometimes it's like, I don't know, I pulled a different part of the context window. And sometimes it's well, it's 50/50. Could go either way. In either of those cases, it's useful to know like, okay, you know, there's there's another route or there's another reason I'm doing this. So, I think that pairing with an AI does get you like like it's a very sophisticated rubber duck. It makes you say things out loud. It makes you understand your assumptions, but also it allows you to it's very agreeable. And I think for me, AI would be more useful if it were less agreeable. If it were a little more opinionated, >> have you to be antagonistic? >> I Well, if it I make it antagonistic, then it's just a dick. Um, >> it is trained on the internet. It is trained on the internet, but I'm like I want what what I want from it is like an opinionated personality that will because that's the thing about pairing is like why are we doing it that way? What's the point of that? How how could we do that differently? That that collegial push is a large part of how we learn from pairing, I think. And AI is it rolls over too fast. It's like, "Oh, you're right." >> Okay, as we wind down, let's just think about, we're mainly speaking to the engineering managers and future engineering managers on this call. What advice do you have for them in this time? I I give I give them a piece of personal advice rather than career advice, which is if you're the kind of engineering manager that hasn't written any code for a little while, go and write some code with wi with an AI because it's so much fun. It's so easy. >> Yeah, I'll I'll echo what Dave says. You got to get hands-on with with this code. The worst thing you can do is to try and lead people but not have empathy for what they're going through at the moment. Whether it's the doubts, the uncertainty, the frustration of swearing at an LLM because it confidently does something stupid. You have to experience that with them um to be able to lead from a position of authenticity, but also to make good decisions. you're going to get pressure from up top potentially to, you know, do AI strategies and stuff and, you know, there's an expectation to 10x your productivity because this is what this person said or, you know, but you have to be in the trenches and experience these things so that you can have informed conversations and share from your own battle scars, you know, what it is like to to adopt to agentic engineering and and feel where where things are moving faster, where are the bottlenecks, where do you suffer? Um, where where's your process not working well? And you have to get hands-on, not not to be on the critical path of feature de development or anything like that. Uh, or not to relive your glory days as an IC, but really to to to kind of like get this experience. The the shift is big enough that you cannot rely on your your old kind of like experiences as as a programmer. hire for communication skills and not code skills. Uh the ability to explain not only to an AI but to your co-workers what you're trying to do is even more important than it always was. and study it yourself. Take a toastmasters course or something. But I blame a lot on engineering leadership not understanding how they connect to business goals because it stops with them and they need to advocate for their teams. And you probably actually have budget to do all the continuous integration and deployment. This just say it's part of AI. That's the best advice. If you say it's part of AI, you may get the budget for it. Finally, >> it's quite good at doing some of it for you if you ask it well. >> Just always check and trust your teams. Keep that door or Slack huddle open and we'll continue the conversation in Slack. We had some more questions and thank you so much Jean, Heidi, and Dave. And thank you listeners. Good luck out there. We really seem, I would say, more optimistic than I thought we would be. >> Thank you all for attending. >> Thank you., Safe Production Changes With Agents, YouTube, 01kv3sjgkwyc8ydjra3zq0te6m.