What a year of hands-on AI coding teaches you about good software with Lada Kesseler

Speaker A: I got lucky and I saw what a focused agent looks like. I think many people are working with an anti pattern of distracted agent, which is basically you're like, hey AI, here's my rules. And also do this, do this, do this, do this, do this. And they're like, oh, and when it messes up, you just add another one to that, right? And nobody pays attention. Does it actually do the thing you asked? And usually what you see is the answer is no. Foreign.

Speaker B: Rebecca Murphy and this is Engineering Unblocked. Engineering Unblocked is brought to you by Swarmia, the engineering intelligence platform that's trusted by some of the best software companies in the world, including startups like superhuman scale ups like Miro and companies from the Fortune 500. On today's show I'm talking to Lada Kessler, lead developer and technical Coach at Logic 2020. I reached out to Lada after watching an amazing workshop she gave about mapping the uncharted territory of AI. And one of the attendees said, lada, this isn't just another Genai tutorial, it's a compass for those of us who aim to design intelligent systems, not just use them. Thank you for mapping what usually stays in the shadows, the judgment behind the code. And that's a pretty strong recommendation. So uh, I hope that you will be able to learn some things today from Lada. So Lada, welcome.

Speaker A: Uh, hi Rebecca, thanks for having me. Yeah, I appreciate the introduction.

Speaker B: Yeah.

Speaker A: Anything else that you want to say

Speaker B: about who you are or anything like that?

Speaker A: Oh yeah. So like, like I said, I'm a software developer and I think of myself as a crafter in that like I'm trying to build systems that work really well, but also the systems that also solve the right problem and kind of make users happy. So I kind of like UX aspects of things as well and my roots are really in like the deep Agile, like the early Agile. So I think about this as extreme programming, right? So the 2 TDD refactoring domain driven design, like evolutionary design. And I've been kind of, like we mentioned, acting as technical coach on my projects and uh, currently kind of trying to explore what all of those values mean in this new territory of AI. Right? How do we apply this to AI? How do we write system that is good and reliable and delight our customers with this unreliable tool that lies to us and breaks and ah, all kinds of madness going on. Right. So, so um, then kind of trying to naturally share knowledge, what I learned about it. And like the ways I do this is like the talks and nowadays people ask me to do master classes and all that.

Speaker B: Yes. Let's not forget that um, you too can have a classroom lotta if you would like. Um, but um. So what I really liked about your workshop first I loved the map. There was a literal map of kind of the AI landscape and it really focuses on you detailed obstacles, patterns and anti patterns and a few different, different areas. But it started from five gaps that we already, I think everybody recognizes uh, regarding AI and just wondering if you can talk about those five gaps and how you arrived at those.

