Jimmy Bogard: AI-Driven Development - Episode 414

Speaker A: AI uh driven development with Jimmy Bogard.

Speaker B: The AI DevOps podcast is a show for those shipping software using AI Net, Azure and DevOps. Each show brings you hard hitting interviews with industry experts, innovating better methods and sharing success stories. Sponsoring the podcast is ClearMeasure, a software architecture and engineering firm that implements AI to empower software teams to establish quality, achieve stability and increase speed. And now your host, Jeffrey Palermo.

Speaker A: Welcome to the show. I'm Jeffrey Palermo, your host for helping you and your teams move fast and deliver quality and to run your software with confidence in Azure, all while using everything that AI and Azure and the. NET ecosystem has to offer. I have a five uh, time return guest on the show, Jimmy Bogard, and he really is a true heavyweight in the Net open source world and someone whose work has kind of quietly but profoundly shaped the way that a lot of developers build software. He's a creator and maintainer of the two very popular libraries automapper and Mediator. And if uh, you've ever tried to simplify object mapping or decouple application logic, chances are you've probably uh, used his libraries. He is based in Austin, Texas and he's an independent software consultant and a 15 year plus recipient of the Microsoft Most Valuable Professional Award. Uh, and uh, Automapper, uh, specifically has been around for what, 17 plus years. He's got hundreds of m, millions of downloads. Um, and, and we're gonna, we're gonna talk about that and more. So Jimmy, welcome back to the show. How are you sir?

Speaker C: Doing good. Thanks for having me back on, I guess.

Speaker A: Yeah, yeah, again.

Speaker C: Again. Again.

Speaker A: Yeah, again, again, again. I love it, love it. And we'll include a link to the past episodes in the show. Notes for the listeners who are just getting to know you for the first time. Um, so for the listeners who haven't heard you speak or getting to know you for the first time, uh, if you could kind of go back in your memory and think what was it and what does it continue to be that is interesting about making computers do interesting things that kind of keeps you engaged and passionate about this field all these years?

Speaker C: Yeah, I think I probably have what a lot of folks in this industry have, which is that I got enjoy that dopamine rush of ask the computer to do something and then it does it. And that's like oh, I got something to do, something that I asked it to do. Um, so I don't know if that, that part will ever get old. It's just, it's, it's always been something that I'VE I've always enjoyed with programming so I don't see that really ever, ever going away. It's still, I still have that same rush I always had.

Speaker A: Yeah, yeah, it is fun. It is fun. Well, I want to, I want to ask you about, uh, just catching me up on, on how your brain is processing, uh, AI driven development over the last year. Since the tools have just really. We're in a whole different world than we were a year ago. But before that, I want you to give us a quick update on Mediator, uh, and Automapper. And you're operating the commercial product company now instead of just open source maintainer. Um, and just kind of give us an update on that now that we're uh, what, over a year?

Speaker C: Yeah, we just passed a year. Um, I officially launched commercially like July 1st or 2nd of last year. So yeah, we've now uh, gone over 12 months of business. Um, and so far it's been, it's been great. It's been really rewarding. Um, I've gotten to do things I've not ever had to do before or ever been exposed to. Like I've never run a software company before. So it's a lot of new experiences just knowing how to do that kind of business. Um, I've been in consulting forever. I mean, gosh, like 17, 18 years, something like that now, uh, and very familiar with that business, but not at all with like licensing, uh, software, the whole business aspect of that. So just that has been really fun and interesting of m doing something new, um, and different than all the consulting stuff I was exclusively doing before.

Speaker A: Yeah, yeah. Cool, cool. Um, so, uh, I don't know if you know how many people out there are using uh, the last open source version versus have kind of upgraded to the new commercial version. You have any, any data on that or is that like. No, you can't even tell because of

