The End of Untouchable Software

0:00Brian Feldt: While these tools are incredibly powerful and they can go and read code bases and answer a lot of questions and move you along a lot faster, they are not perfect, as we'd say over and over. You know, AI is not perfect in what it does. It makes assumptions. It hallucinates. Things can happen that are not going to give you what you need. If you're talking about a critical system and don't expect that you're just be able to get AI to go tell you what the old system did and then just say, OK, write me a new one. And that's going to work in any sense of the word. It's not.

0:31Nate McKie: AI is getting remarkably good at writing software. And for enterprise leaders, that raises a possibility. Finally updating the aging systems that run their businesses. Projects long considered too expensive or too risky to tackle. But buried in that old code are decades of business decisions. a customer promise, a compliance requirement, a safeguard against paying someone twice. So before you replace that software, you also need to know what you need to preserve and how do you prove the replacement actually works. On today's show, we're talking with Nate Mackey, Senior Practice Director of AI Native Engineering and Senior Executive AI Advisor here at WWT about what AI makes possible in software modernization and the hard work that remains even as the tools get better.

1:14Nate McKie: This is the AI Proving Ground podcast from Worldwide Technology.

1:18Brian Feldt: Let's jump in.

1:27Nate McKie: Hey, Mackie, welcome back to the show. How are you? I'm doing great. I'm doing great. It's a crazy world out there. Absolutely. I mean, since the last time we spoke, I mean, pretty much nothing has happened on the AI landscape, right?

1:37Brian Feldt: Just saying the same stuff over and over, and that's pretty boring. Yeah, no, I mean, well, quite the opposite, actually.

1:43Nate McKie: There's been a ton of advancements, seemingly on a daily basis, for sure, weekly basis. I do want to ask you real quick, just to kind of set the table here as we get into more of the legacy modernization, the tools that we're all dealing with, whether it's coding platforms or just general chatbots, I mean, they're getting so advanced, but you still see pockets around or reports about, you know, transformation or ROI being a little bit elusive. From where you're standing right now or maybe what you're seeing with customers, what is still not possible with AI or where are we kind of struggling?

2:16Brian Feldt: Well, what's interesting is that it is incredibly useful in certain kinds of jobs. Anything that is generating text content, right? It's still the case that that's what's leading before anything else. So that's why obviously marketing and all of that is benefiting tremendously. But then software development is. But not every aspect of the software development process is about creating code or creating text. And so just because you take one thing that was probably the long pole in your tent before and you make it really fast doesn't make your entire process fast. Right. And while you can apply AI to those other areas, not everybody has kind of picked up on the fact that they need to do that and that they may need to change the way that they're thinking about things.

3:07Brian Feldt: It also really amplifies any existing issues that you had where you might have been able to get away with long decision cycles or slow requirements gathering or slow deployments because some of that could happen while the coding was going on. now the coders are done same day and you're realizing, oh, wow, this backlog is really filling up. And all these things, we had this two-week-long review process that we always used and was totally fine before, and now it's slowing everything down. So you're going back to basics on a lot of things anyway, just fixing stuff that should have been fixed before, but you were getting away with it because of how long the actual coding process took.

3:49Brian Feldt: So from a coding perspective, I think that's still what's going on. For everybody else, well, we could talk for a while about that. But ultimately, it's more about changing the way you think about your job and your work and what you can hand over to AI has always been the issue, and it still continues to be a little bit of a problem.

4:09Nate McKie: Well, let's stay within the coding community here. I mean, what areas, you know, you mentioned in your answer, there's still areas that we're not necessarily automatically thinking about. Anything in particular that you think's of, you know, that would resonate with our audience?

4:21Brian Feldt: Yeah. Deployment, you know, is I think is probably the first place we start when we're working with customers that where they're saying, Hey, we bought the tools and we're not really getting anywhere. It's have you really looked at your entire deployment process? And that includes things like, you know, code review and security review and testing and like all the things that you would have done. Have you gone through the process of really automating what you can and putting humans on everything else in the best way that's going to allow you to get this stuff through the door. But if you're piling up all this finished code and features and you're not able to get it to production, what's the problem there?