Speaker A: Yeah, that's actually a perfect, perfect start starting point I think because I've like the way I've been thinking about this is so it feels like we're in a new territory. It feels like the rules of the land changed in enough that we kind of need to question our assumptions and learn. And I think the best way to do this is to actually um, try to do things and, and kind of observe what we see. Right. So this is where I coming from. So I observe. I come to this patterns by basically observing my pains. Right. So I've been. It's a lot of hands on experience for me. Right. This year I've been just doing so much hands on coding and writing agents and whatnot with it. And what I saw like some of the things are like well this tool. I keep repeating myself and it's really annoying. Why is that? Well, this thing cannot learn. Right. When I talk to a junior developer, um, they're usually sharp. They're usually sharp people and they usually know what I told them the day before. Not the case with Agenda Ki. Right. So we kind of need to build those systems knowledge and how do we build this knowledge? And this is like I think about my talk like I think you perfectly started with obstacles. Absolutely. I think about this as uh, basically three hikes. And the hikes are around context management and the obstacles are basically those mountains we have to walk around. Right. We can't do anything. We have to figure out how to get to where we want around those things. And then we have a kind of non deterministic. Right. So the next bit is non determinism. And basically. Well, uh, the same input doesn't mean the same output. Right. You give it the same input and now it suddenly does something else. Well, it's a bug in the feature. We can maybe exploit it as well because you can actually try it several times. It's like throwing a die, right? You throw a die if you want a three maybe you throw it 12 times and then one of them will be a three. And there's also amazing opportunities around combining the solutions like this and, and so on. So I'll show that uh, so the non determinism bit is like a. There's a plethora of patterns and not just this obstacle. Like there's many obstacles together. They kind of mean our reactions to them needs to be a certain way. And then the last bit is about communication. Right. So we have something that is very mysterious. So like we don't. We open code and we see what the code does. No mystery there if you just need to know a little bit. Like with the eye it has like a, an approximation of mental model there. And uh, like that mental model is often hidden, like you can't really know. And so like any misconceptions there kind of detrimental. So I show like how it's like I keep telling it things to do it a thing and it's like, yeah, I'm doing this, I'm doing this. But in the end I see that it actually misunderstood me entirely and didn't ask me a question. So that's like the second problem there is compliance bias. Right. So it's trained deliberately to, to say yes, to say you're amazing. Uh, you're right. And so on. I have a pain point around you. Right. I think I need therapy. Um, you're absolutely right is a triggering phrase for me. So you have to fight that. Right. So how do you communicate to it in a way to get better results from it? And there's absolutely ways to do this better than just people give it commands instead of going back and forth and back and forth makes you so much more powerful because you can not just. It is basically I think about it as an instrument of vision. Like you can. I'm at a point where I need to make a decision. I can make one decision. But if I ask it, it's so well read, it knows m more than I know. So I can fish for what's the universe of possible answers here in front of me. A small scale, just like a little experiment or a little like. And this is just so much more powerful. This is this what I call reverse direction. Yeah. So this is how I kind of think about those things.

Speaker B: So those are pretty fundamental challenges. And I think like anybody who's using AI for software development is running into every single one of those. And I also am highly triggered by. You're absolutely right. Um, and I'm constantly frustrated that AI won't ask me a clarifying question. Um, yes. And that's can talk about our wish list for AI.

Speaker A: Yeah. Have a long one.

Speaker B: So how do you create a system where AI, this is a simple question. How can you create a system where AI can, um, be beneficial and not detrimental, given those challenges?

Speaker A: So, so you kind of start from the, from the learning what it is, I think, right? And, and what. Learning what it is actually empowers you to do better. Because, for example, I can give one example that I see many people doing kind of a way that I think hurts them, which is I got lucky and I saw what a focused agent looks like. So I think many people are working with an anti pattern of distracted agent, which is basically you're like, hey, AI, here's my rules. And also do this, do this, do this, do this, do this. And they're like, oh, and when it messes up, you just add another one to that, right? And nobody pays attention. Does it actually do the thing you asked? And usually what you see is the answer is no. Why is that? And I saw something fantastic once by luck, sheer luck, which is I have a little committer that is dedicated to committing. And both little committer and my main AI I code with have the same ground rules. And the ground rules are be proactive, warn me about issues before they become a problem, and so on. And suddenly this little committer that has only one little focus of committing starts to warn me about issues. Well, the main one didn't ever. And so the difference is between always and never. It's nuts, right? It's crazy. And yet I see so many people not understanding this fundamental difference of there's a concept of focus in the eye, right? So it's not just context. There's a context. And like, if we can increase context window to infinity, we'll be so happy. No, because really it has a concept of focus and can only. It feels like it can only pay attention to one thing very well. But knowing that means that we can design around that, right? Because now. So I added a few patterns after this talk that you saw. And that's around AI slope, right? So AI slope is like all, uh, the simple recipes give prompts to AI, maybe lightly edit it and then present it as own work. I don't want to be, uh, judgy here. Um, but I want to say a simple thing. One pass with AI doesn't work. It doesn't actually produce good results for anything more complex than, uh, a simple, simple question. But knowing that empowers you to actually do better. Because now I have a pattern I can Encounter it. So I have uh, a pattern of feedback flip. You can just have one AI criticize another AI and the difference would be stark. Surprisingly, the same AI criticizing its own work also works amazing. And I'm not convinced it works worse. Why is that? That is a question. Because now you see that you gave AI a task and you said end, end, end, do this, this, this. And we thought it just wasn't good at writing good code. It just wasn't good at all these things. But it's not the case when you ask to do this as a primary task. It's amazing at that. It can tell you uh, all the things that are wrong with your code. Why didn't it do it? I think we're going into focus. This is how you think about. This is how you figure out what systems we need. And I think we don't have like we, we need the tools we have are very bad. Like they're limiting me every way. Like, and that's how you figure out. So that's how I approach it.