Speaker C: how Nuget you can kind of. I mean so you do get like raw numbers out of them, do get like just X number of downloads and then you get some information on the versions but it's still a bit limited and it's, it's time windowed so you can't see, you know, forever history. Um, so I still see plenty of downloads of um, the older versions and I kind of expect that to continue. But in terms of understanding like how many folks have decided to upgr whether they pay or not, that's just like Microsoft definitely knows. I'm sure they could. Well, I'm sure they've got numbers to figure that Out. But that's not something that of course they share with anybody else. Um, so they would probably know. But like, I just see, you know, one giant number on NuGet and then I see what people have actually signed up. So that's been another really fun thing of this whole experience is I get to actually see who is using the stuff I've made over the years. Like with consulting, I knew exactly, you know, the customer that paid for it, I know they use it. But with open source you only really just get that sort of download count, but you don't really know who's actually using it. So that's been another really rewarding part of this is just seeing like all the, all these people that had no idea. Um, you know, I knew people used it, but who. No idea. It's just really cool to see, like with consulting you have a direct connection to the missions that you're, you know, furthering and advancing. But with like, just libraries people download, you don't know. So getting that connection has been also super rewarding as well.

Speaker A: Yeah.

Speaker C: So how many? No idea.

Speaker A: Sure, sure. Well, so I, I enjoy that, uh, you're kind of keeping the, keeping the code out in the open, even though the license has changed, you know, it's still, it's still an open, open git repository where the code can be browsed and whatnot. And, and so I threw, I threw Claude at the repository just to see that, okay, the beginning of 26, the number of commits, you know, you had, you had like a spike. And so what was curious for me was, okay, we're into this AI age now where we can kind of go. It seems like we can go at the speed that we can think, you know, pending token budgets and all that. And of course, when, when AI outpaces my capacity to think about the structure of the software, that's where you get into AI slop territory. And it's like, throw that branch away. But so I want to ask, uh, with that transition, how, uh, has that changed your attitude and pace just with software development and what's different from a year ago in your world?

Speaker C: Yeah, so one of the things I found is that all those skills that we worked on so much in consulting of being able to describe the software that we want, you know, we'd always make, you know, good JIRA tickets or whatever, uh, it was. We try to be fairly descriptive and do quite a bit of research into those to like, make sure we're building the right software. We also want to make sure we're building the Software. Right. Which is another thing. But we want to make sure that we're building the software that the end user expects like this is what they want and to do. So we had found that you know, going through user stories and really collaborating uh, on those first so describing what we think we want wanted was valuable time because it had those, you know, brought those conversations as well. So when I am building those instructions for an agent, it's not that different than what I was doing before in terms of building out user stories that describe what we want to do. You know, sometimes we put in hints for implementation details. Those would be for the developers. Right. We had technical notes, whatever. Like that hasn't changed. Um, and neither has changed of however, you know, however good your user story description is, then how good the software comes out on the other side that also has not changed. M. So if I give bad requirements to a junior developer, I can't really expect greater results on the other side. Like it's just garbage and garbage out. So really that has not changed at all with um, agentic based development. It's like you give it garbage, it'll come out garbage on the other side. Minus you know, they are getting what I've seen especially last six months better about like remembering conversations and being able to remember things in the first place and then offering design feedback as well. So it does feel much more like having a conversation with a uh, developer these days versus just pure, you know, garbage in, garbage outs. But still all that like it doesn't remove the need to think about what I want to have built and how to, how it should be designed. Has still not removed that. It's just kind of shortened the time to get that immediate feedback.

Speaker A: Yeah, yeah.

Speaker C: Of is this, you know, is this gonna work or not? Yeah.

Speaker A: So to get kind of really tactical, um, just let's say just over the last four or five months how many lines, how many lines of code do you find yourself hand typing or even you know, resharpering. Tabbing. Tabbing versus just monitoring as a prompt produces it.