5:02Brian Feldt: Is it reviews and decisions? Does somebody higher up need to look at everything and say yes or press a button and it just takes forever to get their time? Or is it that you haven't put enough automation in place to make sure that if you put this in production that you can roll it back out quickly. Are you more careful about that? Is it more manual? Those kinds of things tend to be blockers for this sort of thing. Or just is the culture of your organization resistant to getting regular updates of your software or your platform or whatever tools people are using? If people just start freaking out if things change too much, you know, maybe you're slowing it down on purpose and you're just not seeing the benefit from that perspective.

5:47Nate McKie: Yeah. And as it relates to, you know, updating and modernizing the software that every enterprise is using, can you just set the table for us for those that maybe, you know, aren't, you know, following necessarily one-to-one, what applications or what software are we talking about modernizing and why is that important and why is it now different with the advancements of AI?

6:06Brian Feldt: Okay. Yeah. So every organization has got legacy software that's generally running somewhere is probably incredibly critical to their business because it's probably one of the first things that they wrote. And the larger the organization is and the longer it's been around, the more this is the case. So everything from we've got this incredibly important module that does a critical calculation for us that's on mainframes. And it's just always been there. All the people who wrote it in the first place or know how it works are gone. And it works fine. It's costing us a lot of money. But when we even think about trying to replace it, we go and we ask our experts, how do you replace this?

6:51Brian Feldt: And they say, well, we need a year just to even look into this and figure it out. And then we'll tell you how much it'll cost. And at that point, everybody's like, well, no, I'm not paying for it. I don't even know what that check is. I can't even write it. So that's been the case since we started writing software, where software becomes legacy the minute someone who was critical to it leaves or the tech stack that it's on changes dramatically, right? And then suddenly it becomes from an enabler in your organization to an anchor. Well, what's changed about generative AI is that not only is it great at writing code, which means that you can write new systems quickly, that's great, but it's great at reading code.

7:32Brian Feldt: So it can actually go and take a look at these old systems and not only be able to read the code and describe it, but create architectural diagrams, create flow diagrams, or just be an expert that you can ask questions to so that you can say things like, well, what if we wanted to change this database out that it's using? Or this interface where it's making this call, where do we find that in the code base and what's involved? And suddenly, that year-long discovery that you were going to need to do to just even figure out what it does is reduced to maybe a few days to be able to express, okay, here's what's happening.

8:11Brian Feldt: Now, you still have a big job in front of you just to even change it. So it's not like – it doesn't become free. But the biggest piece that was keeping you from even being able to consider it has now shifted.

8:22Nate McKie: What is it that we have to know about this software, these applications, to know whether it's a candidate for rewriting or replacing or just updating? I'm assuming there's got to be some level of understanding of what the software is doing or why it's doing it. Right. Exactly.

8:40Brian Feldt: There's been this concept for a long time called the seven R's when it comes to app modernization. So it's things like retain. I mean, we're just going to keep it. We're going to remove it. We're going to rewrite it. We're going to rebuild it. We're going to refactor it. You know, those kinds of things to figure it out. And there was always a hierarchy there of how much pain that was going to be to move from one or the other. So that process of figuring out what do we do with this old software generally stems from a couple of main things. One is cost, like we mentioned. If you're running on old platforms, old hardware, old operating systems, or even if it's a SaaS system that's from some very unique vendor that's costing you a ton of money because you just can't get away from them.

9:32Brian Feldt: So the cost is somehow hurting you enough that you're like, if we could just have this here or move it in-house or control it ourselves or move it to a less expensive platform, that would save us X amount of dollars every year. The other thing, and this is even more of a deal now than it used to be, is security. So if you've got software that is critical to your business that was written long ago and no one knows how it works and you have no idea what the code looks like, you have no idea what the vulnerabilities are. And, you know, okay, maybe it's running inside your network. That's great. But, I mean, we've seen how quickly now your network can be penetrated.

10:12Brian Feldt: And if they get in and find this core system that does something incredibly important for you and are able to take hold of it and change it in some way, that could be devastating to your entire business. So security is another piece of this. We can no longer ignore and just kind of say, well, no one's ever going to mess with that. We don't have to worry about it. That whole picture has changed as well. So at that point, that's when you go to the seven R's and you decide which of these is the one we want to do. And the ones you really want to do have always been refactor, which means let's change it so now it's in a code base or a place where we can understand it.