Speaker B: So at Swarmia, uh, we talk a lot about best practices in software engineering. And you work at a consulting company. So I'm sure you also spend a lot of time talking about best practices in software engineering. And we've talked about like I have known my lines for a long time that we talk about like limiting work in progress and having small batch sizes and finishing what you start and maybe only working on one thing at a time. Um, do those rules still make sense or do we need to re. Re examine them?

Speaker A: So I think re examining everything is a good idea right now because it's like seriously changed so much. But I think what I'm, I've ah, been doing that. So I've been asking myself a very hard question to somebody who cares deeply about software craft craftsmanship is, which is, is software car partnership even better if we just can regenerate all the code. And the answer is a resolute yes. Because those agents, what I see them doing is they basically code themselves into a wall at full speed. So what you see in teams that don't know how to do systems, proper system design and the principles that actually make maintainable software, they just code themselves into a wall at super speeds. And that's a problem with when you're dealing with something that needs to be reliable and harming the customers. Right. You don't want that. Uh, and many other things. So I see the craftsmanship principles, for example, in code like AI, when you put it in a good code base, it Actually replicates goodness, it will still degrade, but if you start from good, it will less likely to make messes. And for example, if you actually leave bad code, old code, like code that's not used, that's detrimental completely because it will find it, it will try to edit it and like, hey, I've done the work. Like, no you didn't.

Speaker B: Why?

Speaker A: And it's my fault at this point because I let it degrade to this point. Right? So you kind of have to find those and be merciless about deleting them and all of these other things. The focus part, right, what you mentioned about like, is it important to, to do small batches of extremely. Because AI is not managing complexity right now. I think it's the most crucial question right now. Can it eventually manage complexity? Because the difference between yes and no here is we need to build a system that writes other systems for us and we don't even need to be mentally involved. That's one kind of universe we're going to live in. If that's the case, I'm not convinced right now. But another universe is we still need to understand what this thing does. At some point a human needs to be involved, involved and maybe we can zoom out and work on a higher level, uh, and it can empower us, but we still need to be involved. That's a different system entirely. And nobody tries to solve this because the big problem that like I think we're facing here is AI adopted the um, the pull request model. So basically I can, I can design with it and as back and forth feels very collaborative, but then it goes and does the coding and the coding is a diffusion, right? And this is where my mental model of what's inside my software just degrades. Right. I don't know what it does. I have to invest a lot of time, my time to understand it. Um, and nobody tries to be like how do we collaborate, right? Or at least I don't want to say no, but it does it. I don't see people thinking about and um, talking about it. I see a lot of systems that kind of try to do the same thing, but I think the core issues are around that. So I think we kind of need to. This is the pain point, right? It's a massive one. We need to solve it somehow and we need to like observe and see what we, what we can do to learn. And I think everything else we learned about agile, about how to work efficiently, small batches, right? Managing complexity. So I have to manage it. Can't Manage complexity. So I have to do it, right? How do I do it? I chop it up into small pieces. The ridiculous things sometimes because like AI is not software to the degree that I gave it a small task. So I gave it. Okay, it wasn't a small task. To be fair. I have 180 slides on the first talk and I'm like, look at every slide and make me a textual representation in markdown of what the slide is about in a certain format. Simple. The one thing that my software had never done before is came to me and said, oh, that's too much. I'm going to cut corners. This software doesn't do that stuff. And I like that. But ridiculously, the codecs that I gave, I used codecs for a reason. Codecs. Supposedly everybody was like, the latest code codecs is like uh, GPT5 codecs, uh, model from One Tropic, right? Oh, sorry. From Opena. It's like so, so good at um, being thorough. It's much more thorough than cloth, blah, blah, blah. Oh my God. This model was like, oh, you have 180 slides. No, I'm just gonna cut. I'm just gonna like, I'm like, I'll do 10 and then I'm just gonna be like, oh, I'll just write a script here and I'll just like. And the results are horrid. Like, absolutely. So forcing this thing to just look at every 180 slides is ridiculously hard. Right. Something you never face with it. So this is where managing complexity, chopping it. Small pieces, you need to know this stuff. So you have to give it things in small increments and small pieces. Absolutely relevant.