Speaker C: Oh I gotta say it's like 95% agent based. Um because still the software I'm mainly I think you can look at this in any kind of enterprise software application. 95% of it is not that interesting. You know, it's like fairly straightforward stuff. You know, um, I find myself working on trying to give the agents more context, better context, gibbets, um, more sources for information, um, more what is it called the MCP servers. Although those are limited value but being like oh yeah, Someone has an MCP server for this tool I use. Instead of you guessing based on the API, just plug that thing in so it just works better. I find my time better spent on things like that and then also thinking about what I want to build and designing it versus like the hands on keyboard um, for that 5% where it is complicated uh, or at least I don't know which direction I want to go and I just still want to play around with different options. Then that's when I'll kind of go down for the exploratory just kind of like um, exploratory refactoring sort of sessions. But then otherwise my time's just better spent telling this thing to work in the background and then coming back and reviewing the results.

Speaker A: Yeah, yeah. What does your developer workstation look like these days that your, your tool stack that you find yourself gravitating to?

Speaker C: Well, I'm still, still Mac os. I know I've got friends that have, have not just moved off of um they've gotten really into agentic development. Um they're looking at ways of running, running uh the agents uh locally running the LLMs locally. So they're like looking at getting Mac pros or I don't know that I wait for them to figure it out. Like I'm not an early, early adopter to Mike that like you, if it requires buying the hardware like you figure it out first, I'll come back later. Um, but I still do enough like I still consult so I still need like a laptop so I don't see myself going to like having local GPUs or whatever for a while until you know just becomes, if it ever becomes like painfully obvious that that's a better way to work then I'll move over but otherwise um. Yeah so locally it's you know I do runs uh an agent server locally just for local LLMs and then otherwise I still am mainly in IDE. So I still have not like just gone completely over to VS code. I still find Jetbrains writer to be. Yeah I just, it seems to be better um in terms of just the developer experience than just pure VS code. Then pass that. Um, I still haven't nailed it down so I'm mainly on still um cloud based subscriptions so codecs and that sort of stuff. I do have chatgpt like still as a thing but I mainly moved over to Claude for every uh, all the agentic work I do. But again that's one of those like um, views to make fun of like new JavaScript framework coming out every three months or every three weeks? Every three days, whatever. Noun JS I feel the same way about, you know, some AI models. I'm like, are you using the new Fable or this or that? I'm like, uh, I don't know. If it shows up and it says used, I'm like, okay, I'll use it.

Speaker A: Is it just me?

Speaker C: Whatever.

Speaker A: Does Anthropic seem to be dominating the LLM choices at the moment? Like you mentioned Claude. So you're using the Anthropic models and it's just.

Speaker C: Yeah.

Speaker A: Do I want, do I want Fable, Opus, Sonnet or Haiku for what I'm doing right now?

Speaker C: Right, yeah, yeah, exactly. Yeah. I don't really know the difference other than the uh, you know, that the cost they give me. I just haven't. It's one of those things like kind of waiting for the dust to settle about who's going to quote, win this before I rest a ton of time like trying out these different things. I'm like, I just, I just have stuff I need to build. I don't, you know, I don't need to go on a, you know, 10 day, let's compare all the options because it's just going to change anyway. The new model comes out, it gets improved and then whatever decision you made before may be gone already.

Speaker A: Right. Right. Okay, so you're on, you're on Jetbrains rider and you're using the Claude stack mostly. Um, is your, Are you looking for best of breed tools regardless of price or are you drawn to Claude because they're subsidizing more than any of the other vendors at the moment?

Speaker C: Um, they're definitely subsidizing more than the other vendors and I think as well, I'm on one of the plans that they're not letting people sign up anymore on. So I'm like, I got to figure that out as well. Um, but yeah, I tried a lot of different coding ones. Like I tried them, you know, Microsoft's one, our GitHub copilot. Um, and I still found that the anthropic ones still tended to produce the best results. I even looked at, um, because I also have, you know, when you're solo developer, I still want to have other something else review my code. So I used to use Copilot to review everything but I found there was a lot just the quality just wasn't as good. But um, these days now I use uh, codecs as well. So Codex will review, Anthropic will review um, pull requests, and then I always do the last spot check. This is really no different than I was doing as a tech lead. Right. You've got. You need a peer review, and then you want someone else to give that sort of outside eyes, um, whatever. So I'm still doing that. It just so happens the peer review is like, also LLM.