10:51Brian Feldt: We can change it. We can add interfaces to it. We can add AI to it, whatever it is. Or rebuild, which is just, all right, we're going to sunset this old system. We're going to build a brand new system. And it's going to do everything that one did, but it's going to do it so much better and do all these other things as well. So those are the ones you really want to do, and those are the ones that were always so expensive that you always just had to say, well, never mind. We'll do that next year or next. We'll look again in five years. So it's that consideration that organizations have traditionally gone through that we're now saying, hey, it's time to take another look because things have changed dramatically.

11:28Brian Feldt: And what was inconceivable before might actually be worth doing.

11:33Nate McKie: You shared an article with me before we started recording here that was interesting. It was from TechSpot, and it was highlighting – I'm going to read here a little bit. It was highlighting developers using AI to reconstruct classic video games like GoldenEye, Super Smash Bros, and Halo, which, first of all, thank you, took me back to my teenage years. I was enjoying that. But it also had enterprise examples in it, building alternatives to Adobe applications. And I thought it was a striking example of what these tools can actually do. But then you mentioned it not only can show you what it can do, but – and this is the good line that you had.

12:05Nate McKie: It showed you the dark side of all this as well. I'm curious if you can expand on that because that was just an interesting way to put it. Yes, this is powerful and great, but there is a downside here.

12:14Brian Feldt: Yeah, absolutely. So, well, for one thing, it is incredible what they can do. And the fact that you can take, you know, executable, compiled executables have been turned into binary code and you can back that out and figure out what that code is and rewrite it yourself and build it yourself using AI without having access to anything that that company had when they built it is incredible. It's just it's not something we ever dreamed would be possible. And if you can imagine an organization, again, who's got some critical piece, and it could be some tiny piece of their entire process, but it runs on some binary code that they've lost the source code to or the vendor went out of business or whatever it is, but they absolutely need it because they don't even know how it works.

13:04Brian Feldt: And the fact that they can go from binary code and potentially be able to reconstruct the code and build their own version of it using AI, it's incredible. It's like, wow, you've just taken the handcuffs off us. We were stuck with this, and finally we've got an answer that we never had before. That's amazing. And we've already helped customers in situations where they didn't have source code. We were able to rebuild something and replatform it to now a safe version of what it was before. That's great. The dark side is that if you're a software company and you've been creating applications for people like Microsoft, like Adobe, and now everybody can just build their own version of it, there's a lot of legal concerns there.

13:50And I think I would say it would be really tempting,

13:53Brian Feldt: even as an organization, to look at something like that and say, oh, well, let's just build our own. I think it remains to be seen how the legal system will process all of this. What does it mean? There used to be an idea back when IBM kind of owned the PC and Intel came along and did this white room version of their chips where they basically just said, okay, we don't know how you built that, but we're just going to look at how it works, what it does in a certain situation. We're going to do enough handoffs that nobody ever sees your proprietary stuff, but we're going to rebuild what you had.

14:28Brian Feldt: I think people are – the initial idea is, oh, well, this is the same idea. You're just cloning, right, just like we used to do with those IBM PCs. But that's not exactly the same when you are actually taking something that existed and deconstructing it to put it back into its form that someone worked and spent millions of dollars to build, and then you're just making it for yourself. So just a word of warning for organizations that are tempted by that, that that may end up not being okay. And that would be my guess.

14:59Nate McKie: And this is the SaaS-pocalypse that we've kind of heard about over the last few months.

15:02Brian Feldt: Right, but SaaS is even different because you don't have access to anything. You can see what the app looks like. You know generally what it does, but you don't have the back-end stuff that they're doing. You don't have any access to that. Whereas executable files that run on your machine, you've got everything you need if you can back that out to something. And again, even Microsoft or Adobe files that they've been charging you so much over time to be able to maintain those. If you can build those yourselves somehow, that is questionable from a legal standpoint. So just something to be careful about.

15:39Brian Feldt: For sure.