Speaker B: You talked about kind of software as a craft and I think at this level, like, yes, uh, everything you just said is correct. I agree with you. At this level, how precious should we be about if we're doing everything you just said and creating relatively small diffs, how precious should we be about what's in those diffs versus writing tests to make sure that the diff does what it should?

Speaker A: It depends on what you're building, right? Big time. This is where like I think of wipe coding versus craft. Like the manual work where you'd know every line of code as a dimension now. So previously we just had this little piece where we need to know every line. That's the way to do things. Now there's a dimension and wipe coding is the edge of that dimension. But like depending on the difficulty of what you're facing with. Right. How important what you're Producing is to not break how big it is, how complex. You kind of have to use judgment to be like, I need to look deeper or not deeper, right? And I absolutely have been exploring all kinds of like I've been playing with it very deliberately, like what can I get away with, right? And some things that are so I see a lot of people who are at edges of this thing, right? They're like I only will work at this. Like they try to be like there's a monster under the bed. Uh, if I, if I pretend long enough it'll go away, right? I learned earlier on that I think in this, in this case it won't happen because it changed enough in my work that I think we will never go back to working the old way. And I think it's a good thing. Although I love previous like I love my work, I still love my work. I still write working software. But like the edge, right there's vivecoders and that's fine. And I see people like here not wipe coding sometimes where they should be like, I think they should be wipe coding little tools, they should be wipe coding custom things that give them answers about problem space. That's the thing where you can get so much benefit like and you can just empower yourself to like crazy. Uh, but like the extreme of wipe coding is like productionize the system like productional system, wipe coded to production where you care about your customers. Oh God, please don't do this. Right. You're gonna shoot yourself in the leg, you're gonna lose trust of your people. You're gonna code yourself in the situation where you can't code yourself out because you need to have engineering skills here at some point the complexity is such that you, you just can't get away with this, right? So kind of this is where it depends, right? And it depends to the degree the benefits are real and amazing. Like I've done this. Uh, so we did a real impact on Agile 2025 with a group of technical coaches and other people, like uh, product people who had an amazing team. Uh, there was awesome crafters, Seattle software crafters, uh, Llewellyn Falco, there's uh, Woody Zul, we had a group of ten people, uh, creator of Fast Agile, um, and we tried to take a problem, a real problem for pissed people and solve it in three days and also show how to do it with good agile practices, right? Not bureaucratic but like self organized team, Fast Agile. And this is why we succeeded. I think that's the core of why we succeeded. We were solving the right problem. It was scoped well and we worked with the customer very closely. But if we didn't use AI, we wouldn't have. We just wouldn't have time. Right. And this is such a small thing. And the people who came to us didn't need more than that. But we solved two problems, which nobody thought we would. We solved two problems for them, not one. And like, we were like, oh, it's two is too ambitious. We can probably just do one. No, we had ambitious people among us. They're like, let's do both because we want to. This is a real thing that makes real difference for children who are, uh, like, facing abuse. Let's try to get them funding. And we got solved both problems with AI in the end, but not because of AI. It was empowering the skills we had. Right. Not like the solution, but we got them real funding. And the fact that we did this right, it's making a real difference. That's just so satisfying.

Speaker B: Yeah. And I find myself writing more software than I've written in years.

Speaker A: Uh, absolutely.