Speaker A: Yeah.

Speaker C: Um, but again, those results have gotten better and better and better crazily, like where they're, you know, my local agent is arguing with Kodak's pull request review back and forth, and they'll come back, hey, you need to make a decision. Like, okay, what are you arguing about? Like, oh, okay, okay, well, you need to go this direction then.

Speaker A: Yeah, yeah. Well, let me ask you about that, because you mentioned 90 and 95% code AI generated. Um, and quite a few of my other guests are kind of in that. In that realm as well. Seems like a massive industry shift. Uh, and so with that, you've got code that you didn't write, a peer on the project team didn't write. So you've got it generated by a computer. And you've got to figure out, is this slop or is this good? Do I like it? What is my definition of good? And so how have you found yourself, uh, wrestling with that process question? And what, what have you figured out and what do you still think is in the camp of, uh, yeah, as an industry, we're, we're still trying to figure out that piece.

Speaker C: So I don't think any of the, any of the normal sort of, um, idioms or adages that we had kind of cut our teeth on. I don't think any of those had really changed. So I'm still looking at. I still want to minimize the amount of code I have to write to get something done for a customer. Um, any extra line of code is something that could cause bugs, could be something that then we have to support in the future. So I don't see that as changing. Yes, the agents can do it. They could do it more quickly or at least more asynchronously. I found it's not necessarily quicker, but it's certainly quicker for me because I can do other things, things while that thing's turning in the background. Um, so that sort of stuff hasn't changed. I still see that I need the same quality gates as I had before. So I still have unit tests. I still have those integration tests as well. That still hasn't changed. And the work I used to do as a tech lead, which was more the introspective after you get, I don't know, six to eight weeks of a, uh, project under your belt, there's a point in time where you do this, take a step back, look at to see what patterns are emerging or what complexities have arisen. Um, that's something that I will look at or pay very close attention to with what the pull requests are coming up of. Like, oh, it's changed this thing six times. So maybe this needs to be encapsulated in a concept. Those are things that the junior developers wouldn't necessarily come up on their own, nor do the LLMs come up on their own. So my activities as a tech lead architect are still the same as they were before. Like those are all still needed. It just so happens that I don't have to have myself doing all that work every single time. But like bad, you know, bad, uh, difficult, uh, to maintain code is still difficult to maintain for an LLM. Like it will still have a difficult time reasoning about a code base if the code base is complicated. So you still behooves yourselves to keep things simple, if nothing else, to make the job of AI and ourselves easier when trying to maintain this code base.

Speaker A: Yeah, yeah. So, um, I find myself looking at the organizations or people that try to study and do surveys and gather some type of data. Uh, and the Get Clear organization has put up some numbers they call the maintainability gap. And it's 20, 26. So it's just in the last six. And, and they, they kind of reported that, that uh, refactoring lines of code change is down 70% in this current six months and duplication is up 81% industry wide. And so you mentioned, you know, six weeks, look refactor and see what patterns and whatnot. And so uh, one. Does that surprise you? What do you think about that? And how do you, how do you approach just the, uh, making sure that your code bases in your projects aren't accidentally just duplicating all over the place?

Speaker C: Well, that's a tricky one. So I would also want to pair that those activities against, um, some quality metrics. So is cyclomatic complexity going up? Is coupling going up? If those stayed low, but the other numbers went, you know, the other numbers went up, then I would say, well, it's not as important. Like to me the coupling, the maintainability, those are the most important metrics. The other ones are, those are like, those help indicates those are indicators. But I'm still looking at, you know, what is the quality of the code base over Time, it's not something, honestly I measure a lot in the code bases. It's usually got one off. Okay, we, we have a code base that is hard to change and you run them, you know, you run independent and you're like, well there's your problem. You've got this one method that is super hard, super complex and it's the most important thing going on in your system. So that's why it's hard to maintain. Um, so I, those are still the more, more important numbers to me than just pure the activities. Um, because you could say, you know, now that you don't have another human reviewing every single line of code, they're less likely to just introduce refactorings for their opinion versus if they actually improved the bottom line. Um, it's like, I don't know. I'm sure you've been in client meetings as well where if you ask the group their opinion, everyone feels obligated to tell you their opinion, whether it's actually valuable or not. So I definitely do see that times with peer based code reviews is that someone feels like uh, they need to say something or it's not their personal preference, when that doesn't really matter in the long run. So if it's down with those kinds of refactorings, then to me that's good. If it's just refactoring because it's your preference and it's not objectively improving the code base and that could be seen as a good thing and adding value. Otherwise, um, I'd say, you know, give it another year and come back to see those quality numbers, to see, you know, how, how have those changed over time. Has velocity increased or decreased over time due to bad quality code?