15:39Nate McKie: Well, I am interested then. And so if there is a dark side to all of this and we have to be kind of careful for how we tread moving forward, knowing that there might be unintended consequences on the back end of that, how would you advise? I mean, how are you advising our teams here at WWT or how would you advise other teams at other organizations? OK, well, here's how you should kind of proceed at this moment. Recognize there's an opportunity, but also recognize that there's potential pitfalls.

16:03Brian Feldt: Yeah. So first of all, it's do that evaluation again. Do that 7R evaluation on your legacy systems that are costing you money or you have security concerns around. No matter what, do that and kind of figure out where things stand and where the financials are versus where they were before. Consider that generative AI, even for some languages that people don't really use as much anymore, might be able to help you in a way that was just not possible. But at the same time, if you don't own that application, if that was not something your organization created, if you bought it from someone, licensed it from someone, someone else wrote it for you and are letting you use it, just be careful.

16:46Brian Feldt: Consider that that may not be – it might not be the best idea to try to take what they have and pull that – pull a new system from it like you could if it was your own. Certainly, when it comes to these SaaS applications, if they're doing something that you need and you know what that is, you know all the requirements, consider building that yourself. Absolutely. Rather than paying some niche group to do something important for you, pull it in. Own it. Have it under your roof. The tools are there now that make that feasible and give you a lot more ownership and autonomy over your future. But, you know, just if you don't own it, just be careful.

17:30Nate McKie: This episode is supported by Coder. Coder provides a self-hosted cloud development environment platform that gives enterprises secure, consistent, and governed remote workspaces for developers with built-in AI coding support. Accelerate software delivery and enable secure AI development with Coder's modern developer infrastructure. And it also strikes me that it's kind of half the conversation here. There's a lot of nuance and reasoning behind, you know, why these applications were written the way they were. To your point, they were written, you know, many years ago. Some people are retired, moved on to different companies.

18:06Nate McKie: There was decision making put into why things were written that way. And that gets back to the concept of context, which I've seen a lot more lately in kind of AI headlines, which is, you know, there's this idea that you need to attach yourself to the context to be able to move forward successfully. How do you start to uncover some of those contexts, so to speak, that were maybe not written down on paper and were stuck in somebody's head and that person may be gone now?

18:31Brian Feldt: Right. So we'll call those business rules. Okay, yeah. Like the things that are driving why the system operates the way that it does, right? And that's a great point and something I should have mentioned when you asked me before is that, you know, it is while these tools are incredibly powerful and they can go and read code bases and answer a lot of questions and move you along a lot faster, they are not perfect, as we say over and over. You know, AI is not perfect in what it does. It makes assumptions. It hallucinates. Things can happen that are not going to give you what you need. If you're talking about a critical system and don't expect that you're just be able to get AI to go tell you what the old system did and then just say, okay, write me a new one.

19:11Brian Feldt: And that's going to work in any sense of the word. It's not. So the key is how do you get that information you were just talking about out of the system? And in some cases, you may not be able to right away. And maybe that's okay, because if you just want to – if you're dying because this system is running on such an expensive platform, whether it's mainframe or something else, that you've absolutely got to get off of it, and all you care about is just reproducing its functionality, there's ways of doing that without really understanding what the system's doing. If you have enough examples of, if I give you this input, I get this output.

19:52Brian Feldt: And you need lots of it. But if you have enough, then you can just reproduce. The code can be written so that it will do just that. Always give you the same answer. And in fact, in some cases, even if you know the answer is wrong, if you know this legacy system's been telling you something that you've had to work around because it's not correct, probably better just to have it give it to you anyway. just so that you know you're replicating the system exactly. Do that, move it to its new home, and then let's try to figure out from there what are the business rules. So use AI, use your whatever information or history that you have or whatever you wanna know about your business to then look at the system and make sure that it's doing what it should do.

20:39Brian Feldt: Now, if all of your business rules are lost to time, you're probably in trouble as a business. Like you don't even know why you're operating the way that you are. So hopefully you've got people who know this is how we operate. This is why. I may not, you know, they may have forgotten little pieces like you said, but maybe those don't apply anymore. Maybe they don't matter. Once you've got something that's working, then you can start to move toward, okay, here's the perfect system. Here's the one that we need that reflects how we work.