Speaker B: I've been in leadership for too many years. Um, and even my current job doesn't. That don't call on me to write code much, but I've been writing a ton. Um, so I think there's also that for somebody who's maybe no longer in an engineering role, it can provide so much value because, again, I understand what good enough code looks like and I understand what bad code looks like. And this is my personal tool. So we're very much on the vibe coding end of the spectrum. I want to talk about another best practice. You, uh, mentioned it up at the top. TDD and testing and all of that. Um, the 2025 Dora report. Um, I don't know if you've seen it, but it really, like, talks a lot about how AI is an amplifier. And so if you're good, it will make you better. If you're bad, it's going to possibly hurt you more than it helps. And that could be in terms of quality or reliability or just emphasizing a bottleneck that you already had.

Speaker A: Yeah, I really agree with that.

Speaker B: So one thing I'm noticing kind of as a result of, of that realization is that companies suddenly want to or are willing to at least consider spending time and money on things they should have always been doing. Yes, but what are other things? Like test testing is an obvious one. More documentation is another obvious one. But what are other kind of things? That they've always been good practices, but

Speaker A: now they're essential Yeah, I think in general, like, you need an engineer in there right now who knows what's they're doing guiding those things, right? And the engineer is there to manage complexity and um, like design. Because think, think about, you have a problem space, you have a solution space. With AI, if you have nobody owning that solution space, then it degrades, right? Because AI cannot maintain this. It can't like think about all the level right now. Right. At least it doesn't. Maybe we can build a system that does it. Like, TDD is an absolute awesome thing. Like you mentioned, I, I love TDD with AI, I have my own process that I wrote that works really well and a few people have been spreading it around, seems to work well for them. And what it does, it gives that immediate feedback. And also I do predictive tdd. So this is like, you guess will the test pass or fail before you run it. And that allows you to maintain a mental model of what's happening. And then what you get from that, and AI gets from that too is you get surprised when it's not the case. And like, oh, no, no, I misunderstood. And that can allow that very small feedback. Like this is small feedback loops. Small feedback loops are essential to any kind of management, right? Any kind of going where you want to go. So same thing here. Um, I like refactoring quite a lot, right. So I refactor in general, refactoring is the one superpower that if you don't know how to do, right? So there's a lot of developers that just get thrown into the canna industry and nobody teaches them some things. And it's not just, uh, coding in the end, um, it's not just syntax, right? Syntax is just so much less important. Uh, so refactoring is a superpower and it's a way some people are rewriting instead of refactoring, just writing barrel code. But refactoring is basically learning the ability of transforming code in your brain in small, small steps. And then you can basically go however far you want with this. And that allows you to change and modify it where you want it to be. Um, and get to good software from bad software without breaking anything. Especially if you have statically typed language. I do crazy things with this. If you master it, you can do things like, I've been dropped into system of 50 microservices. And that I didn't know, right? In a month I emerged from that, uh, having changed the architecture of 10 of them in a better way, plus delivering the feature they care about and saving them a few millions of dollars because I did. And improving things without breaking anything. So massive, massive change. What people like, oh, refactoring, they're going to break things and so on. No, if you know how you won't. And you can do this with AI. So I'm kind of figuring out how to do this with AI with Llewellyn. Falco has an amazing process file um, about refactoring with AI. That gets you to the code that is not disgusting, that's not bad. So AI writes codes that most developers are uh, cringe, cringe. And now you can run this thing, it's automated, it gets you to better uh, and all of that. I think it's all applicable in the end. There's many little places where it's applicable.

Speaker B: You kind of raised an eyebrow when I said document documentation. Um, and that documentation is necessary. So was that an agreeing or disagreeing eyebrow?

Speaker A: So it's a question, right? Because documentation has always historically been hard because who's maintaining it? Right. It's a big problem now with AI actually documentation becomes much more important. Before so Agile was like we prefer working software over bureaucracy. I would call it initial specifications. And now we're kind of going back a little bit but like not quite I think. So some people kind of developing software in a way that just defines the whole thing, the whole spec. I don't tend to do this. I work much more iteratively in small steps. But I still spec. Right. And now my documentation. Yes, uh, documentation now is just much more important, the good documentation and it's more important to keep it in sync, tend to it and so on. And I have some patterns around how do you not let it degrade and so on. But like we need more around that.