Speaker A: Yeah, yeah. So there's a, there's a big, there's a, it's not really an argument, it's just two different ways to look at it. Uh, I, I tend to look at a code base and tend to favor splitting out projects and assemblies by major, uh, libraries and major layers in a code base. And I think that you tend to favor like vertical slice in, in a lot of cases. Uh, and, and so I come to the thought of a skyscraper. If a skyscraper is a software system, how a particular floor is configured with an open floor plan versus individual offices, that's one thing. But deciding how many elevator shafts and where they are and the fire escapes and where we're going to run the fire suppression sprinkler pipes up and down. Like if a floor messes that up. Well now the architecture of the building is compromised versus one floor happened to be uh, maybe completely different configured than another floor. And I uh, think that could apply to software. And if naming things and the abstractions and where certain code is was so much for us to understand it and get a picture in our head. But then the question is, okay, what's the structural part of the architecture? Have you wrestled with that and what do you think you think on that?

Speaker C: Um, so I still think that software these days is uh, easier to change than it ever was before. So I still like this idea of optimizing for change versus um, necessarily solidifying a specific way of doing something. Um, so that's one of the reasons I like the slice based architecture is it allows individual features to deviate from the others. If the needs arise, the complexity needs arise. But I also recognize like we need to be able to give large teams instructions on how to build software in a consistent manner. So one of the things I found that these tools, these LLMB based tools allow you to do is we can put those kinds of opinions down into our agents, uh, our agents files so that the entire team can be consistent. So in terms of like where my headspace is more like I don't care. But I sure do hope that these tools help make it easier to enforce an architecture because one of the things I absolutely hate is I know you've seen this as well a lot. You come on a new project, the code base is 10 years old and you can tell there's been four different tech leads because each one has come in and then offered their own, you know, um, brilliant ideas and opinions on the code base. And now you've got a fractured, you know, fractured code base with not a consistent way of doing things. So I, I'm always of the opinion like you know, we can get into philosophical arguments all day long. The reality is like any approach that is out there, as long as you're consistent is probably going to produce a good result. It's the inconsistency in architecture I see that um, kind of can kill these long term projects because every time a new developer comes on board they're like, which is the right way of doing things. And at some point you just kind of give up. You're like, well now there's six different ways of doing things. How about another one? What's one more new way of doing things? So I'm really hoping these tools can really help enforce that consistency so that the team is less worried about these arguments and just focus on like, who cares? This is what we decided. Unless it's there's some, you know, glaring problem in our velocity. Let's just be consistent. That's more important to me.

Speaker A: Well, let's dive into architecture then. You said to uh, enforce the architecture. So we've kind of had manual and non standardized ways. And before 2020, uh, and before the you know, everybody's remote for everything kind of era, there was the concept of people m stood around a whiteboard and drew some pictures and drew some lines and boxes and, or got on Vizio or some other drawing tool. It's like okay, we have a drawing, we all agree this is the desired shape and okay, so how do we in well one, how do we record and communicate and enforce architecture in the era of AI driven development?