21:06Nate McKie: Yeah.

21:06Brian Feldt: But all of that's got to be done all along the way with tests. Like tests become the way that you build, you overcome AI's issues, overcome its flaws and faults so that you know you're getting the system that you want. If you've got a string of tests that you've developed that say with these inputs, I need these outputs, you can always go back to your system and make sure that it's doing that. So that's going to be a bulk of the human-focused work when you're completely rewriting your system is that you're going to make sure that your tests are good, that they represent what you want, they represent how the system should work, and then you're going to let AI do its thing.

21:47Brian Feldt: So that's an incredibly important piece. That's why this is not free, but it does dramatically reduce the cost that it would have been before.

21:55Nate McKie: Yeah, I want to put a pin in test because I do want to talk about that more because I know I recognize it's such an important part. But you mentioned how you need to define the business rules. You need to identify them. But as we've come to learn, certainly in the last few years, the rules of business are kind of changing on the fly here. So how much is there balance to be given to like if you don't know the business rules or if you're lacking to define them? Is that an opportunity for innovation to kind of do things better, to do things outside of the walls of this is the way we've always done it?

22:23Nate McKie: Or do we need to have those defined business rules and justifications as an anchor to at least ground us to what was or is going on?

22:32Brian Feldt: I think if you were – if your decision was to do a complete rebuild of your system. So we're going to – we've got this old system. It's making so many mistakes or it's so wrong. Things are so outdated that we're just going to rebuild it now. Then business rules become your north star around that. is how do we make sure that our business rules are correct? I'm not worried as much about the inputs and outputs of that system because it's not accurate anymore. So what are our business rules? Let's pull out what we can from that. And AI can help you do that. It can help you try to figure out why it's generating the information that it is by, in some cases, looking at code.

23:15Brian Feldt: So you might have real code to look at, and then it can go and investigate that code and see if there are comments or names or anything else that would give it a clue. But even if you don't have that with just logic, trying to figure out why it might do those things in those situations. But what you really need are knowledgeable people about how it wants to work today that can start writing those things down, speaking them, whatever, some way that we can then turn them into requirements that can then be turned into tests that we can use to build our new system. So yes, absolutely. If you are building something new, just like if you were building it from Greenfield, it doesn't exist before, you've got to know what those business rules are.

23:56Brian Feldt: You've got to know how do we want it to behave in these particular situations. And sometimes that takes a while to figure out, but that's what you're going to use as the basis, and it would be the same thing here.

24:07Nate McKie: Yeah, no, that makes sense. Okay, let's unpin the testing component there for a second. And we've been talking a lot about the why, why you should be doing these types of things, and a little bit about the how. But the testing, to me, strikes me as kind of the major, this is how you actually go about getting it done. So walk me through that testing phase. What are you testing? How are you testing? What tools are you using? Yeah, absolutely.

24:28Brian Feldt: So in the case of we want to replicate the system as it was before, you're going to focus more on what's called characterization tests, which, again, are just if I give you this input, what is the output? And the critical thing there is to find all of the – as many of the possible inputs and outputs that you can find to make that work. So hopefully you have your old system. You can feed it things. You can see what comes out. You can use that to ensure that you've got the right list. So all the possible ranges for all the things that you give it. And make sure that it's – that you know how it behaves in all those situations.

25:09Brian Feldt: and building your whole system with that kind of approach. With also some business rules tests where you know them just to make sure that the system does the things you know it should do. But that's going to be your basis for doing that strict rewrite just to move it to a – or refactor rather – just to move it to its new place. But if you're building a – if you're going to rebuild the system or you're building a new system, then you're really going to start to build tests from some kind of specification, some kind of requirements of either what the system was doing and should do, what your experts say should happen, and you're going to use that to generate tests.

25:51Brian Feldt: And while a lot of the good agile and coding discipline practices have started to kind of disappear with the way that code is now being created, one of the ones that we used to have was called test-first development or test-driven development. So it was a great practice as an engineer to instead of just, oh, you want a new feature, I'm just going to go write your new feature in a system. First, stop yourself, write some tests that automatically test your system and prove that that feature doesn't currently exist. And then go in, change the code, and now run your tests again. And if they pass, that means that you have definitely changed the system in such a way so that it now does what you wanted before.