Speaker B: I had one project I was playing with and everything I've done with AI is playing. So I, that's why I talk to people like you who are doing real things. Um, but I had one, one project where I actually had a, had a GitHub workflow or whatever they're called, GitHub action to run an agent that would review the documentation and make a pull request for, for anything that had changed. So it wasn't on me to update the documentation anymore. It was kind of self updating. I'm sure that that could be like optimized far beyond what I did. But I think that sort of stuff is really interesting too where you can just use AI to bake in the practices that you were perhaps avoiding previously because it was just too Hard or not perceived as valuable.

Speaker A: Exactly. But you need to know them right first I think to, to guide AI efficiently. That's why I'm like, I think still like you need to learn engineering practices if you want to write software because the rules didn't change in that lab. Uh, it's still software.

Speaker B: Everything that you're saying so far like matches pretty well with my understanding and my, my like what I've, what I've come to believe by talking to lots of people like you. Um, on the other hand I've also talked to people who say our developers don't write code anymore. Like they don't do that anymore. We like deeply spec the uh, feature up front maybe with a lovable prototype or something like that and get customer feedback. And then we make AI build it and the engineers supervise. But the engineers aren't like. There are also completely autonomous agents in some cases that are just doing the work. What do you think about that?

Speaker A: I think a lot of times we are uh, jumping into solution before we really understand the problem. Is the thing I probably have a suspicion there against and the thing I get from doing it more incrementally is I learn, right? Because the, the interesting bits about designing things when you start the application is like that's the worst time to design. Because this is when you start writing a software for a new problem. This is where you know the least about the problem and you as you developing solution for it, as you talk to people and kind of start to solve their problem problem, you start developing the solution space in parallel with this problem space, right? And understanding like I see so many people skipping that stuff that is just kind of crazy. Like they just solve their own problem entirely and they're like, why don't we have happy customers? Um, yeah, I wonder why. So uh, this is where I'm like, I think I get a lot of knowledge about that and I think this is where AI actually can help you so much more. Because things I've been doing with it is interestingly with AI you can start exploring the solution and problem space together without building a single line of code. Because the agent actually is kind of a stand in for code. You can put it, we're not talking about anything reliable. Let's just pretend that we were trying to write a system and we don't know much. So we're trying to kind of replicate it and instead of code we're going to use it an agent and we're going to give it files and instructions and in and out will be files you can prototype and learn so much about the problem before you write code and then you can write code and the code will be better and you're going like you're shortcutting yourself. I think that's where a lot of power is. So I think the people who are speaking up front like this are um, missing a lot of learning points. But I could be wrong. I recognize I could be wrong. I think I prefer my way. But like I don't write code manually as well. Like when they say don't write code. Yeah, I mean I haven't written much code apart from funsies and like keeping myself, you know, up to date. I don't write code really. I do everything with AI. Like I do it a little bit differently maybe than they do.

Speaker B: Yeah. And that, that's, that is so interesting because yeah, I also, I said earlier, like, I'm only drawing, creating code because there is AI, otherwise it would be unlikely to create code, um, in my, in my current role. Um, and so I also haven't written any code in a long time. Um, but I still, yeah, I'm still bringing, you know, years of software engineering experience. So hopefully that means, that means something. And yeah, I think it's a, I am also skeptical of, of this. Like agents write all our code for us and we just watch. But it's working for them for right now. Yeah.

Speaker A: Ah, I'm curious to see how it goes.

Speaker B: Yeah, yeah. What happened? But I think the answer might be a year away, right?

Speaker A: There's a chance of that, yes. I would imagine the answer would come sooner because like it just, everything is at super speeds. So it depends, like, are they able to actually put the quality in and take care of the structure as they go at this crazy speed? Because I think, uh, so I talked to somebody from GitHub and uh, they were like, we see the most value, uh, people having more value in not just rushing to the answer and building things like speed. Speed is just one dimension, but you can reinvest in your own solutions in the problem space. Understanding problem space, in understanding pain points better in your structure because you can spend some time with AI, uh, refactoring and investing in your product. Building yourself tools is so much easier and more interesting to kind of know more and to be more efficient. And that is where I think the amazing, amazing power is. Like this way you can actually make a true difference.