Speaker C: Um, I think at the application level that is certainly more feasible than it has been in the past. Um, enforcement's always still tricky though because there's still not been a project I've been on where we've had like a ironclad expectation of what the architecture should be. And then like a month later a developer's like well what about this case? And like ah, dang it, there's always that edge case. Like I want uh, with any of these kinds of approaches I still want a safety valve of like I need to be able to get an escape hatch and, and, and get off that. As long as there's you know, a good quote, good reason to do so. Um, and as long as the, that's the expectation we're all good. Um, otherwise I, I still like this idea of using these um, LLM based tools to help help enforce it at the creation time. Um, it's enforcing it later that that becomes a lot trickier I think. I mean we've tried that with things like dependency rules or not like um, code quality CodeQL rules or uh, independent rules. And those can work. But then there's always that okay, if it's enforced but there's a, a um, there's an, there's an um, there's some uh, specific use case where that doesn't fit. We uh, need to have an exclusion for the rule. Then I want to make sure that it's not too difficult for us in those tools to be able to say okay, for this specific use case we want to go against the policy because of blah blah blah blah. Um, it's when I find that those tools become too heavy handed then they become abandoned altogether as opposed to like well I need to be able to bend the rules when it's Required and just recognize these are you know, 99% guidelines over here. But then I need to have an escape hatch over there.

Speaker A: Well, when it comes to just even communicating, getting on the same page with other people on the project team, um, what, what is your current method for communicating the architecture? Do you draw diagrams? Do you generate them? Do you just list it out in bullets? What do you find yourself?

Speaker C: Oh yeah, I still, I mean any kind of online collaboration tool, um, whether it's something like Draw IO or um. Miro. Miro. I don't know how to say pronounce it but those kind of like on um, you know, I'll just completely online SaaS based collaboration tools where people can collaborate in real time on those things. I still spend most of my time in those trying out different designs, whatever. Um, sometimes I may go to some other tool that then like pasted into this thing but it really is those online collaboration tools. Um, and then what I like to do as well is I still like to have a conversation with folks. So that'll be. The diagrams are more of a anchor point for conversation and then we get on a zoom teams, you know, whatever people are using at the company and then didn't have a discussion about. Okay, let's at least have a strawman argument that we're beating up here that we can all um, talk to. So yeah, I still do that. I've not gone full. I mean I know folks that have tried to do like end to end AI sort of development but it becomes a game of telephone where if you try to have a meeting with the customer then they transcript the thing and then you try to put the transcript to create requirements documents and use something to then create tickets. Like every single transition is going to be lossy and there's going to be translation errors. So. Well, I still prefer to have a summary and then I can then guide the creation of the next step, uh, whatever the next step might be. But um, I still see people involved in that process but just not having these like really big expensive meetings or um, collaboration sessions, you know, days of collaboration sessions. Those are to me as necessary as they were before because we can get these tools to kind of get, gather all the information and then we're just really like at the, we're talking about the um, solution phase versus like just doing discovery together.

Speaker A: Yeah, yeah. Well, going back in time there's been some transitions that have really changed how we build, test, package, deploy and then operate and support software. Um, from the smartphone where computers in your pocket to everything's on the cloud versus in data centers and now not just cloud but with just snap your fingers and you got a Kubernetes cluster or you got a PaaS service and you just here run my code. Uh, so you know, purely elastic infrastructure and then the open telemetry standard. So what things in your opinion either already have changed or need to change about the whole DevOps and infrastructure layer just to get the most advantage or fit with AI driven development?

Speaker C: I mean, uh, me personally, I still would love to just point a subscription at something and it can tell me like where I'm wasting, wasting my money. I still feel like I have to pay someone to tell me like where, where is all those? You know, I see some bill at the end of the month, like where's this, all this going? Actually not going to. I can only imagine what largest enterprises have to have to do with that. Um, so I don't know. The. I still haven't found the tools have been super great about, about getting the dollar amount for solutions as part of, you know, me designing a system of like, I love customers. Like, oh, we want to do this versus this. It could be I want to do um, app services versus container instances versus Kubernetes and just trying to ignore, um, the operation side of it that needing people to know how to do all these things. I would love to be able to quickly get through designs and like, okay, what's the actual monthly spend going to be on, um, this thing we've dreamt up ourselves? I don't know, I haven't seen that quite there yet. It's still a lot of work for me to go like, okay, let's go figure out what the operational costs are going to be for whatever we just dreamed up here. Oh, too much. Okay, back to the drawing board. Let's try again.