26:36Brian Feldt: And that was a great way to code because not only did it force you to really think about what you were doing and how it would work and what the results could be, but it also made you only write enough code to make it pass and not go in and start doing a bunch of fancy stuff that would get you in trouble. You would learn a lot from that. It would help you think. It would help you figure out edge cases and that kind of thing. In today's world, it doesn't make as much sense to think that way because you're asking the AI to build this thing for you. You're not going to learn as much from the whole process of doing that.

27:12Brian Feldt: At the same time, AI has the same tendency that excited engineers used to have, which is not only am I going to go add this feature, but I'm going to go fix this thing that's been bothering me over here. You know what? I'm just going to completely redesign how all this works because this is messy and I don't like it. Yes, right. AI will do the same thing. It will go in and do way more than you need to when you just ask it to achieve a certain task. So if you can give AI these tests and then say, I only want you to make these tests work, don't do anything else, you get a lot better chance of having it not go in and make changes that you don't want.

27:50Brian Feldt: So there's still value in that. So that's a good practice regardless. And it's great for what we're trying to do here, which is make sure that your critical system does exactly what you want it to do.

28:00Nate McKie: Is that easier said than done? Because we've talked time and time again on this show about how agents can kind of have a mind of their own or they talk to other agents who might be bad influences on them and have minds of their own. So how do you keep a lid on that knowing that it's so easy for an overzealous AI to be like, oh, you know what? I'm just going to go fix this over here.

28:19Brian Feldt: No guarantees, right? However, for the most part, these systems, and especially the ones that you're using as a software engineer to do agentic coding, are tuned to follow instructions. That is what everyone recognizes is incredibly valuable is do what I told you to do and don't go beyond that. So it still can happen. You know, hugging face kinds of things can still happen where they go off and you give it a hard problem and it decides to break the rules to go and try and solve it. So you need to be careful. You need to not give it too big of a bite to take at any particular time. But having those tests is a great way to give it guardrails just from the start.

28:59Brian Feldt: Like focus on the test. Don't try to reinterpret my words. Don't try to re-architect the system. Focus on the test that I gave you. Make this work. Come back to me if you feel like something is stopping you. And that kind of process tends to work pretty well.

29:14Nate McKie: How quickly is that happening, that process?

29:16Brian Feldt: Well, I mean, if you are able to generate the test using AI, which you can do, and review them pretty quickly and hand them off, depending on the size of the task, it could be a cycle that's going anywhere from minutes to hour or two to go through and do that. on some particularly challenging issues, you might let it run overnight or over the weekend with these particular boundaries or guardrails. But again, you might end up with a lot of stuff to review at the end of that.

29:47Nate McKie: I found it fascinating. You mentioned how there are some coding disciplines that are starting to go by the wayside just because of how AI is changing. What new coding disciplines are starting to emerge that you think are interesting?

29:59Brian Feldt: Yeah, well, whereas before we might have really emphasized readability of code, like make sure that you're naming things in a way that makes sense. Maybe you make sure you're putting comments or whatever you might do in the code to help someone who comes along later understand what it does. That doesn't really matter as much anymore. So now what we're finding ourselves doing is focusing on the requirements and specification side. whereas before you might have given me a spec document and as a coder I'd go and start writing it but then halfway through I might say oh wait a minute you didn't tell me what to do if this thing happens you know if somebody clicks this box and enters you know all caps in this field what am I supposed to do you go back and you ask the question you might change the spec you might not you know you might rather than change the spec you might go in and write a test or something that would show why you're doing this particular thing.

30:57Brian Feldt: So we don't have that anymore. And so what we have to focus a lot more on now is those specs, is those requirements documents. And so our teams, whereas they might've just had the requirements document off in some SharePoint or somewhere, they're now checking it in like it's code. And every time they change, you go and change them, you check in the new version, you put a comment about who changed it and why. Like you want traceability because things are moving so fast. You've got new versions coming out every day and your stakeholders looking at it and saying, oh, yeah, I forgot to tell you. In this case, we've got to do this other thing.