Speaker B: You mentioned earlier that you don't think AI is going away. Um, and I think that's probably true. Um, what you. One thing I, I don't want to say I'm worried about, but one thing I can imagine happening is that AI becomes deeply entrenched in processes, perhaps vendor specific AI becomes deeply entrenched in processes and the usage increases. And at some point either token costs go up or you're just using so much more of it because they keep making it easier and easier to use. So your prices, I expect the cost that people are paying for AI companies are paying for AI will kind of necessarily go up in the next 18, 24 months. Um, I'm curious what, what your perspective is on the cost angle of this, uh, which is a very popular topic going into 2026.

Speaker A: I don't know that I'm the best person to answer this question. Uh, I think what you said makes a lot of sense because uh, as you scale use it in more places, we will need more of it. Right? There's some, I think deep SEQ showed us that maybe the assumptions we had about uh, we need a lot of money to train those good models are kind of wrong. And I see a lot of local models that are pretty decent as well. And this where you don't need as much resources really. Right. So I think that's cool. But like, I, I'm really not an expert at this. I don't want to predict something that

Speaker B: I, you're, you're not going to get into the prediction game. I love the prediction game. Um, but that is, that's totally fair. As we wrap up here, are there cases where AI is maybe not the right choice?

Speaker A: I think it's not the AI that's not the right choice. It's like how you use it. Not the right choice. Right. So like the extreme and bad example is like AI slop, right? That's like what everybody. So when people are like, oh, I write with AI, everybody. Like nobody says that nowadays even they do because like the assumption, the first assumption that people will make is like, oh, you just tell the AI to write a thing and it just, you're reading AI garbage. Right? Well, I write with AI, but I don't do it this way at all. And the process is very intensive on my part. There's a lot of work put in similar to how I write software with AI. Uh, there's a lot of like back and forth. It's crafted, but it's like minting means sort of like, you know, like. So this is where like how you use AI is more important that you use AI. I think AI can help you in many, many areas. Um, so. And I don't know that there's like I would be a bit worried about like nuclear sector using AI maybe security. So. Right. So security, security in AI is not a solved problem. Right. So with agentic AI specifically, right. When, when you put an agent like this is where I'm. I'm a bit freaking out about um, like I don't. Maybe I don't want to give my data to companies very much right now because they're putting those AI agents without being. And they're so rushed. So then don't worry about security. But I think it only takes like one big blow up and one massive issue and I'm kind of cringing waiting for that to happen because I think it will. There's a lot of dangers there. And like don't wipe code. Again same wipe code but like wipe code. You can write code stuff like it's. If you don't wipe code you might be hurting yourself. But like production, please be careful what you put in production. When you care about the software, you can't do this. So it's a balanced game. A lot of judgment. Like I see that the judgment is needed here more than ever.

Speaker B: There's such a spectrum of engineers, right. Like there are engineers who went into engineering almost because they have good judgment and wanted to apply it to that and then some who um, have lived a lot of their life as ticket takers and haven't been asked to show judgment or opinions about the product or how it works. How do you think the definition of a software engineer or software developer changes as this becomes the way that we work.

Speaker A: I think it's still a tool. Right. And these things are skills. Right. So I'm building skills around a new tool we have that has both limitations but also crazy capabilities. And we kind of need to know both. I still find myself guiding it and I don't know if we're going to be in the like I told you, I think there's two possible universes. First universe is like we actually can build a system that builds all the systems. In which case like me, ah, mentally involved is not important or I need to understand then we need to better tool to how do we make my source more powerful instead of just throwing code at a person and thinking that it's okay to be like nobody in software development world wants to be a constant pull request reviewer. It's like torture. It's not working with humans. Doing with AI slope is even less enjoyable, I can tell you that.

Speaker B: Two more questions for you. Um, first, what are kind of three things that you want senior leaders to understand about AI.