Speaker A: Right, well, okay, I think you can. So we've maybe stumbled upon a technique that worked in Azure. Uh, one particular. It was a move to Azure and we kind of sketched out all the different things that had to deploy. And so it's probably six different prompts and it. And one of them was all right, do this and do this in the same frameworks that they're using everything, everything.net eight and then one Angular website and then some other things like eight or ten different things that had to be deployed. And so give me a git repository with these things. These things and give me a skeleton of a system with these technologies and these number of things. Boop, done. And then create the pipeline soup to nuts and then here's a brand new Azure subscription with a token so couldn't trash anything real. And so full access to a brand new Sandbox Azure subscription. And I want to use region A, Region B. Here's the features I want within the region of uh, fault tolerance. I want hot site auto region failover, west coast, east coast. And then I want uh, you know, if this fails, doesn't want to if this fails. And I want, I want to test three different deployment scenarios. One is uh, no more than a 60 second maintenance window. Second is manual, manual deploy like swaps and then third is zero downtime and the different configurations support and just let it run and I think in a few tweaks and within a two hour span of time there was a complete Azure multi failover scenario. All the environments, I mean all the services layered, I mean subnet firewall, everything that it was necessary. It's just go create what's necessary and then throw some traffic at that nothing of a website. Then do a deployment, make sure there was zero downtime, zero dropped requests. It, it was splendid. And so I think, I think that you know, prototyping at the infrastructure level level is here.

Speaker C: So that's, yeah, that's something that I haven't had to do in about a year and a half. So that would make sense that it's, it's changed a bit since then because it's just something you know usually um, we do it once on a project for a customer and then I don't have to think about it for another, you know, nine months. Yeah, yeah. Ah, nobody touches. We've got it, we've got it working there. Um, but yeah, I still see uh, it's now much easier to get those kinds of things up and going now that it would be before like oh great, this XYZ has an API. Great. But do they have an SDK? Oh, they don't have an SDK. Well then um, I'm hosed versus like actually now the LLM can build the SDK from that so you don't need to have that sort of thing. So I was like well as long as people have APIs for stuff it's that same thing again. Like if you have an API for it then it can be automated and now it's now even easier to automate uh, those kinds of things. Now we've got an LLM like just generating that automation for us. I still don't fully understand PowerShell, but I don't think I really need to anymore. I think it can just generate the PowerShell I need. And then I'm like, okay, it works. Uh, I don't need to go back and figure out what the heck is doing.

Speaker A: So that's a big idea. Okay, you just said I'm comfortable not intimately knowing powershell. I, I know, I know it at a good enough level where I know kind of generally what's happening under the covers and that it's there. So, so now as we kind of get to get to the end, you know, you've, you had a very successful career already and you're, I mean, uh, you're, I would say you're at the, you're the top of your game. And so for the young software engineers, whether some people are like, well, I'm getting to shoot, everything changed from when I decided to, to start a university program or whatnot. And now, uh, the big companies have laid off a bunch of people saying that they replaced him with AI. And then I don't know what to believe. And so should I continue to pursue, am I going to have a career? And now you're saying I don't need to know it. So what do they not need to know? Some of the things that you and I spent a lot of time getting good at over the last couple decades. So if you're, uh, coaching really young person, what do they not need to know that we kind of got really good at?