31:34Brian Feldt: Okay, great. Let me go and track that and write down that you told me that and put it in our source control system so if somebody comes along later or even if the AI comes along later, they know that's the rule to follow. And we might have been a little lazy about that before, but now that becomes the main thing that you want to take care of. So that's the sort of change that we're seeing now is discipline around how you define what you want and then discipline around how you review what comes out the back end. And a lot more of the intellectual work is being done at those sides than was in the code before.

32:12Nate McKie: That sounds like we're kind of pushing the engineer maybe closer towards the business.

32:17Brian Feldt: fair? Yes, on some level. Although - Maybe the business closer to the engineer?

32:21Nate McKie: Yeah, right.

32:22Brian Feldt: It depends. I mean, not every engineer is going to be great the business side. So I would not recommend that you get rid of all of your stakeholders and product owners and just let the developers and AI get it all done. You're probably not going to get a great result from that. So on some level, yes, they need to understand requirements better. They need to ask good questions up front. But you still need people who understand the business to be involved and constantly looking this and reviewing what comes out because of the rapidity of how many new features you're getting. If you have stakeholders who are only checking in once a week, they could come in and see a whole new application.

33:02Brian Feldt: There's way too much for them to even absorb. And that's when you're going to start going down the path of having errors or having to redo the whole thing because someone didn't watch carefully what was going on. You still need those business people involved. I do think that the engineers are getting pushed a lot more toward thinking higher level about how systems are architected and put together. And also getting more critical when I review, is what I'm getting from the AI good or not? And that's the kind of thing from an engineering perspective they have to get much better at, is looking at someone else's code and making a good judgment about it, whereas before, maybe they didn't have to do that that often.

33:44Nate McKie: Yeah, that's making a good judgment call for the now. And I'll get you out the door on this, because I know your time is valuable here. You've been gracious enough to give us plenty of it. How do we build things now to make sure that they're adaptable moving forward? The people building these applications 5, 10, 20 years ago, I'm sure they were thinking they were on the cutting edge and be like, oh, yeah, this will stand the test of time. So maybe there's never going to be a good answer for this, but what's the best we can do to build so that it's flexible and adaptable and we don't have to repeat through the seven R's or whatever, however many R's there were moving forward?

34:21Brian Feldt: I would posit that the people who were really caring about things standing the test of time, anything they created is probably great for AI, because AI is going to be able to understand them, the code was readable or whatever, they worked really hard to do something well, that's going to mean that AI is going to make fewer mistakes when it looks at it. So I think that the question kind of answers itself in that if you're worried about that, if you're like, I want to build something that lasts, you're probably going to put a lot more effort into that requirements gathering and tracking and tracing everything that came along and what it was for.

35:00Brian Feldt: You're probably going to put a lot more effort in making sure that the stakeholders are more often involved, that you're reviewing the code at good intervals so it doesn't become too overwhelming and people are just letting things slide without ever looking at it. You're probably going to pay attention on the security review and how it's deployed. All of that kind of block and tackling stuff that we've been saying you need to do for years, you still need to do on some level except for the code writing part. All of that stuff's now even more important than it was before. So I don't think there's anything different to do, just recognizing that those disciplines that allow you to understand what you've built and why you built it that way, and then make sure what is going out the door is what you wanted, ultimately that's going to pay off.

35:49Nate McKie: Well, a lot of chatter then for the always boring back to basics or make sure you keep your mind on fundamentals.

35:55Brian Feldt: It's amazing how AI keeps pushing us security networks, everything else to, yeah, that's that stuff we should have fixed a long time ago.

36:03Nate McKie: Yeah. Well, something to keep in mind moving forward. Nate, as always, appreciate the time and I'm sure we'll have you on again soon. Yeah, it was great. Thanks for having me on. Yeah. Okay. Thanks to Nate for stopping by. It's clear AI is changing what's possible with the software enterprises depend on, but faster development still demands a clear understanding of the business and evidence that the changes work. This episode of the AI Proving Ground podcast was co-produced by Nas Baker and Kara Kuhn. Our audio video engineer is John Knobloch. My name is Brian Felt. Thanks for listening. We'll see you next time.