Speaker A: That's. It's hard because I have a lot, I think, but I think the biggest one is, um, so it's called AI and it has implications. We think of it as maybe it's a brain and the whole brain and so on. But I learned enough to be questioning that assumption right now. And I think it pays a lot by if you just keep your open mind and learn, um, basically learn as much as you can about AI right now. Empower yourself, make your people not make your people learn. Help your people learn. And also get good advice from people who know what this is. And this is where I see a lot of the problem is, um, they go wipe code and oh, it's amazing. It changes everything. Yeah. But if you continue the thread, you will find a lot of frustration down the path. At the end you were stuck and some people get, yeah, there's fun stories and people going all the way because the AI is like, I am helpless human. I cannot do anything. I'm going to destroy myself and delete myself from this computer. Serious. So. Right. So learn about it. And if you don't learn about it, how can you make a good decision? Right. How do you make good decisions? I think open mindedness and experimentation is what actually is needed right now. And then I think we need to start with solving the problems we have. Uh, because right now oftentimes when I go to companies that often looks like solution looking for a problem. Right. So. And the easiest way to do this is go to your people and ask, what's your pain point? Like what is the annoying village they don't like doing? Right. How can we use this there? And the answer is not always use an agent. The answer often should be let's use an agent to write software, reliable software. Because I see a lot of like, oh, everything is a nail when you have this AI hammer. Right. And that's kind of, it has issues, it has limitations. If you can make something reliable, good God, please do make it reliable. You're going to thank yourself for doing that. And then I think I would love people to stop contributing to the culture of fear around this because, because there's a lot of scary language around it. So many top, uh, executives are like, oh, we're going to replace all developers or we're going to replace this role, that role, that role over there. Well, please remember that your customers are people and the way you signal things to them is like, we don't care about people. And maybe that will not endear Them to you, to your company. So for one, even for that simple reason, and in general, you're a human too. Uh, we were joking with some developers actually. Can we write a system to replace, uh, an executive? It doesn't seem very hard, so don't dig that hole maybe for whole humanity. Um, and I think it also will help because if you want to empower your team to use AI, not scaring them around, that will go a long way. Make it safe.

Speaker B: There is a wonderful episode of the Twilight Zone, um, from the 50s and 60s where robots come to a factory and in the end they replace the leader of the factory, um, and not the, not the workers. So, uh, you know, maybe we should

Speaker A: watch it more because we are humans. Like, if we're trying to replace all humans, what's our values as humanity? I question that.

Speaker B: So, last question for you and we'll wrap up. Let's say it's two years from now. It's December 2027.

Speaker A: Are we still talking about this? Yeah, it depends. Right. So it depends. And it depends on, like, is LLM still a thing? I think it's still a thing. Um, unless we discovered something entirely different. Like that's the only case where we don't. Um, I think the patterns that I have anti patterns like I started from, what are the fundamental limitations of this thing we have. And unless we find ways to kind of actually solve them. Right. So continuously learning AI, but even continuously learning AI is interesting because it doesn't remember, uh, the details of everything it learns. It just has kind of like, oh, I read about this thing. I can look things up. And you still need this knowledge, external knowledge to guide details about things. So I think a lot of those, I was trying to build those kind of patterns and so on around the things that don't change. And maybe my solutions will be a bit different, the patterns, but I think the problem space of how we react to them, um, kind of stays roughly the same. At least I'm pretty confident about 2026. I try to not predict things, but I think we're fine for 2026. I think probably it's relevant. We probably learned a lot by 2027, because I learned a lot in a month currently. But I think it will still be relevant.

Speaker B: I think relevant. And I have no idea what it's going to look like.

Speaker A: Um, exactly.

Speaker B: Relevance is going to look like. We will. We shall see.

Speaker A: Yeah.

Speaker B: Um, well, lot of. Thank you. Like, what a great conversation. Um, I really love hearing about, like, the realities of somebody who's not just using this, but, like, really exploring it and thinking about the implications. So, um, I will. The talk in the show or the. Your video in the show notes and some other good stuff. Stuff in the show notes. So check them out. Um, there will be. There will be good goodies in there. Thanks so much.

Speaker A: Yeah, thanks for having me. I really love the conversation, too. I appreciate it.

Speaker B: Excellent. Well, that's the show. Engineering Unblocked is brought to you by Swarmia, the engineering intelligence platform that's trusted by some of the best software companies in the world. Thanks for listening. See you next time.