Speaker C: Oh, gosh. I mean, they may not need to know all the keyboard shortcuts of the ides. I don't know if that's strictly necessary anymore. Um, but I don't know. I still see that all the skills I worked on to get to my point in my career now are still serving me going forward. So that's, um, even just all the sort of basic programming stuff, I still need to understand what these things are generating if I don't necessarily have to type it all myself. Because if ultimately something goes wrong with the application I'm building for a customer, I can't blame the AI. Um, the customer's not going to accept that. Like, no, you're responsible for the software. So I still feel like that's all necessary to understand all these different things. Um, I don't feel anymore though, that I need to become the experts, uh, at everything to have a. To be successful. So, like, you know, at one point I was designing websites and I felt like I had to be the expert at CSS in order to do anything. But these days, like, you know, I can get. There's plenty of good enough solutions out there. That you don't need to try to become the expert. There's enough for me to understand, you know, uh, to know how to steer the AI in the right direction. But I don't feel like I have to be that, you know, that expert on every single solution. It's just to, to know enough to know when it's on the wrong track. We can't just cede all control to these because they just won't know when they're going in the wrong direction. I've just seen that over and over again. They're very confident, um, in their answers, uh, and that just may be hallucinating. So it's up to us to know enough to know when it's on the wrong track or not.

Speaker A: Yeah, yeah. It's almost like, uh, the definition of good has to come from outside the context window because there's no awareness of what good is.

Speaker C: No, no, exactly.

Speaker A: Okay. Well, good. Well, good. Um, yeah. Uh, I don't think we've seen the end of the change. Like, we look on the past year and like, a lot's changed and I'm thinking, no, I think it's just started to change and we'll find out.

Speaker C: Yeah, it could be that there's just going to be a wider gulf between. Because what I keep seeing again and again is that senior developers that understand the technology underneath the covers can go faster with these tools. But I haven't seen the same thing for junior folks that they don't know when it's on the wrong direction. And so they'll submit, um, pull requests that are complicated, completely the wrong thing. So I'm like, well, that just wasted time that didn't, that didn't make things go faster at all. So I still feel like, um, it could be the case where you'll see a gulf in skills that, for folks that don't have the context aren't actually going any faster, but the folks that do have that context can go much faster. Um, so that's kind of what I've just personally seen so far in terms of how that translates for, uh, folks new to the industry. Then, I don't know. Um, we'll see, like, you know, what happens when the subsidies run out. Are these companies going to be around? Um, I'm guessing they will be. What the cost is going to be, who knows? But, um, for me, like, I'm just going to ride this while it's still cheap and, uh, build cool software until, uh, we just see what happens on the other side. I don't know.

Speaker A: Yeah. Yeah, well, I mean there was a time, there was a time where we were paying real money for every text message and every call to a different city with long distance fees. So the question is how long, how long before this becomes a utility instead of pay per usage?

Speaker C: We also saw like, I don't know, we've been in the industry long enough, we've seen other tools not nearly as powerful as LLMs come into the industry. Like for me the first thing was like rapid application development. I was like, was this going to kill developer jobs? Like, well, no. Was SharePoint going to kill jobs? Like, no, just makes more of it. Like the pie got bigger. That's it.

Speaker A: And now more people can, more people can make software and yeah, if they make software where they're the user, like user of one, great, fantastic.

Speaker C: And then were they going to do. Yeah, exactly. So those folks before may have just been stuck with some tool that did exactly what the tool vendor expected it to. So yeah, I know to me just it's, it's making the pie bigger. Um, but in terms of uh, you know, folks new to the industry, I don't think you're doing any self any favors by just strictly relying on the tool because there is an expectation that you're responsible for the code that comes out of it. We can't just point the finger at a Claude and say, you know, it hallucinated again like, well, so customer doesn't care. End user doesn't care.

Speaker A: Yeah. Yeah. Awesome. Well, Jimmy, thanks. Thanks so much for coming back on the podcast. This is a great, a, uh, great update. I appreciate it.

Speaker C: Yeah, thanks for having me. I appreciate it.

Speaker A: My pleasure, My pleasure. And until next time, dear listener, keep shipping.

Speaker B: You've been listening to the AI DevOps podcast. You can find us on YouTube, Apple Podcasts, Google Play and everywhere else. Visit our sponsor, ClearMeasure, ah@clearmeasure.com and on behalf of your host, Jeffrey Palermo, thanks for listening and may God bless